creatorvalet

JSON formatter and validator

Paste JSON and read it. Invalid input gets the line, the column and the line itself.

Runs in your browser0 bytes uploaded
Waiting
Size
Line
Column
Indent
№ 2373waiting

Nothing at the counter yet. Paste JSON, or drop a .json file anywhere on the panel to the left.

"Invalid JSON" is not an answer

Most JSON tools can tell you that a document is broken. Almost none of them tell youwhere. 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 saysUnexpected token } in JSON at position 12. Firefox saysJSON.parse: expected ',' or '}' after property value. Safari saysJSON 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 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 withconsole.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 ownjson module happily emits NaN and Infinityby 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.

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.

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 and the diff collapses to the handful of values that actually changed. 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.

What this JSON formatter refuses to change

Most formatters run your text through JSON.parse and thenJSON.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, so12345678901234567890 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.

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.

Questions

Why does my JSON fail when it looks perfectly fine?

Five things account for almost every failure: a trailing comma after the last item, single quotes instead of double quotes, property names without quotes, comments, and NaN or Infinity where a number should be. All five are legal in JavaScript, and none of them are legal in JSON. This tool names which one it found and points at the character.

What is the difference between JSON, JSONC and JSON5?

JSONC is JSON with comments — it is what VS Code uses for tsconfig.json and settings.json. JSON5 goes further and allows unquoted keys, single quotes, trailing commas and hexadecimal numbers. Both are supersets: every JSON document is valid JSON5, but a JSON5 document is usually not valid JSON. If a file with comments is rejected by a parser, that parser wants plain JSON.

Is my JSON sent to a server?

No. The parser runs in this tab and there is no upload endpoint to send it to. That matters more here than for most formats — the JSON people need to read is usually an API response or a config file, which means it routinely contains API keys, access tokens, internal hostnames and customer records.