JSON Formatter & Validator

Formatting and Validating JSON

JSON is the default data-interchange format of the web, and almost none of it arrives in a shape a human can read. Production APIs minify their responses, log aggregators collapse payloads onto a single line, and config files accumulate nesting until the structure is invisible. A formatter re-inserts the indentation and line breaks so you can see the shape of the data; a validator tells you precisely where the syntax broke when a parser rejects it.

Both operations here run through the browser's native JSON.parse(), which means the acceptance rules are exactly the ones your JavaScript runtime uses. If this page accepts your document, fetch().then(r => r.json()) will too.

The JSON Rules That Trip People Up

JSON is much stricter than the JavaScript object literals it resembles. The differences cause the overwhelming majority of parse failures:

• Double quotes only, on both keys and string values. {'a': 1} and {a: 1} are both invalid; {"a": 1} is correct.
• No trailing commas. [1, 2, 3,] is a syntax error, even though every modern JavaScript engine accepts it in source code.
• No comments. There is no // or /* */ in JSON. Formats that allow them (JSON5, JSONC, tsconfig.json) are supersets and will not parse as strict JSON.
• No undefined, NaN, or Infinity. Use null. This bites when serializing floating-point results.
• Numbers cannot have leading zeros or a leading +, and hex literals are not permitted.
• Control characters must be escaped inside strings — a literal newline or tab in the middle of a string value is invalid.

Reading a Parse Error

Error messages point at the position where the parser gave up, which is usually just after the real mistake rather than on it. Two patterns cover most cases:

• "Unexpected end of JSON input" — the document is truncated. A bracket or brace is unclosed, or the response was cut off mid-transfer.
• "Unexpected token < in JSON at position 0" — the classic. You are not looking at JSON at all: the server returned an HTML error page or a login redirect. Check the status code and the Content-Type before debugging the payload.

Common Use Cases

• Inspecting an API response. Paste a minified body and read the nesting directly instead of guessing at it in a terminal.
• Fixing a config file. package.json, composer.json, and CI manifests fail loudly and unhelpfully on a single stray comma.
• Validating before you ship. Confirm a request body is well-formed before wiring it into code, so a 400 means a business-logic problem rather than a syntax one.
• Reading log output. Structured loggers emit one JSON object per line; formatting one makes the fields legible.
• Preparing a bug report. A formatted payload in an issue is far easier for a maintainer to act on.

Formatting vs. Minifying

Pretty-printed JSON is for humans and belongs in editors, code review, and documentation. Minified JSON — no whitespace at all — is for the wire, where the indentation is pure transfer cost. Neither changes the data: parse both and you get identical objects. Keep source-controlled config formatted so diffs are readable, and let your API layer minify responses.

Comparing Two Documents

Formatting shows you what one document contains; it will not tell you how two of them differ. When a request works in staging and fails in production, the faster route is the JSON Diff Checker, which reports added, removed, and changed values key by key. For non-JSON files — YAML, .env, nginx configs, log excerpts — use the File & Text Diff Checker instead.

Privacy

The document you paste is parsed by your own browser and never sent anywhere. That is the difference that matters when the payload you are debugging contains customer records, internal identifiers, or a session token — the exact material that should never be posted to a third-party formatter.