JSON formatter

"Invalid JSON" is not an answer

Most JSON tools can tell you that a document is broken. Almost none of them tell you where. You paste four thousand lines of an API response, the page turns red, and you are told there was an unexpected token — somewhere. That is the same information you already had.

This formatter reports the line number, the column number, the actual line with a pointer under the offending character, one sentence about what is wrong and one about what to do next. It does that with its own parser rather than by catching the browser's error, because the browsers disagree. Chrome says Unexpected token } in JSON at position 12. Firefox says JSON.parse: expected ',' or '}' after property value. Safari says JSON Parse error: Expected '}' and gives no position whatsoever. A tool built on top of those strings would give you a different answer depending on which browser you happened to open it in.

What JSON is

JSON

Full name	JavaScript Object Notation
Extension	.json
Format type	Nested text data, six value kinds
MIME type	application/json

What actually makes JSON invalid

In practice it is nearly always one of five things, and all five are legal in JavaScript — which is exactly why they slip through.

The trailing comma. A comma after the last element of an array or the last property of an object. JavaScript allows it, Python allows it, your linter probably encourages it, and every diff you have ever written is cleaner because of it. JSON has never allowed it, and it accounts for more rejected files than the other four combined. It usually appears when a property is deleted by hand from the middle of a config file, or when a template loop writes a comma after every item including the last.

Single quotes. {'name': 'Ada'} is a perfectly good JavaScript object literal and it is not JSON. There is no single-quoted string in the format at all. This is the signature of something that was printed with console.log or copied out of a debugger rather than serialized.

Unquoted property names. {name: "Ada"} — again valid JavaScript, again not JSON. Every key is a string and every string is in double quotes. YAML, JSON5 and JavaScript all let the quotes go; JSON does not.

Comments. Douglas Crockford removed them from the spec deliberately, because people had started putting parsing directives in them. A // or a /* */ anywhere in a document makes it invalid, no matter how obviously it is a note to a human.

NaN, Infinity and undefined. JSON has no way to write a non-finite number and no way to write "no value" other than null. Python's own json module happily emits NaN and Infinity by default, which means a file produced by a standard library can be rejected by every strict parser that reads it. Pass allow_nan=False and the problem surfaces at the source instead of three systems downstream.

Two more show up often enough to name. A lone backslash inside a string — a Windows path like C:\Users or a regular expression — has to be doubled. And a pasted document sometimes carries a non-breaking space or a zero-width character that looks exactly like a space and is not one; that arrives from PDFs, chat clients and word processors. This tool names both instead of pointing vaguely at the line. The doubling catches people out in the other direction too: a pattern stored in a JSON config carries twice the backslashes it needs on its own, so paste the unescaped form into the regex tester when you want to know what the engine will actually receive.

There is a sixth case that is not invalid JSON at all, and it wastes an astonishing amount of time: the document is not JSON yet. A JSON Web Token, a webhook signature payload, a Kubernetes secret and half the fields in an OAuth response are JSON wrapped in base64 first, so the paste starts eyJ and every parser refuses it. Run it through a base64 decoder and the JSON falls out the other side, ready for this page. If the paste has two dots in it, it is a token rather than a lone blob, and the JWT decoder is the shorter route: it splits the segments, reads the expiry as a date instead of a ten-digit number, and points out the header fields worth worrying about.

JSON, JSONC and JSON5

If you have seen comments in a tsconfig.json and concluded that comments are fine, you have met JSONC. It is JSON with comments and trailing commas, it is what Visual Studio Code uses for its own configuration files, and it is understood by VS Code's parser — not by JSON.parse.

JSON5 goes considerably further: unquoted keys, single quotes, trailing commas, hexadecimal numbers, leading and trailing decimal points, multi-line strings. Both formats are supersets. Every JSON document is valid JSON5; a JSON5 document is usually not valid JSON. When a parser rejects a file that "works in my editor", the parser wants plain JSON and the editor was being generous.

Which of the three a given file actually is, is a separate question from formatting it, and it is the one worth answering first: the JSON validator next door names the dialect, points at the character that decided it, and gives the smallest change that would make the document plain JSON. This page assumes you already know and want it laid out.

XML is not another relaxed JSON spelling. Attributes, namespaces, repeated elements, ordered mixed content and CDATA need a mapping policy before they can become object keys and values. Use the XML formatter when the source must remain XML; this page will not flatten that document model under the label “formatting.”

Indentation, and why sorting keys matters

Two spaces is the convention almost everywhere in the JavaScript ecosystem; four is common in Python and Java tooling; tabs are what several Go and Make-based toolchains emit. Minified output — no line breaks, no spaces — is what you want when the JSON is going into a single environment variable, a URL, a database column or a request body. All four are one click apart here, and switching between them never asks you to paste the document again.

Sorting keys looks cosmetic and is not. Two API responses that contain identical data in a different property order produce a diff full of noise. Sort both recursively, indent both the same way, and then put the two documents side by side — what is left is the handful of values that actually changed, instead of a wall of red caused by a server that serializes its keys in hash order. The sort here goes all the way down, including objects nested inside arrays, and it is stable — so if a key genuinely appears twice, the two entries keep their original order relative to each other.

Indenting is for reading it as JSON, though, and quite often that is not the point. When the document is an array of objects — an export, a query result, a list of orders — the person waiting for it wants columns and a spreadsheet, not nesting. JSON to CSV flattens that shape into a table and shows which keys became which columns before you download anything, which is where the guessing normally goes wrong.

What this JSON formatter refuses to change

Most formatters run your text through JSON.parse and then JSON.stringify. That round trip quietly rewrites three things. Keys that look like integers get reordered, because JavaScript objects always list integer keys first: {"2":…,"1":…} comes back as {"1":…,"2":…}. Numbers with more than about seventeen digits — Twitter-style IDs, Snowflake IDs, some bank references — are silently rounded, so 12345678901234567890 returns as 12345678901234567000. And a key that appears twice loses one of its values without a word.

This tool parses the text itself and keeps all three intact: original key order, original digits, both duplicate entries — with a note on the receipt telling you the duplicate is there, because a duplicated key is nearly always a bug you want to see.

The same refusal to round shows up when records arrive as a spreadsheet export instead: CSV to JSON leaves a nineteen-digit identifier as a string rather than handing you a number that has lost its last four digits.

Why local processing matters for JSON specifically

Think about what the JSON you need to read usually is. An API response you are debugging. A configuration file. A webhook payload. A service account file. Those documents routinely contain bearer tokens, API keys, internal hostnames, email addresses and customer records — and the habit of pasting them into whichever formatter ranks first is one of the most common quiet data leaks in software work.

Nothing here is transmitted. The parser is JavaScript that runs in this tab, there is no upload endpoint, and you can confirm it yourself: open your browser's Network tab, then paste your document. No request will appear, because there is nowhere for one to go.

The machine you are debugging on is frequently not yours

Consulting work happens on the client's network, with the client's laptop, under the client's acceptable-use rules — and a fair number of those rules name outside beautifier and formatter sites by category, because a pasted payload is a copy of live data leaving the estate. Contractors, agencies, anyone carrying a second laptop for one account: that constraint arrives before the bug does, and it does not care that the response is four thousand lines long.

Students meet a flatter version of the same wall. A teaching lab has a fixed application list, no editor beyond whatever the course put there, and a profile discarded at logout, so an extension or a desktop viewer is not on offer even for one evening. A browser is. All of the above — the parser, the pointer under the offending character, the recursive sort, the minifier — arrives with the page and needs no permission from anyone, which is what makes it usable in the rooms where the interesting JSON actually turns up.