How to Format, Validate and Debug JSON (and Fix “Unexpected Token” Errors)

JSON is the format almost every API speaks, and the reason a “formatter” exists is that APIs do not send it in a form humans can read. A response arrives as one long line with no spaces, a config file has a missing comma on line 412, or a webhook payload nests eight levels deep and you need to find one field. Formatting fixes the first, validating finds the second, and a tree view solves the third. This guide covers all three, the errors you will actually hit, and the rules of the format that trip people up.

Format vs. validate vs. minify

• Formatting (pretty-printing) adds line breaks and indentation so structure is visible. It changes nothing about the data.
• Validating checks the text against the JSON specification and reports the first place it breaks, with a line and column.
• Minifying strips the whitespace back out for transmission or storage.

The JSON Formatter & Validator does all three: paste in, pick 2- or 4-space indentation, and it either returns the formatted output or points at the error. For the reverse direction on a whole file, the Code Minifier handles JSON along with CSS and JavaScript.

The JSON rules people forget

JSON looks like JavaScript but is stricter. These are the differences that cause most “Unexpected token” errors:

Advertisement

Rule	Invalid	Valid
Keys must be double-quoted strings	{name: "Ana"}	{"name": "Ana"}
Strings use double quotes only	{"name": 'Ana'}	{"name": "Ana"}
No trailing commas	[1, 2, 3,]	[1, 2, 3]
No comments	{"a": 1 // note}	Remove, or use a "_comment" key
No undefined, NaN or Infinity	{"x": undefined}	{"x": null}
Numbers cannot have leading zeros or a trailing point	007, 5.	7, 5.0
Escape special characters in strings	"path": "C:\new"	"path": "C:\\new"
One top-level value	{"a":1} {"b":2}	[{"a":1}, {"b":2}]

Reading validator errors

Validators report the position where parsing failed, which is often one token after the real mistake. Common messages and what they usually mean:

• “Unexpected token } in JSON at position N” — a trailing comma just before the brace, or a missing value after a colon.
• “Unexpected token ‘ “ — single quotes used for a string or key.
• “Unexpected end of JSON input” — a bracket or brace was never closed, or the text was truncated when copied.
• “Unexpected token <“ — you are not looking at JSON at all. The API returned an HTML error page (a 404 or a login screen). Check the status code first; the HTTP Header Checker will show it.
• “Bad control character in string literal” — a literal newline or tab inside a string. Replace with \n or \t.

When the error position is deep inside a large document, format it first so the line number becomes meaningful, then fix and re-validate.

Navigating large payloads

A formatted 5,000-line API response is still hard to search by eye. Three approaches, in order of effort:

1. Collapse the tree. A formatter with a tree view lets you fold arrays and objects, so you see the top-level keys first and expand only the branch you need.
2. Search by key. Once formatted, a browser find for "order_id" jumps straight there, which is impossible in the minified single line.
3. Query it. For repeated work, jq on the command line (jq '.data[] | .id') or a JSONPath expression pulls out exactly the fields you want.

Encoding gotchas

• Character encoding is UTF-8. Data pasted from Windows tools may be in a different encoding and show as mojibake (é instead of é).
• Large integers lose precision. JavaScript parses numbers as 64-bit floats, so IDs above 2⁵³ (about 9 quadrillion) get rounded. Twitter and many databases send such IDs as strings for this reason. If your formatter runs in a browser and a long numeric ID changes on output, this is why; treat it as a string.
• Dates are strings. JSON has no date type. ISO 8601 ("2026-09-15T10:30:00Z") is the convention; anything else needs documenting.
• Base64 for binary. Images and files travel as base64 strings. The Base64 Encoder & Decoder turns them back into files when you need to inspect one.

A quick workflow for debugging an API response

1. Check the HTTP status. Anything other than 2xx means the body is probably an error object or HTML, not the data you expected.
2. Paste the body into the formatter. If it validates, format and collapse to the top level.
3. If it fails, read the error position, format what you can, and look one token before the reported spot.
4. Compare field names against the API documentation; a surprising number of bugs are userId vs user_id.
5. Minify before pasting into a test fixture or an environment variable, where line breaks cause trouble.

Frequently asked questions

Is it safe to paste API responses into an online formatter?

Only if the tool processes the text in your browser. The ToolzDirectory formatter runs client-side and sends nothing to a server; still, redact tokens and personal data from anything you paste anywhere, out of habit.

Why does my formatted JSON have keys in a different order?

JSON objects are officially unordered, so some parsers sort keys. It does not change the meaning. If order matters to a downstream system, that system is relying on undefined behaviour.

Can JSON have comments?

Not standard JSON. JSON5 and JSONC (used by VS Code settings) allow them, but most APIs and parsers will reject them.

What is the difference between JSON and a JavaScript object?

JSON is a text format with strict syntax; a JavaScript object is a live value in memory. JSON.parse turns text into an object and JSON.stringify does the reverse.