Never Paste This Into a Random Online Tool

Everyone who works on a computer ends up on some website their IT department would rather they had not opened. A formatter for an obscure config dialect, a Base64 decoder, a regex tester, a diff checker. These tools are useful and building internal versions of all of them is not a real plan.

The gradient between pasting a sample payload and pasting a production connection string is the entire subject. Here is where the line sits and how to tell which side of it you are on.

Where a paste actually lands

Extensions read it first. A content script gets direct DOM access to every page matching its patterns, which means the value of any input or textarea². It runs in an isolated world and cannot see the page's own JavaScript variables, which sounds reassuring until you remember that reading a textarea does not require any.

This is not a hypothetical. In December 2024 a phishing campaign sent extension developers fake policy-violation notices, walked them into authorising a malicious OAuth application, and used that access to push compromised updates through roughly a dozen legitimate Chrome extensions. The injected code lifted ChatGPT session data and OpenAI API keys, plus Facebook Business credentials, straight out of the pages users had open¹.

Nobody in that story installed something shady. They installed a normal extension and let it auto-update, which is what auto-update is for.

The CDN sees the body. Cloudflare, Fastly and the rest generally do not log request bodies, but the bytes pass through them by design.

The application handles it. This is the part people picture, and it is the least interesting one.

The logs keep it. Request-body logging gets switched on to debug something and switched off later, or not. This is the most common way a secret ends up somewhere nobody chose to put it.

The page's own third parties collect it. Error monitoring and product analytics run in the same document as the textarea. Session replay and form-state capture are features people pay for.

Trust has a shelf life

Even a well-run tool you trust today is a company that can be acquired, wound down, or have its user data sold as an asset. Configuration changes. Staff turn over. None of that requires bad faith.

A tool that never receives your data cannot lose it, and cannot change its mind about it later.

What goes where

Never, into an unvetted tool. Production connection strings, which usually carry host, port, username and password in one convenient string. API keys and tokens for anything. The contents of a .env file, which is a manifest of every secret an application holds. Production JWTs, which are valid sessions until they expire. SSH and TLS private keys. OAuth client secrets and webhook signing secrets.

Other people's personal data belongs here too, including anything in the GDPR's special categories: racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, genetic data, biometric data used for identification, health data, and data about sex life or sexual orientation³. So do regulated records generally, and PCI cardholder data even in staging when the data is real.

Verify, then decide. Internal source code, which tends to carry hardcoded credentials and internal hostnames alongside the logic you actually wanted to check. Architecture documents. Unreleased financials. Anything under an NDA.

Fine anywhere. Synthetic data. Anything already public. Your own notes. A selector or a pattern with no real values in it. Stack traces, after you have read them, because a trace carries whatever happened to be in scope.

The test that covers all of it: if this would appear in a breach notification letter, it does not go into an unvetted tool.

The thirty-second check

Plenty of tools claim to run locally. Checking is faster than deciding whether to believe them.

1. Open DevTools and go to the Network tab.
2. Filter to Fetch/XHR.
3. Run the tool on a small, harmless sample.
4. Look for a request carrying your input.

A genuinely local tool shows nothing of the sort. You may see it fetch a WebAssembly module or a font, and neither of those contains what you pasted. An uploading tool shows a request about the size of your data, and there is no ambiguity about it.

That is evidence. A privacy policy is a claim.

What to do instead

Reach for the command line. jq . formats JSON, base64 -d decodes, openssl handles most crypto chores. Most "I need a quick tool" moments have a one-line answer that never touches a network.

Use a tool you have verified. Local processing is a property you can check, and it does not expire. Our Hash Generator , Password Generator and AES Encrypt/Decrypt all run in the page with no upload, and the Network tab will confirm that rather than requiring you to take our word for it. Which is the point: apply the same check to us.

Run the model locally. If the task is "explain this code" or "summarise this document", a model running on your own machine through something like Ollama sends nothing anywhere. This has stopped being an enthusiast setup.

Write the script. Ten minutes of Python or Node for a transformation you do repeatedly, and you own the whole path.

Use the internal tool. Slower, uglier, vetted by someone whose job included caring.

The habit, not the incident

The point is not that web tools are dangerous. It is that the choice should be a choice. Almost no incident starts with someone deciding to leak a credential. It starts with needing to decode something quickly, at the end of a long day, with the terminal in another window.

That is the moment worth interrupting.