SyntaxError: Unexpected end of input, explained and fixed
The engine reached the end of the file while still inside an unfinished construct: a function without its closing brace, a string without its closing quote, a template literal, a comment, or a bracket that never closes. Unlike other syntax errors there is no bad token to look at, the problem is an absence. The second family of causes is truncation: the code itself was complete where it was written, but the file that arrived, after a copy, upload, or network response, is shorter than the original.
How to find what is missing
- Run a formatter or linter over the file. Tools like Prettier fail at the first unbalanced construct and report a position, which is far more useful than the end-of-file location the engine reports.
- Use bracket matching from the outside in: click the opening brace of the top-level structure and find its partner. Work through functions and objects one at a time, the one whose partner is missing is the culprit.
- Look at the very end of the file. If it stops mid-word or mid-line, the file is truncated and the missing piece is not a punctuation mark, it is the rest of the file.
The usual causes
- A deleted or never-typed closing brace, bracket, or parenthesis, commonly lost while editing a long function or pasting a block into the middle of another.
- An unterminated string, template literal, or block comment, everything after the opening mark is treated as content, so the file “ends” while the parser is still inside it.
- Truncated content: an incomplete copy-paste, a file upload that stopped early, a build artifact cut off, or a server response body that ended early and was parsed anyway.
- JSON that ends early, the same error appears when parsing a cut-off JSON document, the data source ends mid-object or mid-array.
The fixes, in order
- Close the construct the parser is waiting for. Add the missing brace, quote, or backtick at the point where the construct should end, which bracket matching identifies, not blindly at the end of the file.
- If the file is truncated, restore the complete version from source control, the editor's local history, or a fresh download or upload, then compare file sizes when copies disagree.
- For parsed responses, check completeness before parsing: verify the HTTP status and content length, and treat a short body as a network or server failure rather than feeding it to the parser.
- Prevent recurrences in long files: let the editor auto-close brackets and quotes, and run the project's syntax check or build before deploying, this error is always caught by parsing, never by users first if a build step runs.
Common questions
Why does the error give no line number? Because the position is the end of the file by definition, everything was still open when the input ran out. A formatter or bracket matching gives the useful position, the construct that never closes.
My code looks complete, what else could it be? An invisible truncation: the file on the server or in the bundle is shorter than the one in the editor. Compare sizes or checksums, and check for an unterminated template literal, which makes a complete-looking file parse as unfinished.
Does this happen with JSON too? Yes. A JSON document cut off mid-structure fails with the same family of message when parsed, and the fix is at the source of the truncated data.
Related errors