JSON won because it is boring. Six value types, two container types, no comments, no schema, no ambiguity. That simplicity is also why a single misplaced comma can take twenty minutes out of your afternoon when the payload is 4,000 lines long and arrived as one unbroken string.
Here are the habits that make JSON quick to work with, and the traps that catch people repeatedly.
Pretty-print first, debug second
When an API returns a minified blob, do not squint at it. Paste it into the JSON Formatter and get properly indented, colour-delimited output. Structure becomes visible immediately: nesting depth, array lengths, which fields are null, and where the shape diverges from what you expected.
Two-space indentation is the de-facto standard — four wastes horizontal space at depth, tabs render inconsistently across tools. Whatever you choose, be consistent within a repository.
Validate before you blame the network
Most "the API is broken" incidents are actually malformed JSON, and the parser error message points to a character offset rather than a human explanation. A formatter that validates tells you the line and what it expected.
The recurring offenders:
Trailing commas. {"a": 1, "b": 2,} is valid JavaScript and invalid JSON. This is the single most common error, and it appears constantly in hand-edited config files.
Single quotes. JSON requires double quotes on both keys and string values. {'name': 'value'} is not JSON.
Unquoted keys. {name: "value"} is a JavaScript object literal, not JSON.
Comments. JSON has none. // and /* */ both break the parse. If you need annotated config, use JSON5, YAML or TOML, and convert at build time.
Unescaped characters in strings. Literal newlines, tabs, backslashes and double quotes must be escaped as \n, \t, \\ and \". Windows paths are the usual culprit: "C:\Users\me" fails, "C:\\Users\\me" works.
NaN, Infinity and undefined. None exist in JSON. Serialise them as null or as strings, and decide deliberately which.
A BOM at the start of the file. Invisible, and it makes strict parsers reject byte one. Save as UTF-8 without BOM.
Minify for the wire, format for humans
Whitespace in a JSON response is bytes you pay for on every single request. For a large payload delivered thousands of times a day, minification is free performance.
But do not minify what humans edit. Config files, fixtures and seed data belong pretty-printed in version control, because a minified file produces a one-line diff on every change and makes code review impossible.
The rule: minify at the boundary, format in the repository. The JSON Formatter does both — toggle between prettify and minify and copy the result.
Note that gzip and brotli already compress repetitive whitespace extremely well, so the real-world saving from minification over a compressed connection is smaller than the raw byte difference suggests. Measure before optimising.
Keep diffs reviewable
Two habits make JSON pleasant in version control:
Sort keys consistently. Serialisers that emit keys in insertion order produce spurious diffs whenever code changes order. Sorting alphabetically makes every diff meaningful.
End files with a newline. Otherwise every tool that adds one creates a phantom change on the last line.
Numbers deserve caution
JSON numbers are IEEE 754 doubles in practice. Integers above 2^53 lose precision silently — a real problem with database IDs, Twitter-style snowflake IDs, and financial values in the smallest currency unit.
If your IDs are large integers, transmit them as strings. Every mature API does this. And never represent money as a float: use integer minor units (cents, paise) or a decimal string, and format at the presentation layer.
Design payloads that stay debuggable
- Prefer flat over deep. Five levels of nesting is hard to read and harder to write selectors against. Two or three is usually enough.
- Use consistent casing.
snake_caseorcamelCase, chosen once, applied everywhere. Mixed casing in one payload is a reliable sign of a stitched-together backend. - Return arrays, not numbered-key objects.
{"0": ..., "1": ...}forces awkward client code. - Prefer
nullto omission for fields that exist but have no value, so clients can distinguish "empty" from "not supported". - Use ISO 8601 for dates —
2026-03-11T09:30:00Z. Unix timestamps are ambiguous about seconds versus milliseconds and unreadable in logs. - Wrap collections in an object, not a bare top-level array, so you can add pagination metadata later without a breaking change.
Handling large payloads
Above a few megabytes, in-browser formatting gets sluggish and your editor may hang. Options:
- Extract the interesting slice with
jqbefore formatting. - Request a smaller page from the API — if it does not paginate, that is the bug.
- Use streaming parsers (NDJSON, one object per line) for logs and bulk exports.
Security habits
Never paste production payloads containing customer data, access tokens or internal endpoints into a random online formatter — many upload the content to a server for processing. The JSON Formatter here parses entirely in your browser with the native JSON.parse, so nothing is transmitted. Check the network tab if you want to verify that claim; you should be doing that with any tool you paste sensitive data into.
Two more:
- Validate untrusted JSON against a schema before using it. Depth limits prevent parser denial-of-service through deeply nested structures.
- Never
eval()JSON.JSON.parseexists and is safe.
Related tools worth bookmarking
While you are formatting payloads, these tend to come up in the same session: Base64 Encoder for embedded blobs, JWT Decoder for inspecting bearer tokens, URL Encoder for query parameters, Regex Tester for extracting fields from logs, and UUID Generator for test fixtures.
They all live in the Developer tools category and, like everything here, run locally.