JSON formatter & validator

JSON (JavaScript Object Notation) is a lightweight, text-based data format used to represent structured data as key-value pairs, arrays, and nested objects. Despite the name, it isn't tied to JavaScript — practically every modern programming language can read and write it, which is why JSON has become the default format for web APIs, configuration files, log entries, and data interchange between services that otherwise share nothing in common.

A JSON document is built from just six value types: objects ({}), arrays ([]), strings, numbers, booleans (true/false), and null. That simplicity is JSON's biggest strength — the entire grammar fits on an index card — but it also means the format is strict. There is no room for trailing commas, unquoted keys, or comments, which is exactly why a dedicated formatter and validator is so useful: it catches the small syntax slip that a human eye glosses over.

These three actions all start from the same parsed JSON, but they serve different purposes. Understanding when to reach for each one saves time whether you're debugging an API response or shipping a production config file.

Under the hood, both format json and minify json use the exact same two steps: JSON.parse() turns the text into a real JavaScript value, and JSON.stringify() turns it back into text. The only difference is the third argument to stringify — pass an indent (like 2 or "\t") to beautify, or omit it entirely to minify. Because both routes start with a full parse, any invalid JSON is caught before either action can run — which is also exactly what the validate button does on its own.

The vast majority of "broken JSON" reports come down to a handful of repeat offenders. This tool surfaces the browser's native parser error verbatim (for example Unexpected token } in JSON at position 42) and converts the character position into a line and column, so you don't have to count commas by hand.

• Trailing commas. {"a": 1, "b": 2,} is invalid — JSON does not allow a comma after the last item in an object or array, even though JavaScript object literals do. Delete the comma before the closing bracket.
• Single quotes instead of double quotes. {'a': 1} fails because JSON strings and keys must use double quotes. Single quotes are a JavaScript convenience that JSON never adopted.
• Unquoted keys. {a: 1} is valid JavaScript but invalid JSON — every key must be a quoted string: {"a": 1}.
• Comments. JSON has no comment syntax at all. A // note or /* block */ left over from JavaScript or JSON5 will fail every time.
• Missing or extra brackets/braces. An unmatched {, [, }, or ] is the most common cause of an "Unexpected end of JSON input" error — usually from copying a truncated response or deleting one character too many while editing.
• NaN, undefined, or Infinity. These are valid JavaScript values but have no JSON representation. Use null instead, or a string like "NaN" if you need to preserve the concept.
• Leading zeros or a trailing decimal point. Numbers like 012 or 1. are invalid JSON numbers — use 12 and 1.0 instead.
• Unescaped control characters or stray backslashes. A raw newline inside a string, or a backslash that isn't part of a valid escape sequence (\n, \t, \", \\, \uXXXX), will break the parser. Escape it or remove it.

If validation fails, the red error box above shows the browser's exact message plus the line and column it maps to, so you can jump straight to the offending character with your editor's "go to line" shortcut instead of scanning the whole file.

• Debugging API responses. Most APIs return minified JSON to save bandwidth. Beautifying it instantly reveals the structure so you can find the field you actually need.
• Reviewing config files. package.json, OpenAPI specs, Kubernetes manifests, and countless other tools store configuration as JSON — a consistent indent makes pull-request diffs readable instead of a wall of noise.
• Shipping smaller payloads. Minifying JSON before it goes over the wire — in a webhook body, a bundled config, or an embedded <script> tag — trims every byte that isn't load-bearing.
• Validating before you commit. A quick validate pass catches a syntax error before it becomes a failed deploy, a broken build step, or a cryptic runtime exception three services away from where the bad JSON was written.
• Teaching and documentation. Well-formatted, indented JSON is far easier to explain in a tutorial, a Stack Overflow answer, or internal docs than a single unbroken line.
• QA and support. Support engineers often need to eyeball a customer's exported data or webhook payload to spot what's missing or malformed, without asking an engineer to run a script.

