Free · Fast · Privacy-first

JSON Parse Error Fixer

A JSON parse error tells you something went wrong but rarely tells you what to do about it.

Converts character positions to line and column

🔒

Explains what caused the unexpected token

Identifies all common parse error types

Free, no installation, browser-based

Cost
Free forever
Sign-up
Not required
Processing
In your browser
Privacy
Files stay local
FreeNo signupWhite-label

Add this JSON Validator to your website

Drop the JSON Validator into any page — blog post, product docs, intranet, school portal — with a single line of HTML. Your visitors get the full tool, processed entirely in their browser. No backend, no uploads, no signup.

  • Files stay 100% in the visitor's browser
  • Responsive — adapts to any container width
  • Free forever, no API key needed

Embed code

<iframe
  src="https://www.fixtools.io/json/json-validator?embed=1"
  width="100%"
  height="780"
  frameborder="0"
  style="border:0;border-radius:16px;max-width:900px;"
  title="JSON Validator by FixTools"
  loading="lazy"
  allow="clipboard-write"
></iframe>

Attribution-friendly: a small "Powered by FixTools" link appears in the embed footer.

Unexpected Token Explained: What Each Token Means and How to Fix It

The phrase Unexpected token appears in JSON parse errors whenever the parser encounters a character that does not match the grammar rule it is currently evaluating. The character is named in the message as the token. The most common unexpected tokens have well-defined human causes. A closing brace or bracket means there is a trailing comma immediately before that closing character. A single quote means a developer used single-quoted strings where the grammar requires double quotes. A leading letter that opens a word like undefined, NaN, True, or None means a serialiser produced a literal that JSON does not recognise. A less-than sign at position zero means the response was actually HTML, not JSON.

The position in the error message is a character offset from the start of the buffer, counting from zero. Converting offset to line and column requires walking the string character by character, counting newlines and resetting the column on each line break. Most engines report the offset accurately at the character that broke the parse. The exception is the trailing comma case: the parser does not realise the comma was trailing until it encounters the closing bracket, so the reported position lands on the closing bracket rather than on the comma itself. Knowing this saves you from staring at a correct-looking closing brace and wondering what is wrong with it.

After locating the unexpected character, the next step is to compare what was found against what the grammar expected. Expected comma between values means two values appeared back to back with no separator. Expected closing bracket means the parser counted more open brackets than it found close brackets. Expected string means a property name was not wrapped in double quotes, or the parser was looking for a string and found a different value type. Expected value means a comma was followed by a closing bracket, which is the trailing comma signature. FixTools reports both the found and the expected character, so the fix is determined rather than guessed.

Once a parse error is diagnosed and fixed in the moment, the durable next step is to prevent the same class of error from recurring by wiring validation into a CI pipeline. A typical GitHub Actions job runs jq . over every JSON file changed in a pull request and exits non-zero on the first failure, blocking the merge. For projects with many JSON fixtures, a pre-commit hook using the standard check-json hook from the pre-commit framework catches the failure on the developer machine before it even reaches the remote repository. For runtime JSON crossing the wire from external systems, a validation middleware that catches parse failures and returns a structured 400 response avoids leaking SyntaxError stack traces to clients. Each layer turns a recurring debugging cost into a one-time configuration cost. The savings compound across the team because every developer benefits from every previous fix without having to learn the same lesson independently.

How to use this tool

💡

Paste the JSON that is giving you a parse error. FixTools shows the line, column, unexpected token, and what was expected, making the fix clear.

How It Works

