Is It Safe to Paste JSON Into an Online Formatter?

The short answer

It depends entirely on where the formatting happens. Some online formatters send your JSON to a server and format it there. Others do the work in your browser and never transmit anything. Both look identical from the outside: you paste, you get formatted output back. The difference only shows up in the network traffic.

You do not have to take anyone's word for which kind you are using. You can check in about thirty seconds, and the steps below work on any formatter, not just this one.

Check it yourself in DevTools

Open the formatter page and press F12, or Cmd+Option+I on a Mac, to open DevTools.
Click the Network tab.
Reload the page and let it settle. You will see a burst of requests. That is normal and it is not your data: it is the page itself, fonts, analytics, and ads.
Click the Clear button to empty the list.
Now paste your JSON and format it.
Watch the request count.

If the list stays empty, the formatting happened on your machine. If a new request appears, open it and look at the Payload tab. If your JSON is in there, it was uploaded.

A useful trick: put a distinctive fake value in your test JSON, something like {"apiKey":"CANARY_12345"}. Then use the Network tab's search, Cmd+F or Ctrl+F, to search every request for CANARY_12345. If it appears anywhere, your data left the browser.

What that audit shows on this page

We ran it against our own JSON Formatter in a headless browser, with a canary value planted in the JSON. Loading the page made 43 requests: the page assets, Google Fonts, analytics, and ad code. Pasting JSON made zero. The canary appeared in no request at all.

Forty-three is worth being upfront about, because a reader who opens DevTools expecting silence will see that number and reasonably wonder. None of them carry what you paste. The test that matters is the one you run after you clear the list.

When you should not use any online tool

Client-side processing removes the network risk. It does not remove every risk, and there are cases where the right answer is to not paste the data anywhere at all.

Live credentials. Production API keys, database connection strings, private keys, and session tokens. Even with nothing transmitted, the value is now in your clipboard, in your browser history if the tool saves state, and possibly on your screen in a meeting. Rotate anything you paste by accident.
Personal data covered by rules you answer to. Health records, payment details, and anything under GDPR or HIPAA. The question is not only whether the bytes moved, it is whether you can prove they did not.
Any machine you do not control. A shared or kiosk browser can have extensions with permission to read page content, and a client-side promise cannot protect you from that.
Browser extensions generally. An extension with access to the page can read what you paste whether or not the site makes a request. If that matters for your data, use a local tool like jq instead.

If you need to share a payload but not its secrets, strip them first with the Secret Redactor, which finds API keys, tokens, and connection strings and replaces them. It runs in the browser too, and you can audit it with exactly the steps above.

If you would rather the data never reach a browser at all, the same formatter exists as an MCP server you install locally. It is a Node process on your own machine with no network code in it, so an AI coding agent can format or inspect a payload without it leaving the machine — which also sidesteps the extension problem above, since there is no page for an extension to read.

Why so many formatters do it server-side

Mostly age and habit. Formatting JSON in the browser needs nothing more than JSON.parse and JSON.stringify, both of which have been in every browser for well over a decade. But plenty of tools were built when doing this work on a server was the normal pattern, and a working tool rarely gets rewritten. Server-side is not automatically malicious. It is a bigger surface than the job requires, and it means your data sits in someone's request logs.