JSON Minify Compare
How it works
JSON minification removes all non-semantic whitespace (spaces, tabs, newlines) from a JSON document, producing the smallest possible valid JSON string. Comparing minified and pretty-printed versions side by side allows inspection of structural differences, while diffing two minified JSONs reveals semantic differences without whitespace noise.
**Why minification matters** API response size: a deeply nested JSON config with generous indentation can be 40–60% whitespace by byte count. Minification reduces bandwidth and improves parse speed for large payloads. Caching: minified JSON produces stable cache keys — two pretty-printed JSONs with different indentation levels would produce different hashes. Transmission: WebSocket and HTTP APIs transmit minified JSON; pretty-printing is a developer tool.
**Semantic equivalence verification** Parse both JSONs, serialize to canonical form (keys sorted, minimal whitespace), and compare byte-by-byte. If the canonical forms are identical, the JSONs are semantically equivalent regardless of whitespace, key order, or indentation style. Key ordering: standard JSON does not define object key order — two JSONs with the same keys in different order are semantically equivalent but string-compare as different.
**JSON canonicalization (JCS)** RFC 8785 defines JSON Canonicalization Scheme: sort keys lexicographically (Unicode code point order), remove insignificant whitespace, use specific number serialization (no trailing zeros, no unnecessary exponents). Canonical JSON enables reproducible signatures and content-addressable storage.
Frequently Asked Questions
- For human-authored JSON configs with 4-space indentation: typically 20–40% size reduction. For deeply nested structures with verbose indentation: up to 50–60%. For already-compact JSON (API responses from some systems): 5–10%. The savings come from removing spaces (indentation), newlines, and sometimes spaces around colons and commas. For large API response payloads (100KB+), minification meaningfully reduces bandwidth. For small payloads (<1KB), the gzip compression applied by HTTPS typically makes the raw size difference irrelevant.
- Canonical JSON (RFC 8785 JSON Canonicalization Scheme) defines a deterministic serialization: keys sorted lexicographically by Unicode code point, no insignificant whitespace, specific number format (no unnecessary exponents or trailing zeros). Canonical JSON is used for cryptographic signing — two JSON objects with identical data but different key orders or whitespace produce different byte sequences and thus different signatures. RFC 8785 ensures that sign(JSON(data)) verifies correctly regardless of which library serialized the JSON, as long as both use canonical form.
- Parse both JSONs and recursively compare their structures: objects are equal if they have the same keys with equal values (order-independent). Arrays are equal if they have the same elements in the same order (arrays are ordered). In Python: import json; a == b (after json.loads) performs semantic comparison. In JavaScript: JSON.stringify(normalize(a)) === JSON.stringify(normalize(b)) where normalize recursively sorts object keys. CLI: jq -S . file1.json > /tmp/a.json; jq -S . file2.json > /tmp/b.json; diff /tmp/a.json /tmp/b.json (the -S flag sorts keys).
- JSON5 (json5.org) is a superset of JSON that adds JavaScript-like syntax: comments (// and /* */), trailing commas in objects and arrays, single-quoted strings, unquoted keys (if valid JS identifiers), hexadecimal numbers, multi-line strings. JSON5 is used in some configuration files (Babel config .babelrc, Biome config biome.json5) where comments and trailing commas improve readability. JSON5 is NOT standard JSON — standard JSON parsers reject JSON5 files. Use JSON5 only for config files; use standard JSON for API data interchange.