JSON Formatter: Validate, Query, Compare and Inspect JSON Locally

A JSON formatter is most useful when it helps you debug

Pretty indentation is the easy part. The hard part shows up when an API response or some webhook body lands in front of you and you’ve got to work out why it broke. Is it valid? Where’s that one field, the one buried six levels down? Does it still match the version that worked yesterday? A tool that just adds spaces leaves you scrolling forever, hunting for the thing that changed, and I got tired of that years ago.

So I crammed the whole debug loop into one place. It parses locally. It hands you the output beautified, or minified, or with every key sorted, counts what’s inside, builds a path explorer, and runs a quick query like $.tools[0].status or $.items[*].id for when you know the field name but not where it’s hiding. Schema-style type hints, a diff of the scalar paths between two documents, that’s in there too. And yes, copy and download buttons. Because once you’ve found the answer it almost never stays put. It goes straight back into your code or a ticket.

How to read a JSON payload before changing it

Start with whether it even parses. Honestly? The parser error tells you more in two seconds than squinting at raw text does in two minutes. The usual culprits: trailing commas, single quotes, unquoted keys, comments someone pasted straight out of JavaScript, plus the odd undefined or NaN that leaked in from a serializer that should’ve known better. Once it parses, look at the shape. The nesting tells you how deep this rabbit hole goes. Scalar paths show you the values that actually shift between responses, and when you know the field but can’t find it, a focused query saves your eyes.

• Formatted output hands you readable JSON, or tight minified JSON. Want a stable order? It sorts every key recursively.
• Query result walks dot keys and bracket indexes, plus the wildcards I lean on most.
• Path explorer lays out every scalar with its full path and type, so nothing hides.
• Schema hints rough out the object and array types, handy when I’m writing docs or sketching validation.
• Diff catches the leaf values that changed, got added, or quietly vanished between two payloads.

Practical JSON checks for APIs and configs

Webhook suddenly dead? Diff the payload that failed against one that went through, before you start poking at the endpoint. Maybe it’s just my luck, but nine times out of ten the answer’s sitting right there in the diff. Config file getting rejected? Validate the raw JSON first, before you sort or minify it, or you’ll quietly bury the very error you’re chasing. Docs vague as usual? Query the one branch you care about and check its actual type instead of trusting the README. And when a value has to obey real business rules, that’s JSON Schema or app-level validation territory. This is the quick exploratory pass that comes first.

Privacy and workflow notes

Running everything in the browser is handy. It doesn’t make you careless-proof. Strip the tokens and the customer records out before you screenshot anything or drop a payload into a chat. I’ve watched an access token sit in a Slack thread for months because somebody forgot it was there. Keep a raw copy while you’re chasing a parse error; you’ll want the original back, trust me. Sort keys when you’re comparing shape. Don’t, when the order itself means something to whoever reads it next. And once a file gets genuinely huge and the browser starts to chug, open it in a local editor or pipe it through a CLI parser.

Common questions

Is this full JSONPath?

Nope. Didn’t try to make it one, either. You get the part I actually reach for day to day: the root marker, dot keys, bracket indexes, wildcard steps for walking through stuff. The moment you need filters or recursive descent or strict spec compatibility, go grab a real JSONPath library. That’s the right tool for that, not this little thing.

Does formatting repair invalid JSON?

No. On purpose. It’ll tell you what broke and point at the usual suspects, but it won’t go silently “fixing” your data behind your back. Auto-repair sounds lovely right up until it guesses wrong and quietly changes what your payload means. I’d rather you fix the source yourself, on purpose, knowing exactly what you touched.

Can I use this before JSON Schema validation?

Honestly, that’s one of my favorite ways to use it. The schema hints give you a fast read on the shape and the field types, so you walk into the real validation step already knowing what you’re holding. Just don’t mistake them for a contract. When you need rules that actually get enforced, run a proper schema validator.

What is the difference between validating and formatting JSON?

Two different jobs, and people lump them together constantly. Validation asks one thing: is the syntax legal? Formatting takes JSON that’s already valid and re-indents it so a human can actually read the thing. Any formatter worth using validates first, then shows you exactly where it choked when the JSON is broken. Skip that and you’re just rearranging garbage into neater garbage.

Why does my JSON fail with an unexpected token error?

I’d put money on one of four things. A trailing comma before a closing brace. Single quotes where double quotes belong. A key that forgot its quotes. Or a comment you copied over from JavaScript. Strict JSON tolerates none of that, even though every last one looks perfectly fine back in JS. And that mismatch? It trips people up over and over.

Can I minify JSON to save space?

Yep. Minifying just rips out the whitespace, so the payload ships smaller and a touch quicker over the wire. My rule of thumb: pretty-print it while you’re building and debugging, then let production API responses go out minified. Readable when you’re staring at it, lean when it’s actually flying around.