JSON Formatter
Format, validate, and beautify JSON data. Spot syntax errors instantly.
What this tool does
It parses the JSON you paste and prints it back out. Format indents it for reading, Minify strips every unnecessary space, and Validate runs the parser without changing anything so you can find out whether the document is legal.
Because it parses rather than prettifies text, it can also tell you something a text editor cannot: whether the document is valid JSON at all, and where the parser gave up. That distinction matters, because a file that looks broken and a file that is genuinely invalid are different problems.
How to use it
- Paste JSON into the top box.
- Click Validate to check it parses, Format to indent it, or Minify to compact it.
- Read the error line when validation fails - the parser reports the position where it stopped understanding the document.
- Click Copy to take the result.
What JSON actually allows
JSON is deliberately small. These six rules cover essentially everything a parser will reject, and most "broken JSON" is one of them:
| Rule | Valid | Invalid |
|---|---|---|
| Keys must be double-quoted | {"a": 1} | {a: 1}, {'a': 1} |
| No trailing commas | [1, 2] | [1, 2,], {"a":1,} |
| No comments | remove them | {"a":1} // note |
| No leading plus or zero padding | 1, 0.5 | +1, 01 |
| No NaN or Infinity | null | NaN, Infinity |
| Top level may be any value | "text", 42, [] | - |
The last row surprises people who learned JSON a decade ago: the original specification
required an object or an array at the top level, and the current standard allows any value. So a
bare 42 is valid JSON. Some older parsers still refuse it, which is a useful thing
to know when one system accepts your file and another does not.
The limits that are not syntax errors
This is the part that costs real money. A document can be perfectly valid JSON and still not mean what you think:
- Numbers have a precision limit. JSON places no restriction on number size, but most parsers - including JavaScript's - store them as 64-bit floating point. Values beyond 9,007,199,254,740,991 lose precision silently: the integer 9007199254740993 parses back as 9007199254740992. This is the standard reason identifiers break when they pass through a JavaScript system, and the fix is to send them as strings.
- Duplicate keys are legal to write and lossy to read. The document
{"a":1,"a":2}parses without complaint, and the last value wins, so the first is simply gone. No error, no warning. - Order is not guaranteed for objects. JSON objects are unordered by definition; if your code depends on key order, it is depending on an implementation detail of the parser in front of you.
- Dates are strings. JSON has no date type. Every system invents its own convention, and mismatched conventions are a classic source of bugs. An ISO 8601 string is the safest choice - this site's timestamp converter handles the other popular option.
- Whitespace is not significant. Formatting changes the file, never the meaning, so a diff full of indentation changes is telling you nothing about the data.
Why formatting is worth doing
Minified JSON is smaller and faster to transfer, which is why APIs send it that way. It is also unreadable, which is why you should never debug against it. Formatting restores the structure your eyes need: nesting becomes visible as indentation, so a value at the wrong level - the classic missing or extra brace - stands out immediately instead of hiding in a wall of text.
Two habits pay off. Format first, then read: an error you can see is worth more than an error you have to hunt. And when two versions of a payload are in front of you, the diff checker will show exactly what changed between them, which is faster than comparing two blocks of JSON by eye.
Pasting JSON from a log or a config file
Not everything between braces is JSON, and knowing which of these you are holding saves a frustrating half hour:
| Thing | Is it JSON? | Why it fails |
|---|---|---|
| JSON5, relaxed JSON with comments | No | Comments, unquoted keys and trailing commas are all rejected |
| JavaScript object literal | Usually not | Functions, undefined and single quotes are not JSON |
| A JSON string inside a log line | Only after unescaping | The whole document is one escaped string, and its quotes are backslashed |
| A YAML or TOML config | No | Different language entirely |
| A binary or compressed response | No | It is bytes, not text - decode it first |
When a paste fails and the text looks right, the usual cause is that you have copied a string containing JSON rather than JSON itself: every quote inside is preceded by a backslash. Decoding that once turns it into the document you expected.
FAQ
What is the difference between format and minify?
Formatting adds indentation and line breaks so the structure is readable but the file is larger. Minifying removes every unnecessary space so the file is as small as possible. The parsed data is identical in both cases.
What does the Validate button actually check?
That the document parses as JSON according to the specification. It reports where the parser stopped if it fails, and changes nothing about your input.
Why does my JSON fail to parse?
The most common causes are unquoted or single-quoted keys, a trailing comma before a closing brace or bracket, comments, and values such as NaN or Infinity. All of these are rejected by the JSON grammar.
Why did a large number come back slightly different?
JSON has no limit on number size, but most parsers store numbers as 64-bit floating point, which is exact only up to 9,007,199,254,740,991. Larger integers lose precision silently, so identifiers should be sent as strings.
Can JSON have comments?
No. The JSON grammar has no comment syntax, so a file containing // or /* */ is not valid JSON. Formats such as JSON5 and JSONC allow them, but a standard parser will reject the document.