What Is a JSON Formatter?
A JSON formatter, sometimes called a JSON beautifier, or a JSON validator when the focus is on catching errors rather than presentation, takes JSON text and re-outputs it with consistent indentation so it is easier to read. Because producing that output requires successfully parsing the input first, a formatter inherently doubles as a validator: if the document is malformed, formatting fails and reports exactly where. This tool works as a lightweight online JSON editor too: paste, tweak, and format JSON online entirely in the browser, with nothing uploaded to a server.
JSON Syntax Rules (RFC 8259 / ECMA-404)
JSON is formally specified by RFC 8259 (IETF, 2017), which obsoletes RFC 7159 (2014), which itself obsoleted the original RFC 4627 (2006). The grammar is independently specified by ECMA-404, "The JSON Data Interchange Syntax." The two specs are kept in sync but maintained by different standards bodies, which is itself a common source of confusion. A JSON document is exactly one value: an object, array, string, number, or one of the literals true, false, or null.
| Value type | Rule | Example |
|---|---|---|
| Object | Key-value pairs in { }, keys must be double-quoted strings | {"a": 1} |
| Array | Ordered values in [ ], any mix of value types allowed | [1, "a", true] |
| String | Double-quoted only; single quotes are not valid JSON | "hello" |
| Number | No leading zeros before more digits; no NaN or Infinity | -12.5, 3e10 |
| Literal | Exactly lowercase true, false, or null | true |
Formatting vs. Validating vs. Minifying: What's the Difference?
These three operations never change what the data means, only its presentation. Format is what most people mean by JSON pretty print; running Detect issues alongside it is effectively JSON lint, catching structural problems before they reach a build or an API consumer. The Minify action doubles as a standalone json minifier: switch to it and this tool will minify json by stripping every insignificant whitespace character, useful on its own even when you never need the pretty-printed view. A common source of "invalid JSON" confusion is pasting a JavaScript object literal and expecting it to be treated as JSON: unquoted keys, single-quoted strings, trailing commas, and undefined are all valid in a JS object literal but none of them are valid JSON, since JSON's grammar is a strict subset of JS object-literal syntax.
| Format | Minify | Sort Keys | |
|---|---|---|---|
| Purpose | Human readability | Reduce byte size | Deterministic ordering |
| Changes meaning? | No | No | No, object key order is not semantically significant per RFC 8259 |
| Typical use | Debugging, code review | Production payloads, embedding | Version-control diffs, config comparison |
Common JSON Errors and What They Mean
Most JSON syntax errors fall into a small number of categories, and the browser's own JSON.parse, which this tool uses directly rather than a hand-rolled parser, reports a character position for each one, which this tool translates into a line and column so you don't have to count characters by hand. Unexpected token in JSON is the single most common error message, and it almost always comes from one of two habits carried over from JavaScript: a trailing comma before a closing } or ] (a JSON trailing comma error, allowed in JS object/array literals but not in strict JSON), or single-quoted strings (JSON requires double quotes for both keys and string values), unquoted keys produce the same error for the same reason. "Unexpected end of JSON input" means the document ends before a structure was closed, a missing closing brace, bracket, or quote, often from a copy-paste that was clipped by a terminal scroll buffer or a line-length limit, an empty string is also not valid JSON at all and will produce this same error. JSON duplicate keys are a valid document, not a syntax error: RFC 8259 says object member names "SHOULD" be unique but explicitly leaves behavior undefined when they are not, and JSON.parse resolves it the same way a JS object literal does, the last occurrence wins and every earlier one is silently discarded, which is why this tool's issue detector scans the raw text separately to flag it as a warning even though the document parses without error.
JSON vs. JSON5 vs. JSONC vs. NDJSON
Several JSON-adjacent formats get confused with strict JSON because they look almost identical. None of the three below are valid input to this tool's strict JSON.parse-based validator; each is a distinct, separately-specified format. This tool validates syntax, whether the document is well-formed JSON, not shape: it does not check the data against a JSON Schema or any expected structure, pair it with a JSON Schema tool for that. It does not stream-parse extremely large files either, parsing and formatting happen synchronously via the browser's native JSON.parse/stringify, so a very large document (tens of MB) can briefly pause the tab, and it does not persist or save documents anywhere, nothing is uploaded and nothing is retained after you leave the page.
| Format | Comments? | Trailing commas? | Typical use |
|---|---|---|---|
| JSON (RFC 8259) | No | No | Data interchange, APIs |
| JSON5 | Yes | Yes | Hand-written config files (e.g. some build tool configs) |
| JSONC | Yes | No | Editor config files (e.g. VS Code's settings.json) |
| NDJSON / JSONL | No | N/A, one JSON value per line, not one document | Log streams, large record-by-record datasets |