What You're Actually Pasting Into an Online JSON Formatter

It is late, an endpoint is returning something unexpected, and you have a wall of minified JSON in your terminal. You select it, search for a formatter, paste, and hit format. Ten seconds later the structure is readable and you have moved on. This is one of the most common actions in software development and almost nobody thinks about it for as long as it takes to perform.

Worth thinking about for a minute, though: what exactly did you just paste into somebody else's website?

What is usually in the blob

Nobody formats a tidy two-key object. The JSON that gets pasted is the awkward one — a real response captured from a real system. Which means it tends to contain:

Credentials. A bearer token in the echoed request headers, an API key in a config dump, a refresh token in an auth response you were debugging precisely because auth was broken.
Personal data. Customer names, email addresses, postal addresses, order histories, sometimes dates of birth. If your organisation is subject to GDPR or a similar regime, pasting this into a third-party service is a processing decision you just made on your own authority at 1am.
Internal topology. Hostnames, private IP ranges, queue names, bucket names, service identifiers. Individually dull; collectively a map.
Stack traces. Absolute file paths, framework versions, and occasionally a fragment of source.

You would not put any of that in a public gist. A formatter feels different because the output comes straight back and nothing appears to have been published. The paste is the same act.

"We don't store your data" is not the load-bearing claim

Most server-side formatters say something reassuring, and most of them mean it. The trouble is the claim covers the wrong stage.

For your text to be formatted on their machine, it must arrive on their machine. TLS terminates at their edge, which means the payload exists in plaintext in memory on a host you do not control. From there the ordinary machinery of running a website applies: a reverse proxy that logs request bodies over a size threshold, an error tracker that captures the request when the parser throws, a CDN with a debug mode someone left on, a backup of that log shipped somewhere for ninety days. None of this requires bad faith. It requires a normal stack behaving normally.

A tool that never receives the text has none of these failure modes, because there is no stage at which the text exists anywhere but your own process.

Checking where the work happens

Three checks, in increasing order of effort:

Airplane test. Load the page, kill your network, format something. If it still works, the parsing ran locally. This is the check you can explain to a non-engineer, and it is not fakeable.
Network tab. Open DevTools, clear the log, press format. Watch for a request carrying your payload. Be alert to the shape of the traffic as well as its presence — a page can be honest about parsing and still ship telemetry.
Content Security Policy and the source. For a tool you plan to use repeatedly, read the CSP header and skim the bundle for fetch or XMLHttpRequest calls near the input handler. Slower, but it answers the question properly.

Our JSON formatter is written to pass the first test: it parses and re-serialises in the page, and the payload never becomes part of a request. You can confirm that yourself in about twenty seconds, which is the only reason worth believing it.

If you are going to use a server-side tool anyway

Sometimes you will, and it is not a catastrophe. Reduce the blast radius:

Strip Authorization, Cookie, and Set-Cookie before pasting. These are the fields that turn an embarrassment into an incident.
Replace real customer records with representative fakes. You are almost always debugging structure, not values.
If a live token did go across, rotate it. Not because you expect misuse, but because the cost of rotating is five minutes and the cost of assuming is unbounded.
Check whether your employer has a policy. Many do, and it is usually more restrictive than people realise.

Local options you already have

You often do not need a website at all:

jq . pretty-prints from a pipe, and jq -S . sorts keys, which makes two responses diffable.
python3 -m json.tool is on nearly every machine with no install.
In a browser console, copy(JSON.stringify(JSON.parse(s), null, 2)) formats and puts the result on your clipboard.
Every serious editor has a format-document command bound to a key.

The browser tool earns its place when you are on a machine that is not yours, when the blob is too large to paste comfortably into a terminal, or when you want to see the tree collapsed rather than as text. Those are good reasons. "It was the first result" is not one.

Common questions

Is a browser-based formatter slower on large payloads?

For anything up to a few megabytes the parse is effectively instant, since it is the same engine your applications run on. Very large documents are limited by rendering the tree rather than by parsing it, and a server-side tool has to transfer the whole thing first, so it rarely wins.

Does formatting change my JSON?

Round-tripping through a parser normalises whitespace and escaping, and it can reorder nothing but will drop duplicate keys and reformat numbers according to the JSON number rules. If you need byte-exact output — a signed payload, for instance — format a copy and keep the original.

What about validating JSON against a schema?

Same reasoning, and often higher stakes, because a schema tends to describe an internal contract you would rather not publish. Prefer a local validator; if you use a hosted one, send the schema with example data rather than production data.