JSON Formatter & Validator
Valid JSON — 6 keys, 154 bytes formatted
How this was worked out
- Structure6 keys, 9 values, nested 2 deep
- Smallest form109 bytes minified
- Output (2 spaces)154 bytes, +41% of it whitespace
Strict JSON, the dialect JSON.parse accepts: double-quoted keys and strings, no comments, no trailing commas, no NaN and no Infinity. Two rewrites happen quietly and are worth knowing about — duplicate keys collapse to the last one, and keys that look like whole numbers are re-ordered numerically ahead of the rest, so {"2":"b","1":"a"} comes back with "1" first. Nothing is uploaded; the parsing happens in this tab. What you type is carried in the address bar up to about 1,200 characters so a snippet can be sent to someone, which is a reason not to paste a token or a customer record in here.
Formatting, validating and finding the break
JSON arrives minified from an API, hand-edited into a config file, or pasted out of a log, and in all three cases the first thing you need is to see its shape. This tool re-indents JSON at two spaces, four spaces or a tab, minifies it back down, and tells you immediately whether it parses at all — reformatting as you type rather than waiting for a button, so the output can never sit there contradicting the input.
When it does not parse, it reports the problem by line and column with a description of what was expected, which is the part that saves the time.
Error messages you can act on
The browser’s own JSON errors are inconsistent. Most carry a character offset — "Unexpected number in JSON at position 32" — which means counting characters in a 40-line file, and some carry no position at all. The wording also changes between browser releases, so the same broken file produces different messages in different places.
This tool locates the fault itself and reports it in editor coordinates. A file whose third line reads "value": 01 is answered with “Expected "," or "}" after property value (line 3, column 13)” — the leading zero is illegal in JSON, so the parser gave up on the number and wanted a delimiter. A trailing comma in {"a": 1,} gives “Trailing comma before "}" (line 1, column 9)”. A key written in single quotes gives “Expected a double-quoted property name (line 1, column 2)”. An unrecognised escape such as \q inside a string gives “Invalid escape "\q" (line 1, column 10)”.
What JSON allows, and what it does not
Most invalid JSON is valid JavaScript, which is why it looks fine. The specification is much stricter than the language it came from:
- Keys must be double-quoted strings. Bare keys and single quotes are both rejected.
- No trailing comma is permitted before a closing brace or bracket.
- No comments of any kind. // and /* */ are JavaScript, not JSON.
- Numbers may not have a leading zero, a leading plus, or a bare decimal point: 01, +1 and .5 are all invalid, while 0.5 and 1e-3 are fine.
- undefined, NaN and Infinity are not JSON values. Only strings, numbers, true, false, null, objects and arrays are.
How it behaves, and what it does not do
Validation is done by the browser’s own parser, so a document accepted here is accepted by anything else that follows the specification. Formatting is re-serialisation, not text manipulation: the document is parsed to values and printed again. That has two consequences worth knowing. Key order is preserved except for keys that look like array indices — "1", "2", "10" — which every JavaScript engine moves to the front in numeric order, whatever the document said. And the original whitespace, and any duplicate key, is not preserved either. Where a key appears twice, the last one wins, which is the same rule every JSON parser applies.
Everything happens in your browser. Nothing is uploaded, logged or stored, which matters given how often the JSON someone needs to inspect contains a token, a customer record or a payload from production. There is no schema validation, no JSON5 or JSONC support, and no repair mode: the tool tells you precisely where the document breaks, and leaves fixing it to you.
Trailing commas, comments and indentation
Why is my trailing comma an error?
Because JSON does not allow one, even though JavaScript does and most editors will not flag it. It is the single most common cause of a file that looks correct and will not parse — particularly after deleting the last entry from a list.
Can I add comments to a JSON file?
Not in JSON itself. The usual workarounds are a dedicated key such as "_comment", or a superset like JSON5 or JSONC — the latter is what VS Code accepts in its own settings files. Neither will parse as plain JSON, so anything consuming the file has to know.
What indentation should I use?
Two spaces is the most common convention for JSON and is what most formatters emit by default. Minify for anything transmitted over a network, where whitespace is pure overhead, and indent for anything a person has to read or diff.
Does reformatting change my data?
Only in ways the JSON model does not distinguish. Whitespace goes, duplicate keys collapse to the last one, numeric-looking keys move to the front, and 1.0 comes back as 1 because JSON has a single number type. Anything that survives a parse and a print is unchanged.
What happens to a very large number in my document?
It is parsed into a double, so an integer above 9,007,199,254,740,991 comes back rounded — a 64-bit database identifier can leave this tool as a different number than it arrived. Systems that must keep those exact send them as strings.
Is JSON the same thing as a JavaScript object literal?
No. JSON borrowed its syntax from JavaScript and then took most of it away: double-quoted keys only, no comments, no trailing commas, no undefined and no functions. Perfectly good JavaScript is very often invalid JSON, which is why a config file that reads fine will not load.
Will this read a newline-delimited JSON file?
No — NDJSON is one complete document per line, which is not itself a JSON document, so paste a single line to inspect it.