Skip to content
DDevToolery

4 November 2024 · 6 min read

Why most online JSON formatters are a security risk

The average formatter POSTs your input to a server. Here is what that means when the input is a production config.

Open the network panel and paste something into a typical online JSON formatter. In most cases you will see a request go out. Your document was sent to a machine you do not control, formatted there, and sent back. The round trip is invisible in the interface and completely visible in the network tab.

For a toy example that is harmless. The problem is what people actually paste into these tools, which is rarely a toy example.

What ends up in the box

Developers reach for a formatter at precisely the moments when the data is interesting: debugging a failing API response, checking a Kubernetes manifest, working out why a webhook payload is malformed, reading a customer record that came back wrong.

  • API responses containing customer names, addresses and order histories
  • Configuration files with database hostnames and internal service URLs
  • Webhook payloads carrying signing secrets in a header field
  • Error dumps with stack traces that reveal your directory structure and dependency versions
  • Access tokens, pasted whole because you wanted to check the claims

None of that is meant to leave your organisation. All of it routinely does, one paste at a time, because the tool that formatted it happened to run somewhere else.

The problem is not malice

Most of these sites are not stealing your data. The risk is duller than that: your data becomes an entry in someone else's logs. It sits in an access log, an application log, an error tracker, a CDN cache, or a database of recent requests kept for debugging. It is now inside a third party's breach radius, retention policy and jurisdiction — and you never agreed to any of them.

You cannot audit a promise. A privacy policy describes what a company intends to do; it does not describe what its infrastructure is capable of doing.

The compliance angle

If you handle personal data, pasting it into a third-party service is a transfer to a processor. Under GDPR that needs a legal basis, a processing agreement, and a record. Nobody files a DPA because they formatted a JSON blob at four in the afternoon, which means the transfer happened outside every control your organisation has.

What local processing changes

JavaScript can parse and format JSON perfectly well in the browser. JSON.parse is built into the language. There is no technical reason for the round trip — it exists because the site was built as a web application with a backend, not because the work needs one.

When the tool runs locally, the entire category of risk disappears. Not because the operator promises to delete your data, but because they never receive it. There is no log to leak, no cache to expire, and no jurisdiction to argue about.

How to check any tool

This takes about ten seconds and works on any site:

  • Open developer tools and select the Network tab
  • Clear the existing entries
  • Paste your input and trigger the tool
  • Watch the list — a local tool adds nothing, a server-side one adds a request with your data in the body

A stronger version of the same test: load the page, disconnect from the network, then use the tool. If it still works, the processing is happening on your machine.

The rule of thumb

Before pasting into any online tool, ask whether you would be comfortable emailing the same content to a stranger. If the answer is no, use something that runs locally — a browser tool that does the work on your device, an editor plugin, or jq at the command line.

Tools mentioned