The 80,000-File Leak That Proves We Need Local-First Dev Tools
In November 2025, researchers at watchTowr Labs published a report that made rounds across every security mailing list I follow. They had scraped 80,000 saved files — over 5 gigabytes of data — from popular online developer formatting tools: JSONFormatter.org and CodeBeautify.org. The data spanned five years of continuous, silent exposure.
What they found inside wasn't theoretical. It was immediately actionable for any attacker:
- Live AWS credentials
- Production database passwords
- Active Directory logins
- OAuth tokens & SSH session recordings
- KYC records from banks & PII from healthcare organizations
Governments, telecoms, critical infrastructure providers, financial institutions. All present.
But here's what the story is really about — and it's not those two specific websites. It's about a mental model most developers have never questioned: that online tools need a server to work.
They don't. And understanding why changes how you think about every tool you use.
What Actually Happened (And Why It Could Happen Again Anywhere)
The mechanism was almost embarrassingly simple. Both JSONFormatter and CodeBeautify offered a "Save" or "Share" feature. When a developer clicked it, the formatted output was stored on a remote server and served at a predictable, enumerable URL. The sites also had "Recent Links" pages — a live feed of every snippet just saved by anyone on the planet.
The watchTowr researchers didn't need to hack anything. They just crawled.
Both platforms disabled the Save functionality after the research was published, but that misses the point. The problem isn't that two specific tools had a bad feature. The problem is the assumption underneath: that processing your data requires sending it somewhere.
That assumption is, in 2025, completely false.
What Your Browser Can Actually Do (The Part Nobody Teaches)
Modern browsers ship with a set of native APIs that are staggeringly powerful. Most developers know about fetch and localStorage. Fewer know about what runs entirely on the client — no server, no upload, no round trip.
Here's what's built into every modern browser, fully standardised, with no library required:
1. JSON.parse() and JSON.stringify()
This is so obvious it gets overlooked. Your browser can parse, validate, format, and serialize JSON entirely in memory. The entire operation of "pretty-printing a JSON blob" is a single line:
const formatted = JSON.stringify(JSON.parse(rawInput), null, 2);
The browser's V8 engine (in Chrome) processes JSON at hundreds of megabytes per second. There is no technical reason this ever needs to leave your machine.
2. DOMParser — for XML
The browser ships with a fully-standards-compliant XML parser, built in, zero dependencies:
const parser = new DOMParser();
const xmlDoc = parser.parseFromString(xmlString, "text/xml");
// now walk the DOM tree, extract nodes, convert to CSV — all local
This is a W3C standard API, available in every browser since IE 9. Parsing, traversing, and converting XML happens on your CPU. No bytes leave your machine.
3. atob() / btoa() — for Base64
Base64 encoding and decoding is literally a single function call that has existed in browsers since the beginning of time:
const decoded = atob("SGVsbG8gV29ybGQ="); // "Hello World"
const encoded = btoa("Hello World"); // "SGVsbG8gV29ybGQ="
Every online Base64 tool that sends your data to a server is doing something worse than unnecessary — it's actively creating risk for no technical benefit.
4. Web Crypto API — for JWTs and Cryptographic Operations
The window.crypto.subtle API provides hardware-accelerated cryptographic primitives directly in the browser. Decoding a JWT payload is just Base64 parsing. Verifying a JWT signature is a few lines using Web Crypto:
// Decode the payload (no verification — just reading claims)
const [, payload] = token.split(".");
const decoded = JSON.parse(atob(payload.replace(/-/g, "+").replace(/_/g, "/")));
// Verify against a public key using window.crypto.subtle.verify()
// — entirely local, zero network requests
That means your JWT decoder, your token inspector, your cryptographic utility — none of them need to touch the internet.
5. WebAssembly — for Everything Else
For computationally heavier tasks — archive extraction, image processing, complex format conversion — WebAssembly runs near-native-speed compiled code directly in the browser sandbox. The Wasm 3.0 specification, standardised in late 2025, introduced garbage collection, 64-bit address spaces, and multi-memory support, meaning full language runtimes (Java, Kotlin, Rust) can now compile to Wasm and run entirely client-side.
The SheetJS library is a practical example: it generates genuine binary .xlsx Excel files entirely in browser memory, then uses the Blob API to trigger a local download. No server generates that file. No data is transmitted.
const wb = XLSX.utils.book_new();
const ws = XLSX.utils.json_to_sheet(data);
XLSX.utils.book_append_sheet(wb, ws, "Sheet1");
XLSX.writeFile(wb, "export.xlsx"); // triggers local download
The browser is not a thin client that forwards work to servers. It is a full execution environment. It always was.
The Risk Isn't Hypothetical — It's a Compliance Violation Before an Attacker Appears
Here's something many developers haven't fully internalised: the data transfer itself is the violation, not just the breach.
- Under GDPR: Transmitting personal data of EU residents to an unvetted third-party without a Data Processing Agreement (DPA) is non-compliant — even if the third party never suffers a breach. Fines reach €20 million or 4% of annual global revenue, whichever is higher.
- Under HIPAA: Processing Protected Health Information (PHI) through an unauthorised system — one without the required Business Associate Agreement (BAA) — is a direct violation, regardless of whether the data is subsequently stolen.
This means the developer who pastes a JSON payload containing patient names into an online formatter has, technically, already created a compliance incident — before anything goes wrong.
In practice, the risk is silent and delayed. You paste the data, get your output, close the tab, and move on. Three months later, a threat actor crawls the "Recent Links" page. Six months later, the credential rotation still hasn't happened. A year later, there's an incident response.
As the watchTowr researchers put it plainly:
"We don't need more AI-driven agentic agent platforms; we need fewer critical organizations pasting credentials into random websites."
How to Verify Any Tool in 30 Seconds
You don't have to trust anyone's privacy policy. You can verify it yourself, right now, in any browser:
- Open the tool you want to check.
- Press F12 (or
Cmd+Option+Ion macOS) to open DevTools. - Go to the Network tab.
- Paste some dummy data into the tool and click Convert / Format / Process.
- Watch the Network tab.
- What you want to see: Nothing. Zero outbound requests while the tool runs.
-
What's a red flag: Any
POSTrequest firing to the tool's domain (or a third-party domain) containing your input data. That data just left your machine.
Tools that process locally will show zero outbound data requests during operation. This is verifiable, technical proof — not a marketing claim.
// In Chrome DevTools Console, you can also filter:
// Network tab → Filter → "XHR" or "Fetch"
// Then use the tool and watch what fires
The Browser-First Alternative
Once you understand that the browser can do all of this locally, the question becomes: which tools are actually built this way?
- VS Code extensions are an excellent option for developers who want to stay in their IDE — built-in formatters, linters, and a rich ecosystem of local-only utilities. Everything runs on your machine.
- For browser-based workflows, you need tools explicitly engineered for client-side processing.
I built Status202 specifically because of this problem — it's a toolkit of 18 utilities (JSON formatter/validator, JWT decoder, XML formatter, CSV/JSON/Excel converters, Base64 encoder, regex tester, URL encoder, Unix timestamp converter, cron explainer, and more) all running on your CPU with zero server uploads. The entire site is static HTML and JavaScript deployed to a CDN — there's no backend to send data to, even if you wanted to.
But the specific tools matter less than the principle. The question to ask of any online utility is: does this tool need a server to work? For JSON formatting, XML parsing, Base64, JWT decoding, CSV conversion — the honest answer is always no.
Closing Thought: A Habit Worth Building
The browser is not a terminal for remote servers. It is a powerful, sandboxed, local execution environment that ships with cryptography, binary file generation, XML parsing, and near-native compute speed — on every device, for every user, for free.
The industry's default assumption that "web tool = sends data to server" is a legacy mental model from a time before Web Crypto, WebAssembly, and the File API. That era is over.
The next time you reach for an online dev tool, spend 30 seconds checking the Network tab. Ask whether the processing is happening locally or remotely. The answer will tell you everything you need to know about whether your data — and your users' data — is genuinely safe.
That habit costs nothing. The absence of it cost those 80,000 files.
