JSON Formatter
Format, minify, and validate JSON data
Top 10 JSON Errors — Spot Them in Seconds
The validator above will pinpoint these for you, but recognising the pattern speeds up debugging API responses, config files, and webhook payloads. Eight of the ten are caused by people hand-editing JSON as if it were JavaScript or Python — both of which are more forgiving than JSON.
| Error | Bad | Good |
|---|---|---|
| Trailing comma | {"a": 1, "b": 2,} | {"a": 1, "b": 2} |
| Single quotes for strings | {'name': 'Alice'} | {"name": "Alice"} |
| Unquoted keys | {name: "Alice"} | {"name": "Alice"} |
| Comments inside JSON | {"a": 1 // count} | JSON has no comments. Use JSONC. |
| Mixed array types — ok, BUT… | [1, "two", undefined] | [1, "two", null] |
| Unescaped backslash in string | {"path": "C:\Users"} | {"path": "C:\\Users"} |
| Unescaped quote in string | {"msg": "He said "hi""} | {"msg": "He said \"hi\""} |
| Newline inside string | {"x": "line1<br/>line2"} | {"x": "line1\nline2"} |
| Leading zeros on numbers | {"id": 007} | {"id": "007"} (string) or {"id": 7} |
| NaN / Infinity | {"val": NaN} | {"val": null} (JSON has no NaN) |
Why JSON is stricter than JavaScript: JSON was originally a subset of JavaScript object literals — but the JSON spec (RFC 8259) intentionally locked it down for interoperability. Trailing commas, comments, single quotes, and unquoted keys all work in JS object literals. They all fail in JSON. The fix when editing JSON in a JS-aware editor: use this validator before saving.
When to Use JSON vs YAML vs TOML vs XML
JSON is the default for APIs and web data, but it's not always the right format. Quick decision matrix for which format fits which use case.
| Format | Best for | Avoid for | Has comments? |
|---|---|---|---|
| JSON | API requests/responses, browser local-storage, NoSQL documents | Hand-edited config files (no comments, strict syntax) | No |
| YAML | Kubernetes manifests, GitHub Actions, hand-edited configs, Ansible playbooks | High-frequency machine parsing (slower), data with significant whitespace | Yes (#) |
| TOML | Rust Cargo.toml, Python pyproject.toml, app config files | Deeply nested data (gets unwieldy past 3 levels) | Yes (#) |
| XML | Legacy enterprise integrations, SOAP APIs, RSS/Atom feeds, SVG, Office docs | New APIs (JSON is 2-3× smaller for same data) | Yes (<!-- -->) |
| JSON5 / JSONC | VS Code settings, tsconfig.json — JSON variants that allow comments + trailing commas | APIs (no native parser support — needs library) | Yes |
The decision shortcut: if a human will hand-edit it daily → YAML or TOML. If a machine reads it more than humans do → JSON. If an enterprise vendor demands it → probably XML. If you control both sides and need speed → consider binary formats (Protobuf, MessagePack) instead.
JSON Workflow Recipes
Four high-frequency developer tasks where this tool fits naturally.
🐛 Debug an API response
- Copy the raw JSON from your browser DevTools Network tab
- Paste into the formatter above
- Click Format — see the indented structure
- Spot the field that's wrong; trace why your code mishandled it
- If validation fails, the line number tells you where the malformed character is
📤 Minify before pushing to production
- Paste your formatted dev-config JSON
- Click Minify — strips all whitespace
- Reduces file size 15-30% — faster page loads, smaller cache
- Paste the minified output into your build artifact / deployment config
- Keep the pretty-printed version in source control for review
📋 Validate webhook payloads
- Copy the payload from your webhook log (Razorpay, Stripe, GitHub)
- Paste into the validator
- If your handler is failing, validate the raw payload first
- If valid → handler bug. If invalid → encoding/escaping issue at sender
- Use formatted view to manually find the expected field path
🔍 Diff two JSON files
- Format both JSON files to standard 2-space indentation here
- Copy each formatted result
- Paste both into our Text Diff tool
- See exact field-level differences side-by-side
- Great for comparing API responses before/after deploys, or config across environments
Privacy note: all formatting, minification, and validation happens entirely in your browser via the native JSON.parse / JSON.stringify APIs. Your JSON — including API keys, tokens, customer PII, or anything else sensitive — never leaves your machine. Closing the tab clears the editor.
Frequently Asked Questions
What is JSON and why does it need formatting?
JSON (JavaScript Object Notation) is a lightweight data interchange format used by APIs, configuration files, and databases. Raw JSON from APIs often comes as a single compressed line, making it difficult to read. Formatting adds proper indentation and line breaks so you can quickly understand the data structure and spot errors.
What is the difference between formatting, minifying, and validating JSON?
Formatting (or beautifying) adds indentation and line breaks for readability. Minifying removes all unnecessary whitespace to reduce file size, which is ideal for production use. Validating checks whether the JSON syntax is correct and pinpoints the exact location of any errors.
What are common JSON syntax errors and how do I fix them?
The most frequent errors include trailing commas after the last item in an array or object, using single quotes instead of double quotes for strings, missing or extra brackets, and unquoted property names. This tool highlights the error location and provides a descriptive message to help you fix the issue quickly.
How much does minifying JSON reduce file size?
Minification typically reduces JSON file size by 10-30% depending on the original formatting. For deeply nested structures with generous indentation, the savings can be even greater. This reduction improves network transfer speeds and API response times in production environments.
Is my JSON data kept private when using this tool?
Yes, all formatting, minification, and validation happens entirely in your browser. No data is sent to any server, so you can safely use this tool with API keys, configuration data, or any other sensitive JSON content.