Formatting and Validating JSON

Why JSON is everywhere and unforgiving

JSON won as the web's data interchange format because it is small, readable, and maps directly onto the data structures every language has. Its strictness — the source of most frustration — exists for parsing speed and unambiguity. One syntax, no options, no interpretation. The practical stance: accept the rules as the price of universal compatibility, and let tooling handle the friction.

The rules that produce ninety percent of errors

Five rules generate nearly every JSON syntax error: keys and strings must use double quotes (single quotes are invalid), trailing commas after the last item are forbidden, comments do not exist in the format, bare words like undefined are not values, and numbers cannot have leading zeros. Memorizing this list converts most errors from mysteries into instant recognitions.

Pretty-printing as a reading tool

Minified JSON — the shape APIs and logs deliver it in — defeats human reading completely. Formatting with indentation per nesting level restores what eyes need: structure. Two-space indentation is the convention; the value is visibility, not aesthetics. Every serious JSON review starts with a format pass, because reviewing minified data is not actually possible.

Error location: the feature that saves hours

A syntax error in a ten-thousand-line payload is the classic debugging tax. Formatters that report the exact line and column convert it to a ten-second fix. The workflow: paste, format, jump to the reported position — and remember the actual mistake may be slightly before the reported spot (an unclosed quote throws the parser's position off). The second formatting attempt after the fix confirms the whole payload, not just the region.

Validating before shipping

The discipline that prevents integration incidents: any hand-edited JSON gets validated before it ships — config files, fixture data, API mocks. The format pass is the validation pass; a payload that formats cleanly parses cleanly. Teams that edit configs by hand and skip validation discover their errors in production logs instead.

Large payloads: strategies beyond formatting

Formatting solves reading for payloads up to a point; beyond a few megabytes, strategies stack. Search for the specific key rather than scrolling. Format and fold sections mentally by indentation level. For truly large data, extract the relevant subtree first — JSON tools generally work best when you give them the slice you care about rather than the whole ocean.

JSON versus JSON-like formats: knowing which you hold

The recurring confusion: content that looks like JSON but allows comments and trailing commas is JSON5 or a config dialect; JSON lines (one object per line) is a streaming format; YAML is an entirely different grammar. Attempting to format these as strict JSON produces errors that are not bugs. Identify the dialect first; strict formatting applies only to actual JSON.

The number precision trap

JavaScript numbers lose integer precision beyond fifteen-ish digits — a real problem for IDs from databases that use large integers. If formatting a payload with long numeric IDs, know that some tools will quietly round them; the professional pattern is transporting such IDs as strings. The formatter surfaces structure; precision is your architecture's job.

Privacy: payloads with real data

The JSON being formatted is usually live data — API responses with personal records, logs with user events. Local formatting validates and pretty-prints without that data leaving the browser, which keeps everyday debugging on the right side of data policy.

Minification: the reverse direction and when it matters

The inverse operation — stripping whitespace to compact JSON — is not just a party trick. APIs with payload-size limits, embedded contexts where every byte counts (localStorage caps, WebSocket messages at scale), and URL-carried JSON all reward minimized output. The guarantee is symmetric: minified JSON parses identically to the formatted version, so the choice is purely transport economics. The workflow pattern: edit and review formatted, transmit minimized. Teams that hand-edit minified JSON invite syntax errors; formatting before every edit keeps error rates near zero.

Navigating large documents: paths over scrolling

Megabyte-scale JSON defeats scrolling; the answer is path navigation. Knowing the target path (users.0.address.city) lets you jump directly, and formatting with consistent indentation makes path-to-line mapping predictable. The practical skills: reading a sample element to learn the schema, counting array indices in the formatted view, and collapsing irrelevant depth mentally by following indent levels. When documents exceed comfortable size, extract the relevant subtree into its own file for inspection — formatting makes the subtree boundaries obvious at a glance.

JSON inside logs: extract, format, then understand

Modern logging pipelines emit JSON blobs per line, and debugging starts with pulling one blob out of the stream. Raw log JSON is typically minified and escaped; extracting it and formatting turns a wall into fields you can read in order of importance. The recurring value: timestamps become comparable, request IDs become traceable, and error payloads become legible. Teams that format log JSON as standard practice resolve incidents measurably faster than teams grepping raw lines — the information was always there; formatting is what makes it addressable.

Diagnosing the five real JSON errors

Almost every JSON parse failure falls into five buckets, and the fix for each is mechanical. Trailing commas: legal in JavaScript object literals, illegal in JSON — delete the comma before a closing brace or bracket. Single quotes: valid in JS, invalid in JSON; every string and key needs double quotes. Unquoted keys: same rule, double quotes required. Comments: JSON has none; remove // and /* */ lines, or you are actually editing JSONC, a different dialect. Bare values: undefined, NaN, and single-quoted dates are JavaScript artifacts that do not exist in JSON and must become null, a number, or a quoted string.

The formatter's error position is your fastest diagnostic. JSON parsers report byte offsets; counting to byte 1,204 by hand is pointless, but the reported line and column lands you at the exact token. The error is usually not at the reported position but just before it — a missing comma on the previous line is reported at the next key, because that is where the parser realized something was wrong. Look one construct backwards.

After fixing, verify the repair answers the original question. A common loop: format, spot an unexpected null where a value should be, trace it back to the producer. Formatting makes data shape visible, and visible shape is how you catch a field that silently stopped being populated — something that stays invisible in a 200 KB single-line payload until the day it breaks a consumer.

Common mistakes with this tool

• Hand-editing JSON configs without a validation pass.
• Using single quotes or trailing commas and blaming the parser.
• Formatting JSON5 or YAML as strict JSON and chasing phantom errors.
• Letting big integer IDs lose precision in transit.

Frequently asked questions