JSON Formatter, Validator & Minifier

Format, validate, and minify JSON without it leaving your browser

JSON is the lingua franca of web APIs, configuration files, and structured logs. It's also painful to read when it arrives minified or hand-edited. Whether you're debugging a webhook payload, comparing two API responses, or cleaning up a copy-pasted config, this formatter validates the input with the browser's own strict JSON parser and rewrites it with consistent indentation — entirely on your machine. JSON often contains access tokens, internal IDs, or customer data; none of it should be posted to someone else's server just to add line breaks. Open the network tab and watch: zero requests fire when you click Format.

JSON's strict syntax, and where it bites

JSON looks like a JavaScript object literal but is far stricter, and the gap between the two causes most validation failures. The rules: every key must be a double-quoted string, strings must use double quotes (never single), trailing commas are forbidden, comments are forbidden, and the only literals allowed are true, false, and null — no undefined, no NaN. A snippet that is perfectly valid JavaScript fails as JSON:

// Invalid JSON (valid JavaScript)
{ name: 'Ada', roles: ['admin',], }

// Valid JSON
{ "name": "Ada", "roles": ["admin"] }

When parsing fails, the tool reports the exact line and column, so a trailing comma buried on line 412 of a config file takes seconds to find instead of minutes of squinting.

Format vs. minify

Formatting and minifying are two sides of the same operation: parse first, then re-serialize. Formatting emits indented output for humans; minifying strips every byte of insignificant whitespace for machines. On a typical pretty-printed API response, whitespace accounts for 20–40% of the file, so minifying before embedding JSON in a query parameter, a JWT claim set, or an environment variable is a real saving. Because both paths run the parser, either one doubles as a validity check — a single stray comma that would break a deploy gets caught here first.

Practical uses

• Pretty-print a webhook or API payload so you can actually see the field you're after.
• Validate a config file before committing — strict parsing catches what a lenient editor lets through.
• Format two responses with "Sort keys" enabled, then diff them to spot the real change rather than noise from key order.
• Minify JSON destined for a data attribute, URL parameter, or inline script tag.

Pitfalls and when not to use it

Two limits are worth knowing. First, JavaScript stores all numbers as 64-bit floats, so integers above 2^53 − 1 (9,007,199,254,740,991) silently lose precision — a 64-bit ID like 1234567890123456789 comes back rounded. If your payload carries IDs that size, keep them as strings. Second, this is a syntax validator, not a schema validator: it confirms the document is well-formed JSON, not that it matches your API contract. And if your file has comments or trailing commas on purpose — JSONC files like tsconfig.json, or JSON5 — strict parsing will reject it by design.

Related tools

• Diff Checker — compare two formatted JSON documents line by line.
• Base64 Encoder/Decoder — decode Base64-wrapped JSON such as JWT payloads.
• Schema Generator — build valid JSON-LD structured data for your pages.