Never Paste This Into a Random Online Tool

Everyone who works on a computer eventually ends up on some random website doing something their company’s IT department would prefer they hadn’t. That’s not a judgment — it’s just true. Formatter for some obscure config format, JSON prettifier, Base64 decoder, regex tester, diff checker. These tools are genuinely useful, and building everything internally is not realistic.

But there’s a gradient between “pasting a sample JSON blob” and “pasting the production database connection string,” and the gradient matters. This is about understanding where the line is.

The actual threat model

Before the list, it’s worth being precise about what actually happens when you paste data into a web tool — because it’s easy to imagine either too much or too little.

The server receives what you type

Unless a tool is explicitly and verifiably client-side (more on what “verifiably” means below), data you enter into a form field or upload to a tool is transmitted to a server. It goes through:

• The tool operator’s web server and application code
• Whatever logging infrastructure they have (often more than they intend — app servers log request bodies in debug mode, and debug mode sometimes leaks to production)
• Any CDN sitting in front of the tool (Cloudflare, Fastly, etc.) — CDNs typically do not log request bodies, but they do see them
• Whatever third-party analytics, error monitoring, or observability tools are embedded in the page (Sentry, Datadog, Mixpanel, etc.)

That’s four different places a secret could end up without anyone doing anything obviously wrong.

Browser extensions see everything

Any browser extension that runs content scripts — which includes most extensions that have any meaningful capability — can read the contents of input fields and textareas on any page unless the extension specifically excludes it. A malicious or compromised extension can silently exfiltrate everything you type, on every site.

This is not theoretical. Several high-profile extension supply-chain attacks in recent years (including extensions with millions of users) involved exactly this. The extension was legitimate, was acquired or compromised, and the new owner pushed an update that added data exfiltration.

If you have 40 browser extensions installed and you can’t name what each one does, that’s worth revisiting.

Search indexing and caches

Some tools (particularly older ones, or tools that are GDPR-naive) include user input in URLs or page titles. Things in URLs can end up in browser history, server logs, referrer headers on outbound links, Google Search Console, and web archive crawls. This is less common for input data but not impossible — particularly for tools that use GET parameters to share results.

The “I trust this service” assumption

Even if you trust the tool operator today, that trust has a lifetime. Companies get acquired. Startups shut down and sell their user data as an asset. Engineering teams make mistakes. A logging config change can start capturing what wasn’t captured before. A junior engineer adds request body logging to debug a production issue and forgets to remove it.

Trust is not a permanent property. A tool that doesn’t have your data cannot lose it.

What you should not paste into a random online tool

No exhaustive list, but these are the categories that consistently matter:

Credentials and secrets

• Production database connection strings (contain host, port, username, password, database name — often all in one string)
• API keys and tokens for any service (AWS, Stripe, Twilio, GitHub, OpenAI, etc.)
• .env file contents — these are essentially a manifest of every secret your application uses
• JWTs from production systems — the payload contains user identity claims; a leaked JWT is a valid session token until it expires
• SSH private keys
• TLS private keys or certificate bundles
• OAuth client secrets
• Webhook secrets used for signature verification

Personal data of others

• Customer names, emails, phone numbers — even a small export
• Any data that falls under GDPR Article 9 (health, religion, political views, biometric data)
• Employee records
• Student records (if you’re in an educational institution)

Company-confidential content

• Source code of proprietary systems (not just for NDA reasons — source code often contains hardcoded credentials, internal hostnames, and architecture details)
• Internal architectural diagrams or design docs
• Financial projections, M&A target lists, board materials
• Legal filings before they’re public

Anything under a regulatory framework

• HIPAA: any information that could identify a patient in a healthcare context
• PCI DSS: cardholder data, PANs, even in test/staging environments if the data is real
• SOC 2 controlled data per your company’s classification policy

The common thread: if something would appear in a breach notification letter to customers, it shouldn’t go into an unvetted web tool.

What is generally safe

Some things are fine to paste essentially anywhere:

• Synthetic or obviously fake data — {"user": "john_doe", "id": 12345} as an example
• Public data — something you’d put in a GitHub README anyway
• Your own personal content with no third-party PII — notes, drafts, your own code for a side project
• Non-sensitive code snippets — a CSS selector you’re trying to test, a regex pattern without any real data in it, a SQL schema without actual table data
• Error messages and stack traces — usually fine, though scrub any values in the trace that look like secrets or user identifiers

Even for “safe” data, thinking about what’s in it for a moment is a reasonable habit.

How to verify a tool is actually client-side

Several tools claim to be client-side. Here’s how to check:

1. Open DevTools (F12 in most browsers) and go to the Network tab.
2. Filter to Fetch/XHR or All requests.
3. Paste or upload your data and trigger the tool.
4. Watch for outbound requests. A genuinely client-side tool will show no requests carrying your input data — you might see a request for a WASM binary or a font, but nothing containing what you pasted.

This takes about 30 seconds and is more reliable than reading a privacy policy.

Safer alternatives for sensitive operations

Use a local tool. If you need to format JSON, jq in a terminal does it without any network involvement. If you need to decode Base64, base64 -d on macOS/Linux. Most “I need a quick tool for this” problems have a one-liner CLI solution.

Use a vetted browser-only tool. Tools that are demonstrably client-side (and where you can verify this with the Network tab method above) are meaningfully safer. For things like hashing a string, generating a strong password, or encrypting data before sharing, try our Hash Generator , Password Generator , or AES Encrypt/Decrypt — all process data locally.

Use a local LLM. If you want to use an AI assistant to explain code or check a document, a locally running model (Ollama + Llama 3, for instance) processes nothing externally. This is increasingly practical in 2026.

Use an internal tool. Many companies have internal developer portals or tooling. Slower and less polished than random web tools, but vetted by someone who presumably had your company’s interests in mind.

Write a one-off script. If you regularly need to do some transformation on sensitive data, write a small Python or Node script for it. It takes 10 minutes, runs locally, and you control it.

A decision tree

When you’re about to paste something into a web tool:

Does the data contain secrets, credentials, or PII?
├── No → Does it contain confidential business information?
│         ├── No → Probably fine. Proceed.
│         └── Yes → Is the tool verifiably client-side?
│                    ├── Yes → Verify with Network tab, then proceed.
│                    └── No → Use a local alternative.
└── Yes → Is the tool verifiably client-side AND do you trust its operator?
           ├── Both yes → Verify with Network tab, then proceed with caution.
           └── Either no → Do not paste. Use a local tool or write a script.

The point is not that web tools are bad. It’s that the decision should be conscious. “I needed to decode something quickly and didn’t think about it” is how most incidents start — not malice, not negligence exactly, just habit running ahead of thought.

That habit is worth interrupting occasionally.