JSON Formatter and Validator — Beautify or Minify JSON

Part of Text tools: See all Text tools.

What is JSON Formatter?

Pretty-print, minify, and validate JSON in your browser. Paste a payload; formatting and parse errors run locally in the page—your JSON is not uploaded to build a server-side archive. Free, no signup. Ideal when debugging APIs, cleaning config files, or teaching why trailing commas break strict JSON.

How to use JSON Formatter

1. Paste your JSON into the Input box.
2. Click Format to pretty-print it with 2-space indentation, or Minify to collapse it to a single line.
3. If the input is invalid, read the error message, fix that spot in the input, and click Format again.
4. Copy the result from the Output box.

Why use this tool?

Minified API responses are hard to read, and one stray comma can break a whole config file. Formatting shows the structure at a glance, and the parse error points you to the first problem, without sending the payload to another server.

Debugging helper: Use this formatter to turn messy JSON into readable indentation, then fix invalid structures (mismatched quotes/braces) before sending to an API.

Readable JSON makes it much faster to spot mistakes during development and code review.

FAQ

Does the JSON formatter upload my data?

No. Format, Minify and validation run with JavaScript in your browser tab, so the JSON you paste is not sent to our server. Still avoid pasting live passwords or tokens on a shared screen.

Why does it say my JSON is invalid?

JSON is stricter than JavaScript. The usual causes are a trailing comma before ] or }, single quotes instead of double quotes, unquoted keys, comments, or values like NaN and undefined. The message comes from your browser's JSON parser and usually gives the position of the first bad character.

What is the difference between Format and Minify?

Format rewrites the same data with line breaks and 2-space indentation so people can read it. Minify removes all optional whitespace so the payload is as small as possible. Neither changes keys, values, or their order.

Can I paste NDJSON or several JSON objects at once?

Not directly. The input must be one JSON document. For line-delimited JSON, paste one line at a time, or wrap the lines in [ ] with commas between them.

Is there a size limit?

There is no fixed limit, but very large pastes (tens of megabytes) can make the tab slow, because everything is processed on your device. Split huge logs into smaller pieces.

JSON Formatter — In-Depth Guide

Common reasons JSON fails to parse: trailing commas, single quotes, unquoted keys, comments, and NaN or Infinity values. Fix the first error the parser reports, then format again; later errors often disappear with it.

Comparing two responses: format both so each key sits on its own line, then paste them into a diff tool. The formatter keeps keys in their original order, so if two servers return keys in a different order the diff will show that too.

Typical workflow: copy a response from your browser DevTools or a curl command, format it here, inspect or fix it, then minify it if you need to send it back in a request body.

Troubleshooting: if the tab slows down on a huge paste, trim the input. If the JSON looks valid but an API still rejects it, check for invisible characters copied from a document, or a wrong Content-Type header on the request.

Encoded payloads: if a value is Base64, decode it with the Base64 tool first, then paste the decoded JSON here.

What a formatter actually does

A JSON formatter takes a single-line compact payload and rewrites it with indentation and line breaks so a human can read it. The bytes change but the parsed value does not. {"a":1,"b":[2,3]} and a pretty-printed seven-line version with two-space indentation represent the exact same JSON document, and any correct parser treats them identically. The formatter is purely cosmetic; it adds nothing, removes nothing, rounds nothing.

Validation is the other half of the job. The tool attempts to parse the input against the strict JSON grammar (RFC 8259). If parsing fails, it reports where and why. The error message comes from your browser's built-in JSON parser and usually gives the position (in recent browsers also the line and column) of the first unexpected token. This is almost always faster than eyeballing a 4000-line payload to find a missing comma.

Common failure patterns, and why JSON is stricter than it looks

JSON looks like JavaScript object literal syntax, but it is a strictly narrower subset. Writing JavaScript-style and expecting JSON to accept it is the single most common source of "invalid JSON" errors in practice.

Trailing commas: [1, 2, 3,] is a valid array in JavaScript, Python, and Rust. It is not valid JSON. Every comma must be followed by another element; a comma immediately before ] or } is a syntax error. Trailing commas cause more JSON parse failures than any other single issue.

Unquoted keys: {name: "Alice"} is valid JavaScript. It is not valid JSON. Every object key must be a double-quoted string. {"name": "Alice"} is the correct form.

Single quotes: {'name': 'Alice'} is not valid JSON. JSON requires double quotes for both keys and string values. Some loose parsers accept single quotes, but no standards-conforming parser will.

