The four things that break JSON
Almost every parse failure comes down to one of four causes, and all four are legal JavaScript, which is exactly why they slip through. A trailing comma after the last element of an object or array. Single quotes instead of double quotes. Unquoted keys. And comments, which JSON has never supported despite how often people expect it to.
The reason these are so common is that most JSON is written by hand inside a codebase where the surrounding language permits all of them. Configuration files are the worst offenders, because a developer editing one is usually thinking in the syntax of the code around it rather than in the stricter grammar of the file.
Knowing the shortlist makes debugging fast. When a parse fails, the error position points at where the parser gave up, which is frequently a character or two after the actual mistake — a missing comma is noticed at the start of the next key, not at the end of the previous value.
Formatting versus minifying, and when each is right
Formatting adds indentation and line breaks so a human can read the structure. Minifying strips every optional byte so a machine can move it faster. They are the same data and the choice is purely about audience.
The rule is simple: format for reading, minify for transport. A 50 KB formatted API response typically minifies to around 35 KB, and across millions of requests that is genuine bandwidth and genuine latency. Never store or serve the formatted version of something users fetch.
The one place people get this wrong is committing minified JSON to version control. It saves a trivial amount of space and destroys every diff, turning a one-character change into a single unreadable line. Keep source files formatted; minify at build time.
Why sorting keys is more useful than it sounds
JSON objects are unordered by specification, so two responses containing identical data can serialise their keys in different orders — and frequently do, particularly across languages or library versions. Comparing them directly produces a wall of differences that mean nothing.
Sorting both before comparing removes that noise entirely and leaves only the real changes. This is the fastest way to answer questions like whether staging and production are returning the same shape, or what actually changed between two API versions.
Arrays deliberately keep their order, because array order is meaningful in a way object key order is not. Sorting an array would change the data rather than just its presentation.
Working with API responses safely
The JSON people paste into formatters is rarely trivial. It is API responses containing customer records, webhook payloads carrying signatures, configuration files holding connection strings, and debug output that captured whatever happened to be in memory.
That makes the choice of tool a real one. A formatter that posts your input to a server has received a copy of whatever was in it, and the categories above are precisely the ones an organisation would not knowingly disclose. This page parses with the same JSON engine your browser already runs, locally, and transmits nothing.
A related habit worth forming: before pasting a payload anywhere, glance at what is in it. Tokens, email addresses and internal hostnames appear in debug output far more often than people expect, and the moment to notice is before rather than after.