You have a lump of JSON that will not parse, and the only thing your program will tell you is something like Unexpected token } at position 4127. Nobody can work with that. Paste it below and it will tell you the line, the column, and what is actually wrong, in words.
Do not worry, and do not go through it character by character. Broken JSON is nearly always one of about eight small things, and a trailing comma accounts for more of them than everything else put together. It is also not your fault that the error message was no use. Almost every one of them counts characters from the start of the file instead of giving you a line number.
Nothing you paste leaves your browser. The checking happens on your own computer, so there is no upload and no server. That matters here more than on most tools, because the thing people usually paste into a JSON formatter is an API response, and an API response often has a token, an email address or a customer order sitting in it.
Checked in your browser. Nothing is uploaded, and nothing is stored.
Three things this does that most JSON formatters cannot
Nearly every JSON tool on the web is a thin wrapper around the browser’s own JSON.parse. That is fine for the easy job of adding indentation, but it makes three specific problems invisible, and two of them lose your data quietly.
1. It tells you where the problem is
JSON.parse gives a different error message in every browser, and none of them give you a line number. Chrome counts characters from the start of the file, which is no use in a file with four thousand of them. Firefox words it differently again.
This one reads the JSON itself rather than handing it to the browser, so it can point at the exact character. It prints the line, puts a caret underneath the spot, and then says in plain words what it found, such as a trailing comma before a closing brace or a key that has no quotes around it.
Where it stops. It reports the first problem, not all of them. Once a file goes wrong, everything after that point is guesswork, and tools that list ten errors are mostly listing nine imaginary ones caused by the first. Fix the one it shows you and check again.
2. It tells you when the same key appears twice
This is valid JSON:
{ "id": 1, "id": 2 }Every program that reads it will keep 2 and throw 1 away without telling anyone. No error, no warning, nothing in the log. If two systems merged their output into one file and both wrote an id, one of those values has already gone and you will never see the moment it happened.
Think of it like two people writing on the same line of a form. The second one wins and the first is simply not there any more. This tool says the file is valid, because it is, and then tells you which line repeated which key.
Where it stops. It cannot tell you which of the two values was the right one. That depends on what wrote the file, and only you know that.
3. It does not quietly change your long numbers
This is the one that catches people out, and it is worth trying yourself. Take this:
{ "order": 12345678901234567890 }Run that through most online JSON formatters and what comes back is 12345678901234567000. The last three digits are gone. Your order number now points at a different order, or at nothing.
It happens because JavaScript can only hold whole numbers exactly up to 9,007,199,254,740,991. Past that it starts rounding, and any tool built on JSON.parse has already done the damage before it prints anything. Snowflake IDs, Twitter IDs, Stripe object numbers and most database bigint columns are all past that line.
This tool never turns your digits into a number at all. It carries the text through exactly as you typed it, so formatting a file cannot corrupt it, and it warns you when a number is in the dangerous range.
Where it stops. Keeping the digits safe here does not make them safe everywhere. Whatever reads the file after you will very likely still round it. The real fix is to put long IDs in quotes so they travel as text, and the warning says so.
The mistakes it will name for you
These are the ones that come up again and again, nearly always because the text started life as JavaScript, or came out of a document rather than a file.
- A trailing comma.
{"a": 1,}is fine in JavaScript and in most programming languages. JSON forbids it. This is the single most common reason a file will not parse. - Single quotes.
{'a': 1}is JavaScript, not JSON. JSON only has double quotes, for keys as well as values. - A key with no quotes.
{a: 1}is again valid JavaScript and not valid JSON. Every key needs double quotes round it. - Comments. JSON has none at all, neither
//nor the slash star kind. This surprises people more than anything else on the list. - Curly quotes. If you edited the file in Word, Google Docs or Notes, your straight quotes have been turned into the slanted kind and nothing will parse. You cannot see the difference at a glance, which is what makes it maddening.
- NaN, Infinity and undefined. All three exist in JavaScript. None of them exist in JSON. Use
null. - A number with a leading zero.
007is not a valid JSON number. If it is a postcode, a phone number or an ID, it was always text and it needs quotes. - An invisible mark at the start. Some Windows editors add a byte order mark when they save. You cannot see it, and plenty of parsers refuse the file on character one because of it.
- Two documents in one file. A JSON file holds exactly one value. Two objects one after the other need to be inside a list, with a comma between them.
The repair button, and when not to trust it
When the tool spots a problem it knows how to mend, it offers to mend it. That covers single quotes, curly quotes, comments, trailing commas, keys with no quotes, and NaN or undefined becoming null.
It lists every change it made, so you never have to take it on trust. Read that list before you use the result. That is the whole reason the list is there.
Where it stops, and this one matters. It will not guess at a missing bracket. If a brace or a square bracket is absent, there is usually more than one place it could go, and the two versions mean genuinely different things. A tool that picks one for you and says nothing is worse than a tool that admits it does not know. It also cannot know whether undefined in your file meant null, meant zero, or meant that the key should not be there at all, so check anything it changed to null yourself.
Formatting, minifying and sorting
Indentation can be two spaces, four spaces or a tab. Two spaces is what most JavaScript projects use and what almost every code formatter produces by default.
Minify strips every space and line break out. It is what you want before sending JSON over a network or storing it, and it typically takes twenty to forty percent off the size of a formatted file, though how much depends entirely on how deeply nested it is.
Sort keys A to Z puts every object’s keys in alphabetical order. It is genuinely useful for one job: comparing two files that hold the same data in a different order. Sort both and the difference between them is the real difference rather than the shuffling.
Where it stops. Sorting changes the order the keys are written in. JSON says key order carries no meaning, and almost every program agrees, but a few systems do read the file in order. If yours is one of them, format without sorting.
Frequently asked questions
Is my JSON sent anywhere?
No. It runs in your browser and there is no upload of any kind. You can check that for yourself rather than believing me: open your browser’s developer tools, go to the Network tab, and paste something in. Nothing is sent. You can also turn off your internet and the tool carries on working.
Is there a size limit?
No fixed one, because the work happens on your own computer. Files of a few megabytes are fine. Somewhere past that your browser will start to feel slow, and on a phone it will happen sooner than on a laptop. If you are working with something very large, a command line tool on your own machine is the better answer.
Why does it say my file is valid when my program still rejects it?
Usually because your program wants a particular shape, not just valid JSON. A file can be perfectly formed and still be missing a field that something expects, or have a number where a string was wanted. That is a schema problem rather than a syntax problem, and this tool only checks syntax.
The other common cause is that you pasted part of the file. Copying from a terminal that has wrapped or truncated the output is a very easy mistake to make.
What is the difference between a JSON formatter and a JSON validator?
In practice, nothing. Formatting a file means reading it first, and reading it means finding out whether it is valid. Any tool that can indent your JSON has already validated it, whether it says so or not. This page does both jobs and tells you about both.
Does it work with JSON Lines or JSON5?
No, and it will say so rather than pretending. JSON Lines is one object per line with no commas and no wrapping brackets, so this tool will report something after the end of the JSON. Put square brackets round the whole thing and commas between the lines and it will read.
JSON5 allows comments, trailing commas and unquoted keys on purpose. This tool treats all of those as errors, because in plain JSON they are. The repair button will turn most JSON5 into ordinary JSON if that is what you want.
If you have any issues, you can ask me via comment, and I will love to help you out.