JSON Formatter & Validator

Why JSON is still everywhere

JSON (JavaScript Object Notation) was specified by Douglas Crockford in 2001 as a lightweight subset of JavaScript object literals. Twenty-five years later, it is the default wire format for the vast majority of public APIs — REST, GraphQL, WebSocket payloads, configuration files, log lines. The simplicity is the feature: only six value types (string, number, boolean, null, object, array), no schema required, no binary framing.

Newer formats like Protocol Buffers, MessagePack, and CBOR exist for reasons (smaller, typed, faster to parse). But JSON's human-readability keeps it the lingua franca for anything a developer might open in a text editor.

The strict-mode rules that bite

The JSON spec (RFC 8259) is stricter than the JavaScript syntax it descends from. Three rules trip people up: (1) keys MUST be double-quoted strings — `{name: "x"}` is invalid, `{"name": "x"}` is required. (2) trailing commas are not allowed: `[1, 2, 3,]` parses in JavaScript but not in JSON. (3) comments are not allowed at all — neither `//` nor `/* */`.

Most parsers also reject NaN, Infinity, and -Infinity (they're not in the spec), reject unescaped control characters in strings, and require UTF-8 encoding. Some "relaxed" parsers (JSON5, HJSON, JSONC) accept these — but if you ship JSON5 to a strict consumer, it will fail.

Pretty-print vs minify: when to use which

Pretty-printed JSON (with indentation and newlines) is for humans — code review, debugging, config files checked into git. Minified JSON (no whitespace) is for the wire — every byte costs latency and bandwidth, and a typical config file shrinks 30-60% when minified.

Rule of thumb: pretty-print at rest (files, logs, dev tools), minify in transit (API responses, message queues). Most production HTTP servers transparently gzip JSON, so the savings from minification compound: a 1 MB pretty file gzips to ~80 KB, the same data minified gzips to ~70 KB. Small percentage, but free.

Common parse errors and how to fix them

"Unexpected token X at position N" — count to position N to find the offending character. Almost always one of: an unquoted key, a single quote, a trailing comma, or an unescaped backslash in a string.

"Unexpected end of JSON input" — the file was truncated mid-parse. Common with file uploads that hit a size limit, or with partial network responses that weren't error-checked.

"Duplicate key" — JSON allows duplicate keys per the spec, but most parsers warn or silently keep only the last one. Don't write JSON with duplicate keys; the behavior is implementation-defined.

Beyond formatting: validation and schema

Validation here means "is the syntax legal JSON" — a syntactic check. For semantic validation ("does this object have the fields my API expects?"), use JSON Schema (RFC draft) with a validator like Ajv (JavaScript) or jsonschema (Python). JSON Schema lets you declare types, required fields, value ranges, regex patterns for strings, and references between schemas.

In production APIs, validate at the boundary. A bad payload should fail fast with a 400 and a clear error message — not silently corrupt downstream state. JSON Schema generates such errors automatically and is portable across languages.