Is it safe to paste JSON into an online formatter?

The short version

A JSON formatter can work in one of two ways. It can format the text in the page, using a function that already exists in every browser. Or it can post the text to a server, format it there, and send the result back.

Both produce identical output. Nothing on the screen distinguishes them. The second one means a copy of whatever you pasted now exists on someone else's machine, and quite possibly in their web server access log, their error tracker and their monitoring system as well.

This is not an accusation aimed at anybody in particular. Building it server-side is a perfectly ordinary engineering decision, especially for a tool that grew out of a larger product. The problem is not that the choice exists; it is that the choice is invisible to you at the moment you paste.

The thirty-second test

You do not have to take anyone's word for this, and you should not, including ours.

1. Open the formatter you are wondering about.
2. Open your browser's developer tools and go to the Network tab. In Chrome, Edge and Firefox that is F12; in Safari you need to enable the Develop menu first.
3. Clear the request list.
4. Paste something harmless in and use the tool.
5. Look at what appeared in the list.

If the list stays empty, the formatting happened in your browser and your text did not go anywhere. If a request appears, click it and look at the request payload. If your text is in there, it was uploaded.

There is a second version of the same test that takes less thinking: once the page has loaded, turn off your wifi and use the tool. Something that formats with the network off cannot have sent anything anywhere. It is a cruder check and it is completely conclusive.

What you might see that is not a leak

Some requests are normal and are not your data leaving. Fonts, stylesheets, images and scripts all load when the page opens, before you have typed anything, which is why the test says to clear the list first. Analytics and advertising requests are also common, and those tell a third party that you visited the page rather than what you pasted into it. That is a different concern and a much smaller one.

The thing to look for is a request that fires when you press the button and that carries your text in its body or its URL. That is the one that matters.

What is actually at risk

It depends entirely on where the JSON came from, and the honest answer is that most JSON is boring. A configuration file with no secrets in it is not worth worrying about.

The ones worth stopping for:

• API responses from a live system. These routinely carry customer names, email addresses, internal identifiers and the shape of your data model.
• Anything with a token in it. Bearer tokens, session identifiers, API keys and refresh tokens are live credentials. A pasted token is a shared token.
• JWTs. Worse than they look, because the whole reason to decode one is to see the claims, and the token itself is the credential. The middle segment is base64url, which is why a strict base64 decoder rejects it.
• Webhook payloads. Often carry personal data and a signing secret in the same document.
• Anything covered by a policy you signed. If your organization has obligations about where personal data goes, an online formatter is a data processor nobody approved.

If you already pasted something

Do not spend the day worrying about it, but do the one thing that actually helps.

If it contained a credential, rotate the credential. That is the whole remedy and it is usually five minutes. Deleting the tab, clearing your history and emailing the site achieve nothing, because you cannot un-send a request. A rotated token makes the copy worthless, which is the only outcome you can control.

If it contained personal data and you work somewhere with a policy about that, tell whoever owns the policy. That is an unpleasant conversation and it is a much smaller one on the day it happens than three months later.

How to avoid the question entirely

Three options, roughly in order of how much effort they cost.

Use what is already on your machine. Most editors format JSON with a keystroke. On a command line, python -m json.tool and jq . both do it and both work offline. Nothing you already have installed is going to upload your text.

Redact before you paste. If you only need to see the shape of a document, replace the values with placeholders first. The structure is what is unreadable, and the structure is rarely the sensitive part.

Use a formatter that runs in the page. Some do. The test above tells you which.

Run the test on us

Our JSON formatter formats in the page. Open a network tab, paste something, press Format, and watch nothing happen. Once it has loaded, you can turn off your wifi and it keeps working.

We also check it automatically, because a promise that depends on nobody making a mistake later is not a promise. Every release runs a test that loads the page, types a distinctive string into every field, clicks every button, and fails the build if that string turns up in any request. It runs a second pass that opens each page at a URL already carrying tool state, the way a shared link arrives, and fails if anything reads that state and sends it onward. The mechanism is written up in how we build tools.

We did not invent that idea and we are not going to claim it as ours: Toolcroft publishes the same guarantee. Their about page says continuous-integration tests verify the privacy promise on every change to the site, and that a change introducing an unexpected outbound request fails the build. It is the right bar, and matching it is more useful than writing a better sentence about privacy.

None of that is a reason to trust us specifically. It is a reason to believe the thirty-second test, which works on any tool, including this one, and which is the only part of this article you should still be using in five years.