JSON Formatter & Validator

JSON (JavaScript Object Notation) is defined by a small, strict grammar — RFC 8259 and the equivalent ECMA-404 standard. A JSON document is exactly one value: an object, an array, a string, a number, true, false, or null. An object is a set of "key": value pairs wrapped in curly braces, where every key must be a double-quoted string — single quotes, unquoted keys, and trailing commas are all invalid, even though they're legal in a JavaScript object literal.

That distinction trips people up constantly: JSON looks like a JavaScript object literal because it grew out of one, but it's a separate, language-independent format. JavaScript-only values like undefined, functions, Date objects, NaN, and Infinity have no JSON representation — JSON.stringify() silently drops or converts them, which is a common source of "my JSON is missing a field" bugs.

Every JSON parser fails at the exact byte where it can no longer match the grammar, which is why a validator reports a line and column rather than a vague "invalid JSON" message. Four mistakes account for the vast majority of real-world errors: a trailing comma before a closing } or ], a missing comma between two properties or array items, a key or string wrapped in single quotes instead of double quotes, and an unescaped double quote or backslash inside a string value.

Numbers have their own strict rules that are easy to miss: a leading zero is only allowed if the number is exactly 0 or 0.something (01 is invalid), and a decimal point must have digits on both sides (1. and .5 are both invalid — they must be 1.0 and 0.5). None of these are stylistic preferences; a parser that accepts them isn't following the spec.

Beautifying (pretty-printing) adds indentation and line breaks purely for human readability while editing, debugging, or reviewing a diff — it changes nothing about the data itself. Minifying strips every character that isn't part of the data's meaning: extra spaces, newlines, and indentation. The two are just different serializations of an identical value, and re-parsing either one produces the same in-memory object.

In practice, minified JSON is what you send over the wire — smaller payloads mean less bandwidth and slightly faster parsing — while pretty-printed JSON is what you keep in version control or read during development. Config files that are meant to be hand-edited (package.json, tsconfig.json) are conventionally kept pretty-printed even though the parser doesn't care either way.

JSON strings are always double-quoted, and a handful of characters inside them must be escaped with a backslash: the double quote itself (\"), the backslash (\\), and the control characters for newline (\n), tab (\t), carriage return (\r), backspace (\b) and form feed (\f). Forgetting to escape a literal double quote inside a string is one of the most common ways hand-written JSON breaks, especially when embedding another JSON document or a snippet of HTML as a string value.

Any Unicode character can also be written as a \uXXXX escape giving its four-digit hexadecimal code point, which is how JSON stays valid even in transport contexts that only support plain ASCII. Characters outside the Basic Multilingual Plane — most emoji, for instance — don't fit in one 16-bit code unit, so they're written as a UTF-16 surrogate pair: two consecutive \uXXXX escapes. A validator that only checks for balanced braces would miss a broken surrogate pair; a real JSON parser rejects it as invalid.

JSON has become the de facto data format for REST and GraphQL APIs because it's compact, human-readable, and has a parser built into essentially every language and runtime — unlike XML, it needs no external schema to be useful, and unlike a binary format, you can read a response with your eyes while debugging. That same simplicity is also its biggest limitation: strict JSON has no way to add a comment explaining why a value is set the way it is, which matters much less for a wire format than it does for a config file a human maintains by hand.

That gap is exactly why relaxed supersets exist: JSON5 and JSONC (JSON with Comments) add comments, trailing commas and unquoted keys back in for tooling and config files, while remaining a strict subset of what a JSON.parse()-only consumer would reject. If a tool's config file accepts comments, it's almost always parsing one of these supersets rather than standard JSON — worth knowing before you paste a commented config into a strict validator and wonder why it fails.

Online JSON formatters and desktop tools like VS Code, jq, or Postman all do the same core job — parse, validate, and pretty-print JSON — but they differ sharply in privacy, portability, and workflow integration. A browser-based formatter like this one has a fundamental privacy advantage: nothing ever leaves your machine. The JSON you paste is processed entirely in memory by JavaScript, and there's no network request, no logging, no server-side storage. For sensitive data — production API responses containing user PII, credentials in config files, or proprietary business logic — that local-only guarantee is decisive.

Desktop tools have their own strengths: jq excels at filtering and transforming JSON in pipelines, VS Code's built-in formatter integrates with your editor's undo history and multi-cursor workflows, and Postman ties formatting directly to API request/response cycles. But they require installation, OS-specific binaries, and updates. The browser tool works identically on Windows, macOS, Linux, and ChromeOS with zero setup. The trade-off is that browser tools can't touch the filesystem directly (you must paste or use a file picker), can't batch-process hundreds of files, and lack plugin ecosystems. Use the online tool for quick, private formatting of sensitive snippets; reach for jq or VS Code when JSON manipulation is part of a larger automated workflow.