Why Your Online Dev Tools Might Be Leaking Your Secrets

In November 2025, security researchers at watchTowr Labs dropped a bombshell: two of the most popular online JSON formatting tools — JSONFormatter.org and CodeBeautify.org — had been silently leaking thousands of passwords, API keys, AWS credentials, and other secrets through their "share" and "save" features. Over 80,000 files were captured, many containing production credentials for major organizations.

This wasn't a sophisticated attack. The share URLs used predictable, sequential identifiers. Anyone could enumerate them and download the stored data. The tools had been operating this way for years.

What Happened

Both JSONFormatter.org and CodeBeautify.org offered "save" or "share" features that stored user-submitted data on their servers and generated shareable URLs. The problem was twofold:

1. Data was stored server-side — every piece of JSON, XML, or code pasted into these tools was transmitted to and stored on remote servers
2. Share URLs were predictable — the generated URLs used sequential or easily guessable identifiers, allowing anyone to scrape the entire database of saved content

The exposed data included:

• AWS access keys and secret keys
• Database connection strings with passwords
• API tokens for payment processors, cloud providers, and SaaS platforms
• JWT tokens containing user session data
• Internal configuration files with production credentials
• Private API responses containing customer PII

Both sites disabled their save/share functionality after the disclosure, but the damage was done — years of accumulated secrets had been publicly accessible.

Why Developers Paste Secrets Into Online Tools

This might seem reckless, but it's incredibly common. Developers paste sensitive data into online formatters for legitimate reasons:

• Debugging API responses — you get a wall of minified JSON from a production API and need to read it
• Validating configuration — checking that a JSON config file or environment variable is syntactically correct
• Decoding JWTs — inspecting token payloads during authentication debugging
• Quick formatting — making a messy JSON payload readable before sharing with a teammate

In each case, the data often contains credentials, tokens, or internal system details. The developer's mental model is "I'm using a formatter" — they don't think about where their data actually goes.

The Client-Side Solution

The fundamental problem with JSONFormatter.org and CodeBeautify.org was that they transmitted user data to their servers. The fix is simple in principle: process everything in the browser.

A client-side tool works entirely within your browser's JavaScript engine. Your data is never transmitted over the network, never stored on a remote server, never logged, and never accessible to anyone but you. When you close the tab, the data is gone.

Here's what to look for when choosing an online developer tool:

Feature	Safe	Risky
Processing	Client-side JavaScript	Server-side API calls
Network activity	No requests when using tool	POST requests on submit
Share feature	URL hash encoding (data in URL fragment)	Server-stored with generated IDs
Works offline	Yes (after initial page load)	No — requires server connection
Open source	Verifiable behavior	Trust-based

How to Verify a Tool Is Client-Side

Don't take a tool's word for it. Verify:

1. Open browser DevTools (F12) and switch to the Network tab
2. Paste your data and click the action button (Format, Encode, etc.)
3. Check for outbound requests — if no new network requests appear when you process data, the tool is client-side
4. Test offline — disconnect from the internet and try using the tool. If it still works, your data never leaves the browser

You can also check the tool's source code in the DevTools Sources tab. Client-side tools use JavaScript functions like JSON.parse(), JSON.stringify(), btoa(), and atob() — all browser-native APIs that require no server interaction.

What About "Save" and "Share" Features?

Sharing formatted output is a legitimate need. The safe way to implement it is URL hash encoding — the shared data is encoded directly into the URL fragment (the part after #). URL fragments are never sent to the server, so the data stays client-side even when sharing.

The trade-off: URLs can get very long for large payloads. But for typical use cases — a JSON config snippet, a JWT token, a formatted SQL query — it works perfectly. If a tool requires you to create an account or "save to server" to share, that's a red flag.

Practical Steps to Protect Your Secrets

1. Use client-side tools — tools like CodeTidy process everything in your browser
2. Redact before pasting — replace real credentials with placeholders before using any online tool you don't fully trust
3. Use local tools when possible — jq, python -m json.tool, and VS Code extensions format JSON without any network access
4. Rotate exposed credentials immediately — if you've used JSONFormatter.org or CodeBeautify.org's save/share features with real credentials, rotate those credentials now
5. Audit your team's tool usage — security policies should cover which online tools are approved for handling sensitive data

The Broader Lesson

The JSONFormatter/CodeBeautify incident is a reminder that convenience and security are often in tension. These tools became popular because they were fast, free, and required no setup. But "free" had a hidden cost: your data was the product.

The good news is that modern browser APIs are powerful enough to handle virtually any text processing task — JSON formatting, Base64 encoding, JWT decoding, regex testing, code formatting — entirely client-side. There's no technical reason for these tools to touch a server. If a tool sends your data to a server, it's either monetizing that data, or it's poorly designed. Either way, you deserve better.

Every tool on CodeTidy processes your data 100% in your browser. Your JSON, your tokens, your configs never leave your machine. We think that should be the default for every developer tool on the web.