MinifyPic

JSON Formatter

Beautify unreadable JSON, minify it back down, and catch syntax errors with a message that actually tells you where the problem is.

FreeValidateMinify
Loading tool…

How it works

A compact workflow from input to download.

1

Paste your JSON

Drop in an API response, a config file, or a single unreadable line of minified JSON.

2

Format or minify

Beautify it with clean indentation, or strip every unnecessary byte for production.

3

Copy the result

Copy the formatted output, or read the error message if the JSON is not valid.

Frequently asked questions

Why does my JSON fail to validate?
In practice it is nearly always one of four things: a trailing comma after the last item in an object or array; single quotes instead of double quotes; unquoted keys; or a stray comment. JavaScript object literals allow all of those and JSON allows none of them, which is why JSON copied out of code so often fails.
Can JSON contain comments?
No, and this is a deliberate and much-argued-about decision by its designer, Douglas Crockford. He removed comments specifically because people were using them to carry parsing directives, which broke interoperability. If you need annotated configuration, use JSON5, JSONC or YAML — but strip the comments before feeding it to a strict JSON parser.
What is the difference between formatting and minifying?
Formatting adds indentation and line breaks so a human can read the structure. Minifying removes every space and newline that is not strictly required, which is what you want in production because it makes the payload smaller and faster to transmit. The data is identical either way.
Does it handle very large JSON files?
It handles files of a size that is realistic to inspect by hand comfortably. Multi-megabyte payloads may make the browser sluggish, simply because rendering that much text in a text area is expensive — that is a limit of the browser rather than of the parsing.
Is my data sent to a server?
No. Everything runs in JavaScript inside your own browser tab — nothing is uploaded, logged or stored. That is what makes it safe to paste in API responses, config files, tokens and other material you could not send to a third-party service.

Why JSON took over

JSON won because it was radically less than what it replaced. XML, the previous default for data interchange, was powerful, extensible and enormously verbose — a simple record could take five lines of angle brackets and repeat every field name twice, once to open a tag and once to close it. JSON offers four primitive types, two container types, and nothing else: no namespaces, no schemas, no attributes-versus-elements distinction, no processing instructions. It maps directly onto the data structures every modern programming language already has, so parsing it requires no ceremony. It is human-readable without being wordy. That deliberate poverty of features is precisely why it became the default language of web APIs within about a decade.

The strictness that catches everyone

The single most common source of frustration is that JSON looks exactly like a JavaScript object literal and is significantly stricter than one. Keys must be wrapped in double quotes — not single quotes, not bare. Strings must use double quotes too. A trailing comma after the final element, which JavaScript now cheerfully permits and many style guides actively encourage, is a hard syntax error in JSON. Comments are forbidden entirely. Numbers cannot have leading zeros or a trailing decimal point, and NaN and Infinity are not valid values. This is why copying an object out of your source code and pasting it into a JSON field so reliably fails: it is very nearly JSON, and very nearly is not good enough for a parser.