Incident breakdown

The 2025 formatter leak — and the architecture that prevents it.

In November 2025, security researchers showed that two of the most-used online JSON tools had been quietly exposing years of user-submitted data. The root cause was architectural. Here is the factual timeline and why a browser-only tool like jsonversal cannot have the same failure.

What happened

watchTowr Labs' November 2025 disclosure

Security firm watchTowr Labs disclosed that JSONFormatter.org and CodeBeautify.org had exposed large volumes of user-submitted data. The exposed surface was a "Recent Links" / save-and-share feature: formatted output could be saved and shared via a URL, and those URLs followed a predictable pattern with no authentication, so the saved content was reachable by anyone who guessed the format.

80,000+
saved snippets retrieved
5 GB+
of exposed user data
48 hrs
to active exploitation

Among the retrieved data were Active Directory credentials, database and cloud keys (AWS / Azure / GCP), private keys, CI/CD secrets, production JWTs, OAuth tokens, SSH keys, and PII / KYC information — originating from organisations in government, critical infrastructure, finance, aerospace, healthcare and telecoms. Researchers also demonstrated active abuse: credentials they planted were probed by third parties within 48 hours of the supposedly-expired link. The finding was covered by The Hacker News, BleepingComputer, and Help Net Security.

Source: watchTowr Labs disclosure (watchtowr.com), November 2025; reported by The Hacker News, BleepingComputer, and Help Net Security.

The important nuance

It was a saved-share feature — not every paste

To keep this honest: the leak came from a specific server-side "save and share" feature that persisted inputs, not from the act of pasting into the formatter itself. Many online tools do not retain submissions at all, and some sites changed their behaviour after the disclosure. This is not a blanket "all online tools leak" story.

The durable lesson is architectural: if a tool can store your input on a server, your threat model has to assume it might — until you verify otherwise. The only way to guarantee that assumption is false is to never send the data to a server in the first place.

Why it happened

Server-side processing + persistence = a database of your data

Your browser
→  POST /format  →
Their server
→
Database (retained)

Once your input reaches their server, its safety depends entirely on their access controls, retention policy, and whether their infrastructure is compromised. Years of snippets accumulated with weak controls — and were found from the outside.

Your browser
→
jsonversal engineruns in your tab
→
Output

↳ no server, no database, nothing to leak

Side by side

Server-side formatter vs jsonversal

Property
Server-side formatter
jsonversal (client-side)
Does your input leave the browser?
Yes — sent to their server
No — processed locally
Stored on a server?
Often, for save/share & history
Never
Needs an account?
Sometimes
No account, ever
Third-party requests at runtime?
Possible (analytics, CDN)
None
Breach blast radius
Every stored snippet
Zero — no data exists
You can verify it yourself?
Only by trusting their policy
Yes — DevTools Network tab
How to check any tool

The 10-second verification test

Works on any developer tool — including ours. No trust required.

  1. Open DevTools — F12 (Windows/Linux) or Cmd+Option+I (macOS).
  2. Network tab → press clear (⊘).
  3. Run the tool on some sample input.
  4. No new request? It is client-side. A POST/GET carrying your input? Your data left the browser.

Don't gamble your secrets on a server you don't control.

Open any jsonversal tool and run the test above — you'll see nothing leaves your tab.

Frequently Asked Questions

Which tools were affected by the 2025 leak?
In November 2025, security firm watchTowr Labs disclosed that JSONFormatter.org and CodeBeautify.org had exposed years of user-submitted data. The exposed surface was their 'Recent Links' / save-and-share feature, not every paste into the formatter.
What kind of data was exposed?
Researchers retrieved 80,000+ saved snippets totalling over 5 GB. The contents included Active Directory credentials, database and cloud keys (AWS / Azure / GCP), private keys, CI/CD secrets, production JWTs, OAuth tokens, SSH keys, and PII / KYC data from organisations in government, finance, healthcare, aerospace and telecoms.
Does this mean every online developer tool leaks data?
No. The failure came from a specific server-side 'save and share' feature that persisted inputs. Many online tools do not retain submissions. The durable lesson is architectural: if a tool can store your input on a server, you must assume it might — until you verify otherwise. Client-side tools remove that assumption entirely.
How is jsonversal different?
jsonversal processes everything in your browser. There is no server that receives your input and nothing is persisted, so there is no database of your data to be exposed. The same verification test applies: open DevTools → Network, and you will see no request carrying your input.
🔒
Your data never leaves your device

All processing happens in your browser. No uploads, no tracking, no servers. Your API keys, configs, and private payloads stay private — 100% client-side.

esc
↑↓ navigate ↵ open esc close