• Backend and API developers inspect request and response bodies while building or debugging REST and GraphQL endpoints, where a minified payload is unreadable without formatting.
• Frontend developers check the shape of data returned from an API before writing the code that consumes it, catching missing fields or unexpected nesting early.
• DevOps and platform engineers validate JSON config for CI/CD pipelines, infrastructure-as-code templates, and service manifests before a deploy, where a single stray comma can fail a build.
• QA engineers and testers compare expected versus actual API responses and need a consistent, readable format to spot the one field that differs.
• Technical writers and educators format JSON samples for documentation, tutorials, and Stack Overflow answers so readers can follow the structure at a glance.
• Support and solutions engineers eyeball exported customer data or webhook payloads to diagnose an integration issue without needing to write or run a script.

1. Add your JSON. Paste it into the input box, or click Upload .json to load a file straight from disk with FileReader.
2. Pick an indent. Choose 2 spaces, 4 spaces, or a tab using the segmented control — this only affects Beautify output.
3. Click Beautify, Minify, or Validate. Beautify and Minify fill the output box with the reformatted JSON; Validate checks the input and reports a pass/fail with no output change.
4. Fix errors if they appear. An invalid document shows the parser's exact message plus a line and column so you can jump straight to the problem.
5. Copy or download the result. Use Copy result to put the output on your clipboard, or Download .json to save it as a file.

The stat line above the buttons shows a green "Valid JSON" badge, the input size, and the total number of keys across the whole document — a quick sanity check that you're looking at the payload you expect.

Real-world JSON is rarely flat. API responses commonly nest objects several levels deep — a user object containing an address object containing an array of previous addresses, for instance — and it's that nesting, more than raw size, that makes minified JSON hard to read. Beautifying restores the visual indentation that lets your eye track which closing brace belongs to which opening one, which is exactly what a code editor's bracket-matching relies on.

When you're hunting for a specific value in a large, deeply nested document, it helps to beautify first, then use your browser's or editor's find function to search for the key name rather than scrolling. The key-count stat above the output gives you a quick sense of how large and complex a document really is — a response with three keys is trivial to eyeball, one with three hundred is not, and knowing which one you're looking at changes how you approach debugging it.

• Use 2-space indentation for compact, git-friendly diffs; 4 spaces or a tab if you find 2 spaces visually cramped in deeply nested structures.
• When comparing two JSON payloads, beautify both with the same indent first — otherwise every line looks different even when the data is identical.
• If you need comments or trailing commas in a config file, you're looking for JSON5 or JSONC, not JSON — most build tools that accept those extensions strip them before treating the file as strict JSON.
• Large arrays of near-identical objects (e.g. a list of users) are a common source of accidentally huge payloads — minifying before you store or transmit them can meaningfully cut size.
• Keep a canonical, beautified copy of important config JSON in version control; only minify at the point you actually need the smaller size, such as a build artifact.
• When editing JSON by hand, add or remove one key at a time and validate after each change — it's far faster to spot a typo in a five-line diff than in a 500-line file.

JSON isn't the only structured data format, and it's worth knowing when a sibling format is actually the better fit. XML predates JSON and is still common in enterprise systems and SOAP APIs; it supports attributes and namespaces that JSON has no equivalent for, but it's far more verbose and needs a full parser rather than a single function call. YAML is a superset-ish alternative popular for configuration (Docker Compose, GitHub Actions, Kubernetes) because it allows comments and reads cleanly without quotes or braces — but its whitespace sensitivity makes it easy to break with a stray tab. CSV is the simplest of the four and ideal for flat, tabular data like a spreadsheet export, but it has no native way to represent nested objects or arrays.

JSON sits in the middle: more structured and less ambiguous than CSV, far less verbose than XML, and stricter but more universally supported than YAML. That combination — plus being a first-class citizen in almost every programming language's standard library — is why it became the default for REST APIs, webhooks, and browser-to-server communication in the first place.

Yes. Every action — beautify, minify, and validate — runs entirely inside this browser tab using the built-in JSON.parse and JSON.stringify functions. Nothing you paste or upload is sent to a server, logged, or stored anywhere. That makes it safe to use with API keys, customer records, internal configs, or any other sensitive payload, and it also means the tool keeps working even if you go offline after the page has loaded.