JSON Formatter and Validator

Finding the error, not just reporting one

"Unexpected token" on its own is useless on a thousand-line file. When the JSON here is invalid, the message includes the line and column where the parser gave up, which is usually a line or two after the actual mistake.

The four mistakes that cause almost all failures

1. A trailing comma. {"a": 1,} is invalid JSON. It is legal in JavaScript, which is exactly why people write it.
2. Single quotes. JSON requires double quotes, on both keys and string values. {'a': 1} is not JSON.
3. Unquoted keys. {a: 1} is a JavaScript object literal, not JSON.
4. Comments. JSON has none. Any // or /* */ makes the document invalid, which is a common frustration in configuration files.

All four exist because JSON looks like JavaScript and is stricter than it. The specification is deliberately tiny — it fits on a single page — and that strictness is what makes it parseable everywhere.

What JSON cannot represent

• Dates. There is no date type, which is why everyone uses ISO 8601 strings by convention.
• Undefined, NaN and Infinity. None are valid.
• Comments, as above.
• Large integers safely. Numbers above 2⁵³ lose precision when parsed by JavaScript, which is why APIs often send IDs as strings.

That last one causes real, subtle bugs. If an ID comes back as a number and the last digits are wrong, this is why.

Minifying

Removing whitespace typically cuts 15–30 % of the size of formatted JSON. Worth doing for anything sent over a network, and worth undoing before trying to read it.

Common uses

• Reading an API response that arrived minified.
• Finding the syntax error in a configuration file.
• Checking structure — key count and nesting depth are shown above.
• Minifying before sending.

Questions people ask

Why is my JSON invalid?

Most often a trailing comma, single quotes, unquoted keys, or comments. All four are legal JavaScript and none are legal JSON.

Can JSON have comments?

No. The specification has no comment syntax, which is a common frustration in configuration files.

How do I represent a date in JSON?

There is no date type. The convention is an ISO 8601 string such as 2026-09-13T12:00:00Z.

Why did my large ID number change?

JavaScript loses precision above 2⁵³. That is why APIs often send identifiers as strings rather than numbers.

Is my JSON sent anywhere to be validated?

No. It is parsed in your browser, which matters given how often these files contain credentials.

Your text stays in the page

This matters more here than on most tools. People paste API keys into hash generators, customer data into CSV converters, contract wording into diff checkers and configuration into JSON validators. Almost every site offering these sends your input to a server to process it.

Nothing here is transmitted. The work happens in your browser, this site is static files with no server behind it, and the about page lists every request the site makes, read live from your own browser so you can check rather than trust.