The JSON You Need to Read Is the JSON You Can't Upload

It is 2:14am and the payment webhook is failing in production.

The log line is 4,000 characters long. The terminal wraps it across eleven visual rows, so the nesting is invisible — you can see that amount_due is 4999, but not whether it sits under data.object or under previous_attributes. You know the answer is somewhere in that wall of text. You are reading it with grep and your eyes.

That is the moment you open a JSON formatter. And that is the moment you hit the real problem: the payload contains a customer ID, an email, an idempotency key, and a partial card fingerprint. You cannot paste that into a website that uploads it to a server.

The JSON you most need to read is exactly the JSON you are not allowed to upload.

The pain, in five layers

Pain 1: nobody produces pretty JSON.
APIs minify. Loggers minify. Message queues minify. The default output of every system that emits JSON is one line, because bytes are cheap and readability is the consumer's problem. You are always the consumer.

Pain 2: a one-line object defeats every reading strategy you have.
Terminal wrapping breaks at the column, not at the structure. grep finds the key but not the path. jq would solve it — if it were installed, if you remembered the filter syntax, and if the machine were not a locked-down bastion host at 2am.

Pain 3: the payload is sensitive, and most tools are not.
This is the layer that actually blocks people. A payment event, a login response, an internal API dump — they carry PII, tokens, tenant IDs. Every "free online JSON formatter" that asks you to paste into a textarea is asking you to move production data to a stranger's server. At 2am, under incident pressure, that is how breaches get their start.

Pain 4: formatting is never the last step.
You format it, then you need to minify it back to paste into a curl command, or copy one nested subtree, or compare it against the version from yesterday. A tool that only pretty-prints gets used once and abandoned.

Pain 5: you cannot tell if it is even valid.
Half of "why is this broken" turns out to be a trailing comma, a smart quote, or an unescaped newline. You need the error position, not a red squiggle.

The insight

None of those pains require a server. JSON parsing, formatting, validating and minifying are pure string operations — the browser can do all of it in the tab, with no network request at all.

So the only question is whether the tool you use actually does that.

The tool: OnliTools JSON Formatter

OnliTools JSON Formatter is a browser-based formatter with one property that matters more than any feature: the badge next to the editor says LOCAL ONLY. Parsing happens in the page. Nothing is sent anywhere.

It covers the whole loop — format, minify, validate, copy, download — in one editor.

Step 1 — paste

Paste the raw payload, or hit Paste to read the clipboard directly. Load sample fills in a demo object if you just want to try it.

Step 2 — format

One click on Format. Indentation is applied, brackets align, and the structure becomes visible.

Step 3 — do the follow-up

• Minify — collapse it back to one line for a curl body or a fixture file.
• Copy — take the result straight to the clipboard.
• Download — save it as a .json file.
• Clear — start over without reloading the page.

If the JSON is malformed, you get an error instead of a broken indentation — which is the actual diagnostic you were looking for.

What it actually did

I ran a realistic Stripe-shaped invoice.payment_failed event through it:

	Before	After
Characters	540	893
Lines	1	41
Structure visible	no	yes

The file got bigger — that is the point. Whitespace is the feature. You format to read, then minify back to 540 characters when you ship it.

Five things that bite when formatting JSON

1. JSON with comments is not JSON. tsconfig.json, VS Code settings, and plenty of config files allow // comments. A strict parser will reject them. If your file is JSONC, strip the comments first — the error is correct, the file is not JSON.

2. Big integers lose precision. 1767225600123456789 as a JS number becomes 1767225600123456800. Any browser-based tool inherits this. If you handle 64-bit IDs (Snowflake, Discord, Twitter), keep them as strings.

3. Duplicate keys silently collapse. {"a":1,"a":2} is legal-ish and every parser keeps the last one. Formatting will not warn you, and the bug will look like data loss.

4. Escaped unicode hides meaning. \u4e2d\u6587 is valid JSON and unreadable. A good formatter decodes it in the display; check that yours does before you assume the data is garbled.

5. Very large payloads will freeze the tab. A 50 MB JSON file is a different problem — that is a job for jq or a streaming parser, not a browser editor.

The two follow-ups you will want next

Comparing two versions. When "it worked yesterday" is the bug report, JSON Compare shows field-level differences instead of making you eyeball two formatted blobs.

Getting it into a spreadsheet. When someone asks for the data in Excel, JSON/CSV Converter flattens it without a Python one-liner.

The takeaway

Formatting JSON is a solved problem that keeps getting unsolved by tools that want your data first.

Pick a formatter that runs in the tab, keep it open in a pinned tab, and the 2am payload becomes a thirty-second read instead of a fifteen-minute squint — with no production data leaving your machine.

Try the JSON Formatter →