Why You Should Never Paste Sensitive Data Into Online Tools

Every developer has done it: you need to quickly format a JSON blob from a production API response, decode a JWT from a live system, or check a database URL — so you paste it into the first online tool that comes up in search. It takes two seconds, it's convenient, and it feels harmless. It isn't.

What Counts as Sensitive Data?

Before getting into the risk, it helps to be clear about what "sensitive data" actually includes when using developer tools:

• API keys and tokens — AWS, Stripe, GitHub, OpenAI, Twilio, SendGrid
• JWT tokens — contain encoded user identity, roles, and session info
• Database connection strings — include credentials, host, and database name
• Private keys and certificates — TLS/SSL private keys, SSH keys
• OAuth secrets — client IDs and secrets for third-party integrations
• Passwords — in any format, including hashed
• Production data — customer records, PII, financial data in JSON or CSV
• Internal URLs and hostnames — can reveal infrastructure

If the data could be used to access a system, impersonate a user, or extract business information — it's sensitive. When in doubt, treat it as sensitive.

What Actually Happens When You Use a Server-Side Tool

Most online developer tools — JSON formatters, JWT decoders, base64 encoders, URL parsers — look identical in the browser whether they're client-side or server-side. But there is a fundamental difference in what happens when you click "Format" or "Decode":

Client-side tool

Your input is processed by JavaScript running in your browser. Nothing leaves your machine. The tool's server never sees your data.

Server-side tool

Your input is sent as an HTTP request to the tool's server, processed there, and the result is returned. The server has received your data. What happens to it after that depends on the tool's logging configuration, analytics setup, and the honesty of its operators.

That server may log requests (standard practice for debugging and analytics). The logs may be stored in a database that has weaker security than your production systems. The operator may sell aggregate data. The site may be using third-party analytics that records request bodies. Or, in the worst case, the operator may be intentionally harvesting credentials.

The JSONFormatter and CodeBeautify Incident

This isn't theoretical. In a documented incident, JSONFormatter.org and CodeBeautify.org — two of the most popular developer tool sites, used by millions of developers monthly — exposed 5 GB of user data including API keys, database passwords, JWT tokens, and internal credentials.

The data came from developers who had pasted production credentials into these tools, either directly (a JWT with a user token) or embedded in larger JSON payloads (an API response containing keys). The tools processed the data server-side and stored it.

Read the full breakdown: The JSONFormatter & CodeBeautify Data Leak

The JWT Problem Is Especially Severe

JWT tokens are a particularly dangerous thing to paste into online tools. A JWT looks like random text — three base64 segments separated by dots — but the payload contains real data:

// A typical JWT payload (decoded) from a production system:
{
  "sub": "user_8f2a1b3c",
  "email": "alice@company.com",
  "role": "admin",
  "org_id": "org_9d4e2f1a",
  "permissions": ["read:all", "write:all", "delete:all"],
  "iat": 1712600000,
  "exp": 1712686400
}

If this token is valid and not yet expired, anyone who has it can authenticate as that user. Pasting it into a server-side JWT decoder hands that capability to the tool's operator.

We wrote more about this: Why You Should Never Paste JWT Tokens Into Online Tools

How to Spot a Server-Side Tool

The easiest test: open DevTools → Network tab, paste something into the tool, and click the action button. Watch for outgoing requests.

• No outgoing requests → client-side. Your data never left the browser.
• XHR or Fetch request to the tool's domain → server-side. Your data was sent to their server.

A second test: disconnect from the internet and try the tool. Client-side tools continue working. Server-side tools fail.

Safe Alternatives: Client-Side Tools

All tools at devessentials.dev run 100% in your browser. Your data is never sent to a server. You can verify this yourself using the Network tab — no outgoing requests when you use any tool here.

If You Must Use a Server-Side Tool

Sometimes you don't have a choice — a team uses a specific tool that's server-side. In that case:

• Anonymize the data first. Replace real values with placeholders before pasting. Replace "api_key": "sk-live-abc123" with "api_key": "REDACTED".
• Rotate credentials immediately after. If you pasted a real API key, treat it as compromised and rotate it — even if you trust the tool.
• Use a local alternative. Install the formatter or decoder locally and run it in your terminal. jq, yq, python -m json.tool, and jwt-cli are all offline tools that work entirely on your machine.
• Use your editor. VS Code, JetBrains IDEs, and most modern editors can format JSON, YAML, and XML without sending data anywhere.

A Habit Worth Building

The security principle here is simple: treat your production data like you treat your passwords. You wouldn't type your password into a random website to check if it's strong — use a local tool or a client-side one. Apply the same rule to API keys, JWT tokens, database credentials, and any data from production systems.

It takes two seconds to check the Network tab. One data leak can take months to recover from.

All devessentials.dev tools are 100% client-side — your data never leaves your browser. Browse all tools →