Step-by-step guide to json parse error fixer:

  1. 1

    Copy the failing JSON

    Capture the exact JSON string that triggered the parse error in your code. Add a console.log of the input immediately before the parse call so the captured value matches what the parser actually saw, including any invisible bytes the surrounding code may have introduced. Copy from the log rather than from the original source to be sure.

  2. 2

    Paste into FixTools

    Paste the captured string into the FixTools JSON validator input area. Confirm the length and the first few characters match your expectations to rule out clipboard truncation. If the string came from JSON.stringify in your log, strip the outer quotes and unescape the embedded quotes before pasting so the validator processes the same bytes the parser did.

  3. 3

    Read the error details

    FixTools reports three pieces of information for every error: the line and column where parsing failed, the unexpected character that was found, and the character or token type that the grammar expected at that point. Read all three together. The combination tells you whether the fix is a single character deletion, a quote replacement, or a content-type investigation.

  4. 4

    Fix at the reported location

    Navigate to the exact line and column in your source editor. Apply the fix that matches the token type: delete the trailing comma before a closing bracket, replace single quotes with double quotes, change a NaN to null, or trace back to where the JSON was generated when the issue is at position zero. Save the file and prepare to revalidate.

  5. 5

    Revalidate

    Paste the updated JSON into FixTools and run validation again. JSON parsers fail fast, so one error can hide others further down. Repeat the fix-and-revalidate cycle until the validator returns a green result. Only then update the source generator so the same failure does not recur on the next record produced by the same pipeline.

Real-world examples

Common situations where this approach makes a real difference:

DevOps engineer

A deployment pipeline fails with a JSON parse error at position 1823 in a Helm values file. The engineer cannot tell which line that is. They paste the file into FixTools, which reports the error at line 47 column 3 with the message Unexpected closing bracket, expected value. The trailing comma on line 46 closed a list prematurely. Removing the comma lets the deploy proceed, and the engineer updates the Helm chart template that produced the comma so the same failure does not block the next release.

Front-end developer

A React app throws SyntaxError: Unexpected token 'undefined' at runtime when reading a cached response. The developer logs the cached string before parsing, pastes it into FixTools, and sees the literal text undefined where a value should be. The cache writer serialised an undefined object property without converting it to null. The fix is to add a replacer to the JSON.stringify call that converts undefined to null so the cache content always validates on read.

Backend developer

An Express API receives a request body that fails parsing in the express.json middleware. The developer captures the failing body and pastes it into FixTools. The validator reports an open parenthesis at position zero, meaning the body is JSONP-wrapped rather than plain JSON. The client is sending the wrong content type because of a misconfigured fetch call. The fix is in the client, not the server, and the team adds a content-type check to the middleware to surface this category of error more clearly in future.

QA engineer

A QA engineer is reproducing a production bug where a JSON import fails for a small group of users. They download the file from one affected user environment and paste it into FixTools. The validator reports NaN at line 103 in a numeric field where the sensor reading was missing. The data pipeline that generates these files writes NaN instead of null when a sensor times out. The fix is in the pipeline, and the QA engineer adds a regression test that replays the affected file shape.

Pro tips

Get better results with these expert suggestions:

1

Fix errors from the top down

JSON parsers stop at the first fatal error, so the error reported is always the earliest failure in the buffer. Fix that one first and revalidate. Errors earlier in the file frequently cause the parser to misinterpret everything that follows, which produces misleading secondary error messages. Trying to address all reported issues in a single editing pass without revalidating in between often introduces new errors that did not exist before you touched the file.

2

Unexpected closing bracket means trailing comma

When the error says Unexpected token } or Unexpected token ] and the position lands on the closing character, look at the character immediately before it in the source. A comma sitting between the last value and the closing bracket is almost always the cause, and the parser only realised the comma was trailing once it reached the bracket. The fix is to delete the comma, not to add a new value, and not to remove the bracket.

3

Check for NaN and undefined in serialised output

When JSON comes from JSON.stringify and still fails to parse on the receiving side, the source object likely contained NaN, undefined, or Infinity in some field. JSON.stringify writes Infinity and NaN as null automatically, but some hand-written serialisers in other languages or in older libraries write them literally. Add an assertion in the producing code that rejects these values before serialisation rather than waiting for the consumer to fail.

4

Use a hex viewer for invisible character errors

When the error position points to a character that looks completely correct in your editor, the buffer almost certainly contains an invisible Unicode character at that location. A hex viewer or a Unicode code point inspector reveals zero-width spaces at U+200B, non-breaking spaces at U+00A0, byte order marks at U+FEFF, and directional formatting marks at U+200E and U+200F. Remove the invisible character or escape it as a Unicode escape sequence inside a string.