Comments: JSON has no comment syntax. // this is a note and /* ... */ are both rejected. If you need annotated configuration, consider JSON5 or YAML instead of JSON. If you absolutely must use JSON with notes, the conventional workaround is a sibling key like "_comment": "this is a note" that consumers ignore.

Undefined and NaN: JavaScript has the values undefined, NaN, and Infinity. JSON has none of them. Attempting to encode these will either fail or emit invalid JSON. Most encoders replace them with null, but you have to know that is happening because null is often semantically different from undefined.

Indentation and key order

This formatter uses two-space indentation, the most common convention (Python's json.dumps(indent=4) uses four). Minified output, with no whitespace at all, is what you want when sending JSON over the wire: it is often 10–30% smaller than pretty-printed output and parses identically.

Keys stay in the order they appear in your input. JSON objects are technically unordered, so if two servers return the same data with keys in a different order, a line-by-line diff will show every moved key. When you need a clean comparison, sort keys in code first (for example json.dumps(obj, sort_keys=True) in Python) and then format both payloads here.

Why this tool runs entirely in your browser

Parsing, validation, and indentation all happen in JavaScript inside the page you have open. The text you paste never leaves your computer. This matters because the payloads people format are frequently sensitive: API responses mid-debug, internal data dumps, customer records, auth tokens in the Authorization header of a captured request. Sending any of that to a server to pretty-print it would be a pointless privacy violation, and a small number of browser-based formatters on the web do exactly that.

The practical upshot: use this tool on the raw output of curl without worrying about what you are sharing. Large responses are handled locally with no network traffic, limited only by your device's memory. The only request sent during the interaction is the initial page load, which is static HTML and JavaScript.

JSON in practice: APIs, config files, log aggregation

API responses are the most common thing people paste into a formatter. Most REST APIs return minified JSON because it saves bandwidth. A successful response from a typical web API is five or fifteen or three hundred kilobytes of compact, unreadable text. Pretty-printing it is the first step of almost every debugging session that begins with "why did this field come back empty".

Configuration files in JSON (package.json, tsconfig.json, AWS IAM policies, Kubernetes manifests) are usually pretty-printed already because they are edited by humans. The common failure pattern is: a developer hand-edits the file, adds a trailing comma on line 42, and the entire config stops loading. Paste into this tool and the error jumps out immediately.

Log aggregation pipelines (Elasticsearch, Datadog, Splunk) emit one JSON document per log line, stitched together with newlines (NDJSON or JSON-Lines). Each line is independently valid JSON, but the full file is not. If you paste a NDJSON chunk in here, the formatter will reject it because it is not a single JSON document. Paste one line at a time, or wrap the whole thing in a wrapping array first.

Beyond validation: structural sanity checks

Strict JSON validity is a minimum bar. A payload can be perfectly valid JSON and still be broken — null values where strings were expected, arrays where objects should be, dates formatted as Unix timestamps in one field and ISO 8601 strings in another. The formatter cannot detect these semantic issues, but it makes them easy to spot because a human can now read the document.

For schema-level validation, the next step is JSON Schema or TypeScript types — not something this tool covers, but a natural follow-on once you know the document parses cleanly. Get the JSON to parse first, read it second, validate the shape third.

Minify, prettify, and the diff-friendly middle ground

Minified JSON strips every optional whitespace character — no indentation, no line breaks, no space after commas. It is the shipping format for API payloads, where every byte over the wire matters and no human is expected to read the raw response. Pretty-printed JSON is the same document with indentation and line breaks inserted for readability. Switching between the two is a formatting choice, not a semantic one, and this tool offers both as separate buttons.

Two-space pretty printing already puts each key and each array element on its own line, which is what line-oriented diff tools need: when two versions differ by one field, the diff highlights just that line. That is why JSON kept in version control (Kubernetes manifests, package-lock.json) is usually stored pretty-printed rather than minified.

When JSON is the wrong choice

JSON is the right default for structured data in most modern stacks, but a few cases push towards alternatives. Configuration files that need comments should use YAML, TOML, or JSON5. Heavily numeric payloads (scientific data, time series) compress much better as binary formats like Protocol Buffers, MessagePack, or Apache Arrow — a 10 MB JSON file of floats often becomes a 1 MB binary equivalent. Documents with mandatory structure and compile-time validation benefit from Protocol Buffers or TypeScript types with runtime parsers like Zod. JSON's great strength — being a loose string-typed container that every language can parse — is also its weakness when rigour matters.

Step-by-step guides

• How to fix invalid JSON
• JSON formatter: when and how to use it
• CSV vs JSON: which data format should you use?

Also try

Related tools that work well with this one:

• Base64 Encode/Decode
• Regex Tester
• Hash Generator
• Word & Character Counter