JSON formatter & validator
Paste JSON from an API response, config file, or log line to validate syntax, pretty-print with readable indentation, or minify for production. Errors show line-level hints for missing commas, unquoted keys, and stray brackets — essential when debugging webhooks, REST APIs, and GraphQL payloads. Everything runs locally so tokens and PII never leave your browser.
Input
Output
{
"hello": "world"
}
How to format and validate JSON
1. Paste raw JSON into the input area (or a fragment wrapped if needed).
2. Click format to pretty-print with standard 2-space indent, or minify for one line.
3. Fix any validation error the parser reports — often a trailing comma or single quotes.
4. Copy the cleaned output into your IDE, Postman, or deployment config.
JSON formatting examples
Pretty-print API response
Minified `{"id":42,"name":"Ada","roles":["admin","user"]}` becomes indented multi-line JSON for readable diffs in code review.
Catch invalid JSON
`{"status": "ok",}` fails — trailing comma after last property. Remove the comma before `}` to validate.
Minify for HTTP body
A 4 KB pretty config shrinks ~30% minified — useful when size matters, though gzip often makes both small on the wire.
When to use this tool
• When an API returns a one-line JSON blob and you need to read nested fields.
• When a CI config or package.json fails parse and you isolate the bad line.
• When you sanitize a payload before sharing in a bug report (redact secrets first).
When to choose something else
• When you need JSON ↔ CSV conversion — use jsonToCsv / csvToJson.
• When you only validate schema (types, required fields) — use a JSON Schema validator.
• When files exceed browser memory — use jq or IDE formatters on desktop.
Debugging APIs with formatted JSON
When a fetch returns 200 but wrong data, pretty-print exposes nesting: is `user.id` missing or renamed? Compare formatted before/after responses in git diff. For GraphQL, errors array often sits beside `data` — indentation reveals partial success. Redact Authorization headers and tokens before pasting into any tool, even local ones, on shared recordings.
Validation in the development workflow
JSON Schema validates shape; a formatter validates syntax. Run format first in pipelines — invalid JSON fails fast. Minify before embedding in HTML script tags to reduce escape issues, but prefer separate `.json` files fetched at runtime. Standard indent is 2 spaces (npm, most APIs); 4 spaces appear in some Java configs — pick team convention.
Frequently asked questions
What makes JSON invalid?
Unquoted keys, single quotes, trailing commas, comments (non-standard), NaN/Infinity literals, or mismatched brackets.
Does it preserve key order?
Yes — parsed objects re-serialize in insertion order for keys as parsed (ES2015+ behavior).
Can I format JSON with secrets?
Processing is local — safer than cloud formatters — but still avoid pasting production keys on shared screens.
Pretty-print vs minify?
Pretty for humans; minify for storage or embedded scripts. Semantically identical if valid.
Does it fix JSON automatically?
It reports errors; some issues (trailing commas) you fix manually. It does not guess at corrupted data.
Is my data sent to a server?
No. Parse and format happen entirely in-browser.
Is this tool free?
Yes.