JSON: formatting, validation and repair of what is broken
Paste an API response, a config or a fragment of a log — and you get a readable view, a tree and a list of everything that does not match the standard, with the exact line and position. Everything is parsed in your browser: the data is never sent anywhere and never stored.
.json here — the file is read locally. You can also paste what is not valid JSON yet: a log, an API response with comments, a fragment with trailing commas.
Keys and their order are preserved, the way numbers are written is unchanged.
Paste JSON above and press «Process».
Paste JSON above and press «Process».
The data never leaves your browser — parsing and formatting run locally, with nothing sent to a server.
Four editions of the standard and how they differ
JSON is described by several documents, and they are not identical. The choice of specification changes what the tool treats as an error. RFC 4627 (2006) — the original. A top-level document can only be an object or an array; a standalone number or string is not allowed. Some old libraries still rely on this edition. RFC 7159 (2014) — allowed any value at the top level. Since then 42 and "text" are self-contained JSON documents. RFC 8259 (2017) — the current one. It added the UTF-8 requirement for interchange between systems and settled that names within one object have to be unique. ECMA-404 — describes syntax only. It does not forbid duplicate keys and does not mention lone surrogates, so the set of warnings is the shortest here. When in doubt, keep RFC 8259: it is the strictest of the current rule sets, and whatever passes it will be accepted everywhere.
Why a parser of our own instead of the browser's JSON.parse
The built-in parser is made for speed, not for diagnostics. On the same data it stays silent where a tool should speak: A message with no coordinates. The browser says «Unexpected token» and an offset in characters; here you get the line, the position and what exactly was expected. One error for the whole document. After the first failure parsing recovers and shows the rest instead of making you fix them one at a time. Duplicate keys pass silently. JSON.parse keeps the last value, and the loss is noticed in production. The way numbers are written is lost. 1.0 becomes 1, and an integer above nine quadrillion changes its last digits — that is exactly how identifiers from a database break. The order of keys in the output stays as in the source until you ask for sorting yourself. Numbers here are printed by default exactly as they were written: the tool shows the document, not the result of interpreting it.
What exactly the fix mode repairs
Real data is rarely clean JSON. The repair mode brings what arrives from configs, logs and other people's APIs into line with the standard: comments // and /* */ are removed; commas before a closing bracket are dropped; single and curly quotes are normalised to double ones; unquoted and numeric keys are put in quotes; True, NULL, None, undefined become true, false, null; NaN and Infinity become null, because JSON has no numbers without a finite value; the way numbers are written — a stray plus, a dot at the edge, leading zeros; control characters inside strings are escaped; the BOM at the start of the file and the JSONP wrapper are stripped. No fix is made silently: each one goes into the list with the number of cases. If the result does not suit you, switch the checkbox off and the document is checked as it is.