Format JSON, and find the line the mistake is on
Paste a document into the panel above and it is read as you type. When it is good you get it laid out at two spaces, four spaces or tabs, or squeezed flat, with a count of names and values and how deep it goes. When it is not, you get the line number, the column number, the character the reader stopped on with a caret under it, and a sentence saying what was wrong in words rather than a token name. Numbers are written back exactly as you wrote them.
Check a JSON document and find out where it broke
Paste a document and it is read as you type. If it is good you get it laid out or squeezed flat, with every number written exactly as you wrote it; if it is not, you get the line and the column and the character the reader stopped on, which is the part the browser will not tell you.
Your document is not uploaded. It is read by this page, in a background task beside it, and there is no code here that could send it anywhere. Laying it out or squeezing it flat changes the whitespace and nothing else: numbers keep the digits you wrote, so a long identifier or a price written with a trailing zero comes back the way it went in, which is not true of anything built on the browser's own parser.
JSON formatter, step by step
- Paste the documentIt is read as you type, in a background task, so a large one does not lock the box up while you are still pasting.
- Read the verdictEither a count of what is in it, or the line and column with the offending piece printed underneath and a caret under the character.
- Lay it out or squeeze it flatThen copy it or save it. Only the whitespace changes, so nothing in the document is different afterwards.
What the browser tells you when JSON will not parse, and why it is no help
Every browser has a JSON reader built in and it is the fastest correct one on the machine. It is also the worst thing to build a validator on, for two reasons. The first is the message. Given a document with a stray comma before a closing brace, one engine answers that there was an unexpected token at position 12 and another answers that a quote was expected instead of a brace. Neither gives a line, neither gives a column, and neither agrees with the other, so a page that repeats whatever the browser said reports something useful in one browser and something useless in the next. The reader here works out where it is as it goes, so the answer is the same in every browser by construction, and it points at the comma you have to delete rather than at the brace that noticed. The second reason is arithmetic. Reading a document into values and writing it back out puts every number through a double, and a double holds about fifteen significant digits: a long order reference comes back rounded and a price written with a trailing zero comes back without it. Laying out a document here is done from the pieces it was read as, with every number and every string kept as the characters that were typed, so the only thing a reformat changes is the whitespace.
There are a great many pages offering to make JSON pretty, and the reason is that making JSON pretty is one line of code. Reading a document into values and writing it back out with an indent is built into every browser, so a page that does only that is a text box and an afternoon.
Nobody arrives at one of those pages because their document is ugly. They arrive because something has rejected it and the something in question said very little about why. That is the job worth doing well, and it is the part almost every tool of this kind skips, because the built-in reader throws away the position before it hands you the error.
So this one reads the document itself and keeps count of where it is. When it stops, it can tell you the line and the column, print the line, and put a caret under the character. It also means the laying out can be done on the text rather than on the values, which is what stops your long identifiers being quietly rounded on the way through.
Questions
Why is the error here different from the one in my console?
Because it is not the same reader. The browser has one built in and its message is engine specific, carries no line and no column, and points at wherever it happened to notice rather than at the mistake. This page reads the document itself and keeps track of where it is, so it can say line four, column nine, and print the line with a caret under the character. The two disagreeing does not mean one of them is wrong about the document.
Will laying it out change any of my numbers?
No, and that is worth checking on other tools because most of them do. Anything built on reading a document into values and writing them back out sends every number through a floating point double, which holds about fifteen digits, so a twenty digit identifier is silently rounded and a value written as 1.50 comes back as 1.5. Here the digits you wrote are the digits that come out, because formatting works on the text rather than on the value.
My file is all on one line. Is the column number any use?
It is, because the offending region is printed as well. A file with no line breaks is one very long line, so the column is a character count into it, and rather than making you count that far the panel prints a window of the text around the fault with a caret under the exact character. Search your editor for the fragment shown and you are in the right place.
Does it accept comments, or a trailing comma?
No, and it names them when it finds them rather than reporting a stray character. Neither is legal JSON, though plenty of tools that read configuration files accept both and that is why they turn up. Being told that the thing under the caret is a comment, or that there is a comma with nothing after it, is more useful than being told a slash was unexpected.
Other things here
There is a full list on the free tools page. They all work the same way: in the browser, with nothing to install.