What happens when you paste into a server-side tool
Take an ordinary example: a JSON formatter that posts your input to a server, formats it there and returns the result.
Your JSON now exists on infrastructure you do not control. It is very likely in a request log, because web servers log requests by default and request bodies are commonly captured for debugging. It may be in an error tracking service if anything went wrong. It may be in a CDN cache, an application performance monitoring tool, or a load balancer log. Each of those is a separate system with its own retention policy, its own access controls and its own backup schedule.
None of this requires bad intent. A conscientious operator who never looks at your data still has it distributed across half a dozen systems, retained for however long each of those defaults to, and included in whatever gets exposed if any one of them is breached.
Now consider what people commonly paste: bearer tokens from a production environment, database connection strings, customer records in CSV, draft contracts, financial figures before an announcement, and medical documents. Each of those has a materially different consequence if it leaks.
What client-side processing changes
A client-side tool loads its code once and then does the work in your browser. Your input goes into a text box, JavaScript running on your machine transforms it, and the result appears. No network request is made, so there is nothing to log, nothing to cache, and nothing to breach.
The distinction is not that the operator promises not to look. It is that there is nothing to look at. A privacy policy is a commitment that can be changed, misunderstood or violated; an architecture that never receives the data cannot disclose it.
This matters most in the situations where it is hardest to get approval: an employee who cannot paste customer data into an external service can use a tool that never transmits it, because no disclosure occurs.
How to check for yourself
You do not have to take any site's word for it. Two methods, either of which takes under a minute.
Watch the network. Open your browser's developer tools, go to the Network tab, use the tool, and look at what was requested. A client-side tool makes no request when you press the button. A server-side one makes an obvious POST containing your input.
Disconnect. Load the page, turn off your network connection, then use the tool. If it still works, the processing is local. This is the simpler test and it is conclusive.
Both tests are worth running on any tool you are about to trust with something that matters, including this one.
What client-side processing does not protect against
It is worth being precise about the boundaries, because "runs in your browser" is not a blanket guarantee.
- The page could change. A site that processes locally today could deploy code tomorrow that uploads. The network check tells you about the version you are running now.
- Third-party scripts are on the page. Analytics and advertising code runs in the same document. It cannot read your input unless it is written to, but it is code you did not audit. A tool serious about this keeps third-party scripts to a minimum.
- Browser extensions can read anything. An extension with permission to access page content sees everything you type, on every site. This is a far larger and less examined risk than most people realise.
- Your device is still your device. Malware, a compromised machine or someone reading over your shoulder are unaffected by where processing happens.
- Some tools genuinely need a server. An IP lookup must ask someone what your address is. A DNS query must reach a resolver. An AI tool must call a model. The honest approach is to say which tools those are, rather than claiming everything is local.
A practical policy
A simple set of rules covers most situations.
- Assume anything you paste into a server-side tool is disclosed. Not stolen, not misused - disclosed. Then decide whether that is acceptable for this particular material.
- Never paste live credentials anywhere. Tokens, keys, connection strings and passwords should not go into any web tool, local or not. If you already have, rotate them.
- Redact before you paste. Replace real names, account numbers and identifiers with placeholders. The tool almost never needs the real values to demonstrate the problem.
- Prefer local tools for confidential material. Verify with the network check, then use them.
- Use a command-line tool for the most sensitive work.
jq,openssland their equivalents never touch a browser at all.
Why more tools do not work this way
Almost everything a small utility does can run in a browser. Modern browsers have a cryptography API, canvas-based image processing, file reading, compression, and fast parsers for every common format. The technical obstacle largely disappeared a decade ago.
What remains is commercial. Server-side processing produces logs, and logs produce analytics about what users do. It enables rate limiting, which enables a paid tier. It keeps the implementation hidden rather than shipping it to every visitor. And it is simply what most developers reach for by habit.
None of those reasons benefit the person pasting a contract into a text box. Where a tool can run locally, it should - and where it cannot, it should say so plainly.
Frequently asked questions
Load the page, disconnect from the internet, and try it. If it works offline, the processing is local. Alternatively, watch the Network tab in developer tools while you use it.
For confidentiality, yes - data that is never transmitted cannot be logged or breached. It does not protect against a compromised device, malicious browser extensions, or a site changing its code later.
Rotate it immediately. Assume it is compromised, revoke it and issue a new one. Then check your provider's access logs for use you do not recognise.
Yes, and an under-appreciated one. An extension with permission to read page content sees everything you type on every site, including passwords and anything pasted into a tool. Review what you have installed and what permissions it holds.