FAQ

Frequently asked questions

A JSON parse error occurs when JSON.parse, or any equivalent parser in another language, receives a string that does not conform to the JSON grammar defined in RFC 8259. The parser raises an exception, in JavaScript a SyntaxError, with a message describing the character it found and the position in the buffer. Common root causes are trailing commas, single quotes instead of double quotes, unquoted property names, missing or mismatched brackets, undefined or NaN as values, and unescaped control characters inside string values.
The phrase means the parser encountered a character at a position where the grammar did not allow that character. The named token is the character that was found. The position is the offset in the buffer where the parser was when it gave up. For example, Unexpected token comma at a position right after a comma means a duplicate or leading comma was encountered. Unexpected token at a closing bracket position means a trailing comma was encountered. Each combination has a specific human cause and a specific fix.
The easiest way is to paste the failing JSON into FixTools, which converts the raw character offset into a line and column reference automatically. Firefox already includes a line and column in the SyntaxError message it produces, so you can read it directly if you are debugging in Firefox. Chrome and Node.js produce a position offset that you can convert by counting newlines in the input, but doing that manually for a large file is tedious and error prone. The validator handles the conversion for you.
There is no universal automatic fixer because the right fix depends on the human intent behind the data. A trailing comma might mean the last element should be removed or that a new element was about to be added. A single quote might mean every string in the file should be converted or that just one was mistyped. An undefined value might mean null was intended or that the key should be omitted entirely. FixTools identifies the exact location and category of the error so a developer can apply the correct intent-aware fix in seconds.
JSON parsers are fail-fast by design: they stop at the first character that violates the grammar and report only that location. Everything after the first failure is unread, so any errors lurking further down the buffer are invisible until the first one is repaired. After you apply a fix and revalidate, the parser advances further into the file and may surface a second, previously hidden error. Repeat the fix-and-revalidate cycle until the parser reaches the end of the buffer without complaint.
A parse error means the bytes cannot even be turned into a JavaScript value because the grammar is violated. A schema validation error means the bytes parsed successfully, producing a structured value, but the value does not match a declared schema: wrong field types, missing required properties, values outside a permitted range. Parse errors are lower-level and must be fixed before schema validation can run at all. The two checks fail for different reasons and produce different diagnostic information, so always treat them as separate steps.
JSON.parse accepts the full range of Unicode characters in string values. RFC 8259 requires the JSON text itself to be encoded in UTF-8, UTF-16, or UTF-32, with UTF-8 being effectively universal in modern practice. String values may contain any Unicode code point except the control characters from U+0000 through U+001F, which must be written using the backslash-u four-hex-digit escape sequence. Characters outside the Basic Multilingual Plane are represented as UTF-16 surrogate pairs in JSON escape sequences when the source format requires escape encoding.
Validate JSON at the boundaries where it enters your system: API responses, user-submitted bodies, file reads, database column reads, and message-queue payloads. Wrap every JSON.parse call site in try-catch and log the input along with the error message in the catch branch so failures can be replayed. For JSON that your own code generates, add tests that round-trip every type your serialiser may emit, including the edge cases of NaN, Infinity, undefined, very large integers, and Unicode strings with embedded escape sequences.
When the validator output is not enough to pinpoint the cause, layer additional tools on top. A hex viewer such as xxd, the built-in hex mode in VS Code, or a tool like CyberChef reveals invisible characters, BOM bytes, and encoding issues that look identical to valid characters in a normal editor. A diff tool comparing the failing document against a known-good template highlights exactly which bytes diverge between the two. A JSON formatter that indents by nesting level visually exposes structural imbalance because the closing brackets sit at unexpected indent depths. For programmatic debugging in JavaScript, the json-source-map package returns line and column information for every position in the parsed tree, which lets you write tooling that points at specific paths in the original source. Combining these views with FixTools usually resolves even the hardest parse errors within a few minutes of focused investigation.

Ready to get started?

Open the full JSON Validator — free, no account needed, works on any device.

Open JSON Validator →

Free · No account needed · Works on any device