Last week I watched a senior engineer paste a 4MB JSON payload into VS Code and wait 12 seconds for the linter to finish. Then they Cmd+F'd for the missing bracket. Then they gave up, re-ran the API call, and tried again.
That whole detour was unnecessary. There are three places JSON validation lives in 2026 — the browser, the editor, and the shell — and each one wins in a different scenario. Mixing them up costs a few minutes a day. Once you stop mixing them up, you stop noticing the friction at all.
This is a field guide to which tool actually wins for which task.
Why "just use VS Code" is wrong
VS Code's built-in JSON validator is excellent. It is also the worst answer to several common questions, because:
It loads the whole file into memory. A 50MB log dump from CloudWatch hangs the renderer for seconds before you can scroll.
It validates syntax, not shape. Without a $schema reference, you get a green checkmark for any structurally valid blob — no help with "is this the response my API returned yesterday?"
It is coupled to a workspace. Pasting an ad-hoc payload into a scratch buffer means picking a filename, picking a folder, and ignoring unsaved-buffer warnings on quit.
It is not on the production server. When you SSH into a box at 2am to inspect what an API returned, the editor is irrelevant.
VS Code is right when JSON is part of a project — config files, fixtures, schema-validated payloads. It is wrong for almost everything else.
When the browser wins
Most JSON validation in practice is one-shot: "is this blob I just pasted valid?" or "what does this nested structure actually look like?"
For that, a browser-based formatter is the fastest answer. No file to save, no buffer to close, no schema to wire up. You paste, you see green or red, you keep moving.
I use TextKit's JSON formatter for this. The reason is boring and important: it pretty-prints, minifies, and validates without sending the payload anywhere. Everything happens client-side. That matters when the JSON contains a customer email or an internal token — and it almost always does, because if it did not, you would not be poking at it.
The browser wins specifically when:
The payload is between 1KB and 5MB (above that, browsers struggle too).
You do not need to query the data, just look at it.
You want to compare two payloads side by side. Format both, then drop them into TextKit's text diff tool — it respects whitespace and shows the structural drift line by line. This is the single fastest way to answer "what changed between yesterday's API response and today's?"
You are on someone else's machine and you do not trust their Node version.
A note on copy-paste hygiene. JSON pulled from server logs usually comes with line numbers, timestamps, or wrapper text glued to it. Cleaning that up by hand is irritating. A regex-capable find and replace can strip the prefix in one pass — the pattern ^\d{4}-\d{2}-\d{2}T[^\s]+\s+ covers the ISO-timestamp prefix that breaks most parsers.
When VS Code wins
VS Code is the right tool when JSON is part of the project, not a one-off blob.
The clearest signal: the file lives in your repo and someone else will edit it next week. That includes:
tsconfig.json, package.json, .eslintrc.json, and the rest of the config family.
API request and response fixtures in a test directory.
OpenAPI specs and JSON Schema definitions where IntelliSense matters.
Any file where Git history needs to track changes
In these cases the editor's schema validation is the entire point. Reach for the browser and you lose Cmd-click navigation, autocomplete, type errors against the schema, and the "Format Document" keybind your hands already know.
A useful trick: if you are handed a JSON payload and you know it is about to become a fixture, paste it into a scratch buffer first, save it as *.fixture.json, and let VS Code start nagging immediately. The friction is the value.
When jq wins
jq is the only correct answer for three things:
JSON over 10MB. No browser, no editor, just stream it.
JSON you need to query, not just read. "Give me the email of every user where subscription.status == 'cancelled'" is a one-liner in jq and a ten-minute exercise in any UI.
JSON inside a pipeline. When the input is curl ... | jq and the output feeds another command, no GUI tool fits.
The jq syntax curve is real, but the floor is low. Three commands cover 80% of practical usage:
bash# Pretty-print and validate (exits non-zero on bad JSON)
cat response.json | jq .
# Pull a nested field out
cat response.json | jq '.data.users[0].email'
# Filter an array by predicate
cat response.json | jq '.data.users[] | select(.status == "cancelled") | .email'
If you are new to jq, the first command alone — jq . — replaces 90% of "is this valid?" workflows once you internalize it. The second and third are what make it irreplaceable.
The cost of jq: it is installed-on-this-machine-or-not, and on Windows the experience is rough enough that most engineers do not bother. That is why the browser tool stays in the rotation even on jq-friendly setups.
A decision tree that fits on an index card
Use this and you will be right 95% of the time:
File is in the repo? → VS Code.
Payload over 10MB, or you need to query inside it? → jq.
One-shot blob, you just want to look at it or share a clean version? → browser-based formatter.
Comparing two payloads? → format both in the browser, diff them, then reach for jq if you need to drill in.
The trap is reaching for VS Code by default because it is already open. It is the most powerful of the three for project work and the slowest for ad-hoc inspection. The browser tool exists for the second category, and the few seconds it saves per inspection compound into real time across a week.
A note on "online JSON validators"
A surprising number of online JSON tools POST your payload to a server. For small public data this is fine. For anything containing PII, internal IDs, API keys, customer records, or anything that ends up in a SOC 2 audit trail — it is not. The fix is to use a tool that runs entirely in the browser and to verify it by opening the network tab and watching for outbound requests during a paste-and-format cycle. If you see none, you are safe.
This is also why "JSON beautifier" search results from 2018 are not a great answer in 2026. Most of those domains were sold, the privacy posture changed, and there is no easy way to audit what they do with what you paste. Pick a tool whose source-of-truth you can verify, then stop thinking about it.
Try it
Next time you are about to paste 200 lines of JSON into your editor's scratch buffer, try TextKit's JSON formatter instead. If it is a structural diff problem, TextKit's text diff takes the formatted output and shows exactly which keys moved.
Save VS Code for the files that actually live in the repo.
Top comments (0)