JSON is the lingua franca of APIs, config files, and structured logs — which means a single malformed document can take down a deployment or silently corrupt a pipeline. The good news: most JSON problems are caught in seconds with the right formatting and validation habits.
Format for humans, minify for machines
Raw API responses are often a single unreadable line. Before you read or review a payload, beautify it with consistent indentation so nested objects and arrays become scannable. When you're done, minify for production to shrink transfer size. ForgePlug's JSON Formatter does both with configurable 2-space, 4-space, or tab indentation to match your project's style.
Match your project's style guide
Consistency matters more than the specific indent size. Pick 2-space or 4-space and let your formatter enforce it across the codebase.
Validate before you trust
A trailing comma, an unquoted key, or an extra brace produces parser errors that are cryptic at best. Validation tools that report the exact line and column — with a plain-English explanation — turn a five-minute hunt into a five-second fix. The JSON Validator watches your input as you type and flips to green the moment the document becomes valid, with document statistics (key count, depth, type breakdown) to help you understand unfamiliar payloads.
Format, validate, and compare
Beautify or minify with pinpoint error reporting, validate live as you type, and diff two documents side by side to review API contract changes.
Open JSON Formatter & ValidatorDiff before you deploy
When you're reviewing configuration drift between environments or checking what a code review changed in a fixture, a JSON diff that explains each change in plain language is invaluable — added keys, changed values, array-length shifts — with ignore options for volatile fields like timestamps.
The errors that account for most failures
Nearly every JSON parse error comes from writing JavaScript and expecting it to be JSON. The two languages look similar and are not the same thing. A trailing comma after the final element is valid JavaScript and invalid JSON. Single-quoted strings are valid JavaScript and invalid JSON — JSON requires double quotes for both keys and string values. Unquoted keys are valid JavaScript object syntax and invalid JSON.
Then there are values JSON has no representation for. undefined, NaN, and Infinity all exist in JavaScript and none exist in JSON, which is why serialising an object with an undefined property silently drops that key rather than raising an error. Comments are not permitted either, which is the single most common complaint about JSON as a configuration format and the reason JSON5 and JSONC exist as separate things.
Two failures that produce no error at all
Duplicate keys are the more dangerous one. The specification permits them but does not define what a parser should do, and in practice most parsers keep the last occurrence and discard the earlier ones without complaint. A config file where a key appears twice parses cleanly and quietly ignores one of the values — which is precisely the kind of bug that survives review, because the file looks fine and the parser never objects.
Large numbers are the other. JSON numbers have no defined precision limit, but most parsers read them into a double-precision float, which represents integers exactly only up to about 9 quadrillion. A 64-bit database ID or a Twitter-style snowflake ID beyond that range gets silently rounded, so the value you parse is not the value that was sent — no error, just a subtly wrong number. This is why APIs that deal in large identifiers usually transmit them as strings.
An invisible character at position 0
A byte-order mark at the start of a file is invisible in most editors and will break parsing with an error pointing at the very first character, where nothing appears to be wrong. It is commonly introduced by Windows tooling saving as UTF-8 with BOM. If a file looks perfect and refuses to parse, this is the usual culprit — save it as UTF-8 without BOM.
Habits that prevent the problem
Validate JSON in CI, not just locally. A malformed config file that reaches production is a deployment failure; the same file caught by a validation step in the pipeline is a thirty-second fix. Most languages have a lightweight JSON parse check that can run against your config directory in seconds.
Keep a consistent key order — most commonly alphabetical, or a fixed logical grouping — and stick to one indentation setting across the repository. This is not aesthetics: inconsistent formatting produces enormous, unreadable diffs when a tool reserialises a file, burying the one line that actually changed in hundreds of lines of reordering noise.
Finally, prefer null to an omitted key when a value is genuinely absent but expected. Omitting a key and setting it to null mean different things to most consumers, and being deliberate about the distinction avoids a class of bug where the receiving code cannot tell "not provided" from "provided as empty".