JSON formatter vs jq vs your editor: when to reach for which

Almost every JSON problem a developer touches falls into one of three categories: I want to read this, I want to transform this, or I'm editing the file that contains this. The three tools listed in the title each map to one of those categories. They overlap, but the right choice depends entirely on which category you're in.

The 30-second decision

• Browser JSON formatter — best when the JSON arrived in a chat, ticket, browser tab, or email and you want to read it. Paste, format, copy, close. No install, no syntax to remember.
• jq — best when you want to transform JSON (extract a field, reshape, filter, aggregate) and especially when you want to do it inside a shell pipeline.
• Your editor's built-in formatter— best when the JSON is already in a file you're editing and you want format-on-save, schema validation, or refactoring across multiple values.

The rest of this post fleshes out the cases where each one wins and the ones where it doesn't.

1. The browser formatter — "I want to read this"

Most JSON in a developer's day arrives unsolicited. A teammate pastes an API response into Slack. A customer ticket includes a webhook payload. A staging dashboard shows a JSON error blob that wraps to three screens.

For these cases, the friction-minimal answer is a browser tab. Paste, get back a pretty-printed, validated, syntax-highlighted version, copy it where it needs to go, and move on. You don't open an editor. You don't open a terminal. The JSON came to you in a browser; it can stay there.

Reasons a browser formatter wins this category:

• Zero install. Works on every machine, including the locked-down corporate laptop and the phone.
• Visual error reporting. A missing comma or trailing comma is flagged with line and column inline — cognitively cheaper than reading parse error: Expected ',' in a terminal.
• Minify mode. One click strips whitespace if you want to paste it into a URL parameter or an environment variable.
• Privacy when offline-first.A browser formatter that runs entirely in your tab — like the one on this site — never sees the payload server-side, which matters for production data, customer PII, or anything else that shouldn't be uploaded.

Where the browser formatter doesn't win:

• Programmatic transformation. If you need to extract users[].emailfrom a 10MB response, the formatter isn't the right tool.
• Diffing two versions. A formatter shows you one payload; a diff tool shows you the change. (We have one of those too — format both sides first, then diff.)

2. jq — "I want to transform this"

jqis a small CLI that parses JSON and applies a tiny functional query language to it. It's ubiquitous on developer machines and has earned its place: nothing else makes pipelines like curl /api/users | jq '.[] | select(.active) | .email' as natural.

jq wins when the operation is one of:

• Field extraction. jq '.users[0].id' is shorter than any alternative.
• Filtering. jq '.[] | select(.status == "error")' handles the long-tail of "just the records that match X."
• Reshaping. Going from { "users": [{ "id": 1, "name": "Ada" }] } to [{ "id": 1, "label": "Ada" }] is two lines of jq.
• Aggregation. group_by, map, and reducehandle the operations you'd normally reach for Pandas to do.
• Streaming on big files. jq --stream processes multi-gigabyte JSON without holding it in memory.

Where jq doesn't win:

• You don't have a terminal.On someone else's laptop, on your phone, on a machine you can't install binaries on.
• You want a visual exploration. Browsing a deeply nested response by clicking expandable rows is what the JSON to Table viewer does better than a CLI ever will.
• You need to share the output with a non-developer. A coworker who lives in spreadsheets wants a CSV, not a jq one-liner. Use the CSV / JSON converter instead.

3. The editor formatter — "I'm in the file"

If the JSON is in a file you're editing — a config file, a fixture, an API mock — the editor's built-in formatter is the right answer. VS Code, JetBrains, and every other modern editor format JSON on save, validate against schema, fold sections, and rename keys across the file.

The editor wins when:

• You're going to commit it. Format-on-save is how you keep a config file from drifting in indentation between contributors.
• You have a JSON Schema.The editor surfaces type errors ("expected a string") inline as you type, which a formatter doesn't.
• You're refactoring. Renaming user_id to userId across 200 occurrences in a fixture is editor work, not formatter work.

Where the editor doesn't win: any of the cases where the JSON isn't already in a file you have open. Opening a file just to paste a chat snippet into it, format it, and never save — that's when the browser tab is faster.

A decision matrix

If you want to memorize one rule:

Use the editor when the JSON is in a file you'll save. Use jq when you're transforming or piping. Use the browser when the JSON arrived in a browser.

And if the data shouldn't leave your device — staging responses with real customer fields, draft webhooks containing signatures, anything you wouldn't paste into a Slack DM — pick the option that runs locally. The browser formatter on this site runs entirely in your tab and is auditable in the Network panel. jq on your laptop is obviously local. Online formatters that send your paste to a server are the option you should reach for last.

Related reading

For the broader privacy argument behind "local first", see why offline-first developer tools matter in 2026. For the underlying spec, the JSON glossary entry covers the grammar and the common gotchas.