JSON formatting as a family of operations
JSON is a data-interchange format, not a display format. The same object graph can be serialized with different whitespace, key order, and nesting style while remaining semantically equivalent under ECMA-404 / RFC 8259. Teams therefore need more than one transform: indent for humans, collapse for transport, stabilize key order for digests and diffs, and combine documents without losing nested structure.
This hub covers those related operations. Start with Pretty-print JSON when you need readable indentation and immediate syntax feedback; the siblings below address minify, canonicalization, and deep merge.
Why whitespace and key order matter
Parsers ignore insignificant whitespace. Humans and line-oriented tools do not. Pretty-printed JSON makes nested arrays and objects scannable in reviews and support tickets. Minified JSON reduces payload size on the wire and in logs. Neither change alters values—only presentation.
Key order is subtler. The JSON data model treats objects as unordered collections of name/value pairs, but many serializers emit keys in insertion order, and some ecosystems (notably certain cryptographic and content-addressing schemes) require a deterministic encoding. If you hash or compare raw JSON text, two documents with the same members but different key sequences produce different digests. Canonicalization exists to close that gap before hashing, caching, or snapshot tests.
Subtools in this family
- Pretty-print JSON — parse valid JSON and re-emit it with indentation and line breaks for reading and debugging.
- Minify JSON — remove unnecessary whitespace so the document fits on one line (or a compact stream) for APIs and storage.
- Canonical JSON — sort object keys recursively so two equivalent objects serialize to the same byte sequence (subject to the tool’s canonical rules).
- Deep merge JSON — combine two JSON objects by walking nested objects rather than replacing whole branches at the top level.
Choose pretty-print or minify when you only care about layout. Choose canonical JSON when stability of the serialized form matters. Choose deep merge when configuration or patch-style overlays need nested combination.
Pretty-print versus minify
Pretty-print expands structure: each nesting level gains consistent indent, arrays and objects gain line breaks, and trailing commas are never introduced (JSON forbids them). The operation fails if the input is not parseable—formatting is not a best-effort “fix my broken JSON” tool; it is a round-trip through a parser.
Minify is the inverse layout transform: after a successful parse, the serializer emits the compact form without indentation or cosmetic newlines. Numbers, strings, and boolean/null literals keep their JSON encodings; only insignificant whitespace disappears. Minifying already-compact JSON is a no-op aside from normalizing how the serializer reprints values (for example, how it chooses to represent a number).
In pipelines, pretty-print often sits next to editors and code review; minify sits next to Content-Type: application/json responses, message queues, and size-sensitive caches. Running pretty-print then minify (or the reverse) should preserve the parsed value graph when both steps use a standards-compliant parser.
Canonical JSON and stable digests
Canonicalization typically:
- Parses the input into an in-memory value.
- Recursively sorts object keys (commonly lexicographic by Unicode code point of the key string).
- Serializes with a fixed whitespace policy (often no insignificant whitespace) and consistent number/string encoding rules.
That stable string is what you hash with SHA-256, store as a cache key, or commit as a golden fixture. Without it, “semantically equal” fixtures flake when a library changes enumeration order.
Canonical JSON is not a substitute for schema validation. Two documents can canonicalize to different strings yet both be valid against a loose schema, or match as strings while violating business rules. Use validation elsewhere when structure constraints matter; use canonicalization when byte-level identity of the encoding matters.
Watch floating-point serialization and duplicate keys in non-compliant input (parsers disagree on which value wins). Stick to values representable in JSON.
Deep merge semantics
A shallow merge replaces top-level keys from the second object over the first. A deep merge walks into nested plain objects and merges those recursively, while typically replacing arrays and scalar values wholesale when both sides define the same key:
- Objects combine key-by-key.
- Arrays usually do not element-wise merge unless a tool documents that behavior.
- Scalars on the right overwrite the left.
Deep merge suits layered configuration (defaults ← environment ← user overrides) and partial API overlays. It is a poor fit for list append semantics or JSON Patch (RFC 6902). Last-writer-wins merge can silently drop left-hand nested keys when the right-hand side replaces a subtree with a scalar—validate merged results when settings are safety-critical.
Parse errors and unsafe input
All four tools begin with parsing. Classic failures include trailing commas, single-quoted strings, unquoted keys, NaN/Infinity, and comments—none valid in standard JSON. Cap size before parse in services; do not eval JSON as JavaScript. Browser-side formatting keeps data on-device, but pasted secrets still appear in memory and screenshots.
Practical workflows
- Debug an API body: pretty-print → inspect → minify before sending again.
- Snapshot a config for git: canonical-json so diffs reflect real changes, not key reshuffles.
- Compose overlays: deep-merge defaults with overrides, then pretty-print for review.
- Integrity check: canonical-json → hash when both sides share the same canonical rules.
Limitations of the family
These tools reshape and combine JSON text; they do not enforce JSON Schema or OpenAPI, convert YAML/XML, or redact secrets. Prefer streaming CLI tooling for multi-megabyte artifacts.
Related ideas
For syntax-only accept/reject, see Valid JSON. For JSON↔XML trees, see From JSON to XML. Validate or parse first, then choose a layout or merge strategy.