JSON Formatter & Validator
Pretty-print, minify, and get a real line-and-column error when the JSON is malformed.
Everything strict JSON forbids
JSON is defined by RFC 8259 and it is deliberately austere. Every one of the following is a syntax error, even though a JavaScript object literal would accept it:
- Comments. Neither
//nor/* */is legal. Configuration formats that allow them — JSONC, JSON5 — are supersets, not JSON. - Trailing commas.
{"a": 1,}is invalid. This is the single most common cause of a broken config file. - Single quotes. Strings must use double quotes.
'a'is a parse error. - Unquoted keys.
{a: 1}is invalid; the key must be"a". NaN,Infinityand-Infinity. These are numbers in JavaScript and illegal in JSON. Usenullor a string.- Leading zeros and a leading
+.01and+1are both rejected. - Bare newlines inside strings. A literal line break must be written
\n.
The number precision trap
JSON numbers are IEEE 754 double-precision floats. That means every integer up to 2^53 (9,007,199,254,740,992) is exact, and beyond that values silently lose precision. A 19-digit database identifier or a snowflake ID round-trips to a different number, and nothing in the parser warns you. If your API carries large integers — Twitter/X IDs, Discord IDs, MongoDB ObjectIds in numeric form, financial amounts in minor units — send them as strings.
Duplicate keys and other silent surprises
- Duplicate keys are legal and the last one wins.
{"a":1,"a":2}parses to{a:2}with no error in most parsers. Some reject it; RFC 8259 calls the behaviour unpredictable. Lint for it. - Unicode escapes are optional.
\u00e9and the literal characteréare the same string. - Object key order is not guaranteed by the specification, though every mainstream implementation preserves insertion order in practice. Do not depend on it for signing or hashing — canonicalise first.
U+2028andU+2029are legal in JSON strings but were illegal in JavaScript source, a historical mismatch that broke JSON-in-<script>embedding.
Formatting versus minifying, and what actually reduces bytes
Pretty-printing adds indentation, newlines and spaces purely for human reading — it never changes the meaning. Minifying strips exactly those characters. The saving is typically 10 to 20 percent of an uncompressed payload, and close to zero if the response is gzip or Brotli compressed, because the compressor already removes redundant whitespace. Minify for readability in logs and for small JSON embedded in a URL; enable compression for transport.
For structured logs, prefer JSON Lines — one complete JSON value per line — over one giant array. A single malformed line then costs you one record instead of the whole file, and the format streams naturally.
How to use it
- Paste JSON, or drop a
.jsonfile. - Choose an indent of two spaces, four spaces, or a tab.
- Read the validation result — a syntax error is reported with its line and column.
- Minify if you need the compact form for embedding or logging.
Worth knowing
- Governing standard is RFC 8259, published December 2017.
- Integers above 2^53 lose precision as IEEE 754 doubles.
- Comments, trailing commas and single quotes are all invalid.
- Duplicate keys are accepted by most parsers with last-one-wins behaviour.
Limitations
- No JSON5, JSONC or JSON Lines parsing — strict RFC 8259 only.
- Large documents are bounded by available tab memory.
- Validation checks syntax, never a schema — use JSON Schema for structural rules.
- Property order is not normalised, so this output is not a canonical form for signing.