JSON Formatter

Format it, or find out why it won’t parse

Paste JSON and it is checked as you type. Valid documents are reindented and described; broken ones get a line, a column and a sentence saying what is actually wrong, with the offending line marked in the gutter.

Everything runs in your browser and nothing is uploaded — which matters here more than on most pages, because what people paste into a JSON formatter is usually a real API response with real data in it.

Where exactly is the error?

This is what half the visits to a JSON formatter are really about, and it is the thing most of them do worst.

The reason is that browsers disagree. JSON.parse throws an error whose message text is entirely up to the engine:

Chrome: Unexpected token } in JSON at position 47
Firefox: expected double-quoted property name at line 4 column 3
Safari: something different again

A tool built on that has to scrape a position out of prose, in three formats, and gets nothing at all on the fourth engine. So this one has its own parser. It walks the document once and knows precisely where it stopped, in every browser, and it names the specific fault rather than reporting an unexpected token.

The mistakes it names

Roughly in order of how often they turn up.

Trailing commas. {"a": 1,} is valid JavaScript and invalid JSON. This is the single most common cause, usually from hand-editing a list.

Single quotes. {'a': 1} — again fine in JavaScript, not JSON. JSON strings are double-quoted, keys included.

Unquoted keys. {a: 1}. JavaScript object literals allow it; JSON never does.

Values from another language. True, False, None, NULL, undefined and NaN all get named for what they are — usually a Python dict or a JavaScript object printed to a log rather than serialized.

A raw line break inside a string. Pasting multi-line text into a value breaks it; the fix is \n, and the tool says so at the line break rather than at the quote.

Comments. JSON has none. // and /* */ are both invalid, however many config files pretend otherwise.

Large numbers survive here

This is the quiet one, and it is worth understanding because it can corrupt data without any error at all.

JSON puts no limit on the size of a number. JavaScript numbers are 64-bit floats, which hold integers exactly only up to 9,007,199,254,740,991. Anything larger gets rounded to the nearest representable value.

So a formatter built the obvious way — parse, then stringify — does this:

{"id": 9007199254740993} in
{"id": 9007199254740992} out

A different ID, no warning, and a bug that surfaces days later in whatever system you pasted it into. This is not hypothetical: Twitter’s API famously had to add a second id_str field carrying every ID as a string, because JavaScript clients kept mangling the numeric one.

This tool never converts a number. It reindents the text around your values, leaving every digit exactly as written — and it tells you when a document contains numbers that other tools will change.

Key order and duplicate keys

Order is preserved by default. The JSON specification says object members are unordered, but that is a statement about the data model rather than about your file. Order is meaningful in a config, a changelog, or anything a person maintains, and reordering it makes every diff unreadable. There is a checkbox to sort alphabetically when you want exactly that — a stable order for comparison.

Duplicate keys are kept and flagged. {"a": 1, "a": 2} is legal JSON. The spec says the behavior is undefined; in practice nearly every parser keeps the last one, so JSON.parse silently gives you {"a": 2} and a formatter built on it can never tell you anything was wrong. This one keeps both copies and says so, because a document with duplicate keys almost certainly does not mean what it looks like.

Formatting versus minifying

Both change only whitespace, and neither touches a value.

Formatting adds newlines and indentation. Use it to read something, to diff two versions meaningfully, or to find your way around a response.

Minifying strips all of it. Use it to save bytes over the wire or to paste a payload into a single-line context. On a typical API response it saves 10–30%, though gzip recovers most of that anyway — the real reason to minify is usually that something needs it on one line.

Indentation is a matter of house style. Two spaces is the most common in JSON; four is easier to follow at depth; tabs let each reader choose. None of them is more correct.

What JSON does and does not have

Worth knowing, because most JSON errors are really someone expecting a feature that isn’t there.

Six types. Object, array, string, number, boolean, null. That is the entire set.

No comments. Douglas Crockford removed them deliberately, on the grounds that people were using them to carry parsing directives. JSON5 and JSONC add them back; neither is JSON.

No dates. There is no date type, which is why everyone uses an ISO 8601 string or a Unix timestamp — and why the timestamp converter exists.

No trailing commas, no single quotes, no unquoted keys, no undefined, no NaN, no Infinity. All of these are JavaScript, and the resemblance between JSON and JavaScript object syntax is exactly why they get typed.

Strings are UTF-8 and must escape control characters. A literal tab or newline inside a string is invalid; \t and \n are how you write them.

Privacy

The document you paste never leaves your browser — no upload, no request, nothing logged. It is also deliberately kept out of the page address, unlike the formatting settings: a URL is something people share, and a payload is not something you want to have shared by accident.

For turning the result into something transportable, use the Base64 encoder, or the copy-as-quoted-string button here.

Frequently asked questions

Where is the error in my JSON?

The tool reports the line, the column and what is actually wrong — a trailing comma, a single quote, an unquoted key — and marks the line in the gutter. It uses its own parser rather than the browser's, because JSON.parse throws a message whose wording differs between Chrome, Firefox and Safari and cannot be relied on for a position.

Why do large numbers change in other formatters?

Because most are built on JSON.parse and JSON.stringify, and JavaScript numbers are 64-bit floats. Any integer above 9,007,199,254,740,991 gets rounded — 9007199254740993 comes back as 9007199254740992, silently. This tool re-indents the text without ever converting a number, so what you paste is what you get.

Does it change the order of my keys?

Not unless you ask. Order is meaningful in a config file or anything a human maintains, so it is preserved by default; there is a checkbox to sort alphabetically when you want a stable diff.

What happens to duplicate keys?

They are kept, and flagged. Duplicate keys are legal JSON but almost every parser keeps only the last one, so a document containing them probably does not mean what it looks like — worth knowing rather than having them quietly removed.

Is my data uploaded anywhere?

No. Everything runs in your browser and nothing leaves the page — which matters, because the thing people paste into a JSON formatter is usually a real API response with real data in it. The document is deliberately kept out of the page address too.

What is the difference between formatting and minifying?

Both only touch whitespace. Formatting adds newlines and indentation so a human can read it; minifying removes all of it so a machine can transfer it in fewer bytes. Neither changes a single value.

Can I get the JSON as an escaped string?

Yes — the second copy button gives the whole document wrapped in quotes with the inner quotes escaped, ready to paste into a test fixture, a shell command or another JSON document.