JSON Formatter
Validate, pretty-print and minify
JSON is deliberately small: objects, arrays, strings, numbers, booleans and null, and nothing else. There are no comments, no trailing commas, no single quotes and no date type. That minimalism is why it is implemented everywhere consistently, and also why a single stray comma produces a parse error rather than a best guess.
Formatting serves two opposite needs. Pretty-printing with indentation makes a payload readable while you are debugging it; minifying strips every unnecessary byte for transport. Validation is the part that matters most in practice — knowing not just that a document is broken but exactly where, which is what a line and column number gives you.
How to use it
- Paste the JSONAn API response, a config file, a log line. Parsing happens in this tab, which matters when the payload contains anything you would rather not paste into someone else’s server.
- Read the error position if it failsErrors are reported at the line and column where parsing stopped. That position is where the parser gave up, which is usually just after the actual mistake.
- Pretty-print or minifyIndent for reading and diffing; minify for embedding in a single line or measuring true payload size.
Frequently asked questions
Why is my JSON invalid when it looks fine?
The usual suspects are a trailing comma after the last element, single quotes instead of double, unquoted keys, or a comment. All four are legal in JavaScript object literals and none are legal in JSON, which is why hand-edited config files fail so often. An unescaped newline inside a string is the other frequent cause.
Can JSON contain comments?
No. Douglas Crockford removed them deliberately, having seen comments abused to carry parsing directives. Formats such as JSON5 and JSONC add them back, and tools like VS Code accept JSONC for their own config, but a standard parser will reject a comment outright.
How should dates be represented in JSON?
There is no date type, so a date is either a string or a number. The convention is an ISO 8601 string in UTC, such as 2026-08-27T10:30:00Z, because it is unambiguous, sorts lexicographically and is readable. Epoch integers are compact but hide their units, and a bare date with no zone is ambiguous.
Are large numbers safe in JSON?
Not always. JSON itself places no limit, but most parsers map numbers onto IEEE 754 doubles, which lose integer precision beyond 2^53. A 64-bit database ID can round to a different value on parse — silently. The standard workaround is to transmit such identifiers as strings.
Does key order matter?
Not to the specification: an object is an unordered set of pairs, and parsers are free to reorder. In practice most preserve insertion order, and this tool does too, because a reordered document is far harder to diff. Never write code that depends on it.