How it works : Format JSON
The parser is written here, by hand, rather than borrowed from the browser: because the browser's error message is normalised by no specification at all, and differs from one browser to the next. This one gives the line, the column, and what was expected, the same everywhere.
A JSON file rejected by a program, and an error message that says nothing: that is daily life for anyone who touches a configuration file or a data export. The first job of a validator is therefore to say WHERE, precisely, and what was expected at that point.
That is why the parser is written here rather than borrowed from the browser. The language standard fixes the TYPE of exception the browser must throw, not its text: Firefox gives the line and the column, Chrome gives a byte position, Safari gives neither. A tool that repeats that message therefore hands out a different diagnosis depending on which browser the person is using. Ours counts its own lines and columns.
And it sees three things the browser's own function swallows in silence. DUPLICATE KEYS: the standard says names “should” be unique and that the behaviour of software receiving such an object is unpredictable; in practice the last one overwrites the first, and a piece of data vanishes without a word. Half Unicode characters left on their own, which encode nothing and break half the readers downstream. And the byte order mark at the head of a file, which the standard forbids adding.
How it works
- Paste your JSON. It does not leave your device, which matters for a data export or a configuration carrying identifiers.
- Choose the indentation, and key sorting if you plan to compare two files afterwards.
- If the JSON is invalid, read the line, the column and the expected token. If it is valid, read the alerts table: that is where duplicate keys hide.
Formats accepted
JSON as the standard defines it: no comments, no trailing comma before a closing brace, no unquoted keys. Those three departures are common, and the tool refuses them by name, because a program will refuse them too.
Text in JSON format
Up to 400,000 characters. The result downloads as .json or copies with one click.
Its limits
The tool applies the standard, without the tolerances some programs allow
Comments, trailing commas and unquoted keys are accepted by several development tools, but they are NOT JSON: the standard does not provide for them, and the program refusing your file is right. We do not accept them either, because a permissive validator would let you believe your file will pass elsewhere.
Duplicate keys are REPORTED, never fixed on your behalf
The standard says the names in an object should be unique, and that otherwise the behaviour of software receiving that data is unpredictable. In practice, almost every implementation keeps the LAST value: a piece of data vanishes without a word. The tool names them with their path and their line, but the formatted file reflects the same choice everyone makes, the last value, because doing otherwise would be a surprise.
A very large number can lose digits, and that is not our doing
The language browsers use can only represent integers exactly up to about nine million billion. An identifier larger than that written in a JSON file therefore loses digits the moment it is read, in any tool that goes through that language. That is why serious interfaces carry large identifiers as quoted strings, and if you see one bare in a file, the problem existed before us.
Key order is preserved, except for keys that look like numbers
A JavaScript object ALWAYS puts keys that read as integers first, in ascending order, whatever their original position. That is a rule of the language, not a choice of ours, and no tool that goes through that language escapes it. On an object whose keys are “10”, “2”, “1”, the original order is therefore lost. Saying so was better than keeping quiet.
Questions about this tool
Is my data sent anywhere?
No, and that matters here more than elsewhere: a JSON configuration often carries identifiers, internal addresses, sometimes access keys. Check it in thirty seconds: open the inspector with the F12 key, the “Network” tab, clear the list, then paste your JSON and validate it. Not one line appears. Cut your connection and do it again.
Why is my JSON with comments refused?
Because it is not JSON. The standard provides for no comments at all, and its author has explained that he removed them deliberately. Several development tools accept them for convenience, which keeps the confusion alive: your file passes on your machine and fails in production. We refuse for the same reason a validator must refuse: to tell you the truth about what your file is.
What is key sorting for?
For comparing. Two exports of the same data by two different programs often come out with the keys in a different order: a raw comparison then returns hundreds of false differences. Sort both, then paste them into the “Compare two texts” tool in the same corner: only the real differences will be left. It is the most useful trick on this page.
You mention duplicate keys: are they really allowed?
The standard says the names in an object “should” be unique, and that if they are not, the behaviour of software receiving the data becomes unpredictable. So it is neither forbidden nor safe. In practice almost every implementation keeps the last value and throws the first away without a word: if you have the key “price” twice in the same object, one of those two prices already does not exist. That is exactly the kind of problem people hunt for two hours, and it is why we report it.
My nineteen digit identifier changes after formatting.
Yes, and that is not our doing: it is a limit of the language every browser uses, which represents integers exactly only up to about nine million billion. Past that, the last digits change the moment they are read, in any tool that goes through that language. That is why serious interfaces carry large identifiers in quotes, as strings. If yours is bare in the file, the problem existed before you.
The parser is written here, by hand, rather than borrowed from the browser: because the browser's error message is normalised by no specification at all, and differs from one browser to the next. This one gives the line, the column, and what was expected, the same everywhere.
VerifyThe proof, step by stepThe network inspector check, explained one gesture at a time, with screenshots.
The cornerThe text and data cornerCount, compare, format, clean. The small jobs that cost an hour when you do not have them at hand.