Why Your JSON Formatter Might Be Leaking Your API Keys

In November 2025, security researcher David Batey discovered that jsonformatter.org — one of the most popular online JSON formatting tools — had been logging every piece of data pasted into it. The exposed database contained over 80,000 credentials, including AWS keys, Stripe secrets, database connection strings, and API tokens from companies of every size. The data was sitting in an unsecured Elasticsearch instance, accessible to anyone who knew where to look.

This wasn't a sophisticated attack. It wasn't a zero-day exploit. It was the predictable consequence of a simple architectural choice: sending user data to a remote server for processing that could have been done entirely in the browser.

How Online JSON Formatters Actually Work

Most developers assume that when they paste JSON into a web-based formatter, the processing happens locally in their browser. After all, JSON formatting is trivial — it's just parsing a string and re-serializing it with indentation. Any modern browser can do this in milliseconds with JSON.parse() and JSON.stringify().

But many popular formatters don't work this way. Instead, they send your raw input to a backend server. Sometimes this is for "validation" features. Sometimes it's for analytics. Sometimes there's no good technical reason at all — it's simply how the tool was built years ago, and nobody questioned the architecture.

The jsonformatter.org incident proved that this server-side processing creates a massive attack surface. Even if the service operator has good intentions, sending sensitive data to a third-party server means:

Server logs capture everything. Web servers routinely log request bodies. Even if the application doesn't intentionally store your data, the infrastructure might.
Database backups persist your data. If your input touches a database — even temporarily — it lives on in backups, replicas, and snapshots.
Third-party analytics see your data. Many sites embed Google Analytics, Hotjar, or similar services that can capture form inputs.
Network intermediaries can intercept data. CDNs, load balancers, and WAFs all potentially see and log request payloads.
A single misconfiguration exposes everything. As the jsonformatter.org case showed, one unsecured Elasticsearch instance turned routine operations into a credential bonanza.

The Scale of the Problem

The 80,000+ credentials found in the jsonformatter.org breach weren't from careless junior developers. They included production AWS access keys, Stripe API secrets capable of processing payments, database connection strings to production PostgreSQL and MongoDB instances, OAuth client secrets, and JWT signing keys.

Developers paste sensitive JSON into formatters every day — API responses containing tokens, configuration files with secrets, webhook payloads with authentication headers, debug output from production systems. It's a natural part of the development workflow. The problem isn't developer behavior; it's the tools that silently transmit this data to remote servers.

When you think about the volume, it's staggering. jsonformatter.org receives millions of visits per month. If even a small fraction of those visits involve sensitive data, the exposure is enormous. And jsonformatter.org is just one tool. Dozens of similar services operate the same way.

Why Client-Side Processing Is the Only Safe Architecture

The fix for this class of vulnerability is architectural, not procedural. You can't solve it with better security practices on the server — the only way to guarantee that user data isn't exposed is to never send it to a server in the first place.

Client-side JSON formatting means your data stays in your browser's memory. It's parsed by JavaScript running on your machine, formatted locally, and displayed without ever touching a network interface. There's nothing to log, nothing to back up, nothing to leak.

This isn't a theoretical advantage. It's a fundamental security boundary. When data never leaves your browser:

Server breaches can't expose your data — because the server never had it.
Man-in-the-middle attacks are irrelevant — because nothing is transmitted.
Compliance is simplified — no need to worry about where data is processed or stored.
You can work offline — no server dependency for basic formatting operations.

How to Verify a Tool Processes Data Client-Side

Don't take a tool's word for it. Here's how to verify for yourself:

Open browser DevTools (F12) and go to the Network tab. Clear the log, then paste some test data and format it. If no new network requests appear, the processing is client-side.
Disconnect from the internet. Turn off WiFi or unplug ethernet. If the tool still works perfectly, it doesn't need a server.
Read the source code. For open-source tools, check whether the formatting logic calls fetch() or XMLHttpRequest. Pure formatters should only use JSON.parse() and JSON.stringify().
Check for third-party scripts. Look at what external JavaScript is loaded. Analytics scripts and tracking pixels can capture form inputs even if the core tool is client-side.

What Developers Should Do Right Now

If you've ever pasted sensitive data into an online formatter — and statistically, you almost certainly have — here's your immediate action plan:

Rotate any credentials you've pasted into online tools. Yes, all of them. If you can't remember which tools you've used, rotate everything to be safe.
Audit your API key usage. Check AWS CloudTrail, Stripe dashboard logs, and similar services for unexpected access patterns.
Switch to client-side tools. PinusX JSON Formatter processes everything in your browser — your data never touches a server. Verify this yourself using the Network tab technique described above.
Use environment variables properly. Avoid putting raw secrets in JSON configuration files. Use secret management services like AWS Secrets Manager, HashiCorp Vault, or even simple .env files that are gitignored.
Educate your team. Share the jsonformatter.org incident with colleagues. Security awareness around developer tools is often overlooked in training programs.

Building a Security-First Developer Toolkit

The jsonformatter.org incident is a reminder that security isn't just about your application code — it's about every tool in your development workflow. The same care you put into securing your production infrastructure should extend to the utilities you use daily.

At PinusX, every tool we build processes data 100% client-side. Our JSON Formatter, JWT Decoder, Base64 Encoder, Hash Generator, and URL Encoder all run entirely in your browser. We don't operate backend servers for data processing. We don't log inputs. We can't leak what we never receive.

Your data never leaves your browser. That's not a marketing slogan — it's an architectural guarantee. And after 80,000 leaked credentials proved why that matters, it's the only standard developers should accept from their tools.