JSON formatter and validator.

A JSON formatter takes compact or messy JSON and rewrites it with consistent indentation so people can read it. A JSON validator checks that the text follows the JSON grammar at all. This tool does both: it validates on every keystroke, then formats with 2 spaces, 4 spaces or tabs, minifies to a single line, or shows the data as a collapsible tree.

Under the hood there are two steps. A small scanner written for this page walks your text character by character and stops at the first rule it breaks, so it can report a plain-English message with an exact line and column. Browsers word JSON.parse errors differently and some omit the position, so the scanner gives the same answer in every browser. Once the text is valid, the browser's own JSON.parse builds the value and JSON.stringify writes the formatted or minified output.

If you work with JSON every day, you are probably reading API responses, config files or log lines. Formatting makes them reviewable; validation tells you why a parser rejected them.

JSON is defined by RFC 8259 and ECMA-404. A JSON text is one value: an object, an array, a string, a number, or one of the literals true, false and null. Since RFC 8259 the top-level value can be any of these, not only an object or array, so a bare "hello" or 42 is valid JSON.

The rules are strict. Object keys must be strings in double quotes. Strings use double quotes only, and line breaks, tabs and other control characters inside them must be escaped as \n, \t or \u0000-style sequences. Numbers are decimal: no leading zeros (01), no leading plus sign, no hexadecimal, and no NaN or Infinity. The literals are lowercase. Commas separate items but may not follow the last one, and there is no syntax for comments.

Two softer rules matter too. JSON exchanged between systems should be encoded as UTF-8, and the names in an object SHOULD be unique. The specification does not say what happens with duplicates, so different parsers behave differently.

Trailing commas are the most common error, usually left behind after deleting the last item of a list. Next come single-quoted strings and unquoted keys, which are fine in JavaScript object literals but not in JSON. Pasting a Python dict gives True, False and None, which must become true, false and null.

A missing comma between two properties is reported at the start of the second one, because that is where the parser first notices something is wrong. The same applies to a missing closing bracket: the error often points further down than the real mistake, so read the line above too.

"Unexpected token < in JSON at position 0" (or "is not valid JSON" in newer browsers) means the response was not JSON at all. It is usually an HTML error page, a login redirect or a proxy message. Check the status code and Content-Type header of the response rather than the JSON itself; the REST API design best practices guide covers returning JSON errors consistently.

"Unexpected content after the JSON value" means two documents are glued together. That is normal for JSON Lines (NDJSON), where each line is its own document: validate one line at a time.

Format and Minify parse your JSON into a JavaScript value and write it back out, so the output is equivalent data, not a character-for-character copy with new whitespace. In everyday payloads you will not notice. In a few cases you will.

Numbers become JavaScript doubles. Integers above 9,007,199,254,740,991 (2^53 - 1) lose precision, 1.50 becomes 1.5 and 1e3 becomes 1000. Escapes are normalised, so "\u00e9" is written as é. With duplicate keys only the last value survives. Keys that look like non-negative integers, such as "2" and "10", move to the front of their object in ascending order, because that is how JavaScript orders object properties.

If any of that matters, for example in a signed payload or a file you diff byte by byte, use the validator only and keep your original text. To compare two versions of a document after formatting both, use the text diff checker.

JSON5 and JSONC (JSON with comments, used by many editor and TypeScript config files) relax the rules: comments, trailing commas and, in JSON5, single quotes and unquoted keys. They are convenient for hand-edited config, but a strict JSON parser will reject them, which is exactly what this validator reports.

YAML is a superset of JSON aimed at human-written config, with indentation instead of brackets. NDJSON stores one JSON document per line for logs and streaming. For typed code, the JSON to TypeScript converter turns a sample payload into interfaces you can paste into a project.

With this one, yes. Validation, formatting and the tree view run in JavaScript inside your browser tab. There is no upload step, no account and no server-side processing, so internal API responses and customer records never leave your machine. You can confirm it by opening your browser's developer tools and watching the Network tab while you format.

Very large documents of many megabytes format quickly, but the tree view renders every node, so it can become slow. Use the text view for those.