The Evolution of JSON Formatters in Web Development

JSON won the data-interchange war so thoroughly that it is easy to forget how rough the early tooling was. In the mid-2000s, "formatting" a JSON payload usually meant a homemade function that walked a string character by character, counted braces, and concatenated newlines and spaces as it went. It worked — until it met a brace inside a string literal, an escaped quote, or a Unicode surrogate pair, and silently produced garbage.

This post traces how JSON formatters evolved from those string-concatenation hacks to the AST-driven, fully in-browser tools we rely on today, and what that evolution teaches about building developer utilities in general.

Phase one: regex and string surgery

The first generation of formatters treated JSON as text, not data. They inserted a newline after every comma and brace and indented based on a depth counter. Because they never actually parsed the document, they could not tell structure from content: a comma inside "New York, NY" got a newline just like a comma between object keys. Minifiers built the same way were worse — stripping "unnecessary" whitespace inside string values corrupted data in ways that only surfaced downstream.

The lesson from this era stuck: you cannot safely transform a structured format with regular expressions. You have to parse it.

Phase two: parse, then print

The breakthrough was embarrassingly simple in hindsight. Douglas Crockford's reference implementation, and later the native JSON object standardized in ECMAScript 5 (2009), gave every browser a real parser. Formatting became a two-step pipeline: JSON.parse() turns the text into an abstract syntax tree — the actual objects and arrays — and JSON.stringify(value, null, 2) prints that tree back with perfect, structure-aware indentation. Minification is the same pipeline with no indent argument.

Parsing first delivers something regex never could: validation for free. If the input is malformed, the parser tells you exactly where — line, column, unexpected token — instead of producing subtly wrong output. Modern formatters are really validators with a pretty-printer attached.

Phase three: moving it all into the browser

For years the best formatters lived on servers: you pasted your payload into a website, it round-tripped to a backend, and formatted text came back. That model has an obvious problem — developers routinely paste API responses containing tokens, keys, and customer data. Sending that to a third-party server is a security incident waiting to happen.

Native browser APIs made the server unnecessary. Today a formatter can parse, validate, beautify, and minify megabytes of JSON entirely client-side, with zero latency and zero data leaving the machine. That is exactly how our own JSON Formatter & Validator works, along with its companion JSON Minifier for shrinking payloads before shipping them. Even format conversion is local now — our CSV to JSON converter restructures spreadsheet exports without a single network request.

What the history teaches

Three principles fell out of this evolution. Parse, never pattern-match: structure-aware tools are correct; text-surgery tools are lucky. Validate as a side effect: the best error messages come from the parser itself. And keep data on the client: if a tool can run in the browser, it should — privacy and speed both improve. Every utility on DevToolStack is built on those three ideas.