Free online utilities save real time. Format some JSON, decode a token, clean a list, check a page's meta tags — the alternative is usually installing something or writing a script, and for a two-minute job neither is worth it.
The risk is that the two-minute job often involves data that should not leave your organisation. An API response with customer records. A subscriber export. A configuration file with credentials in it. And pasting that into a random web form is, in regulatory terms, a disclosure to a third party.
The good news is that the important distinction is simple, and you can usually verify it yourself.
The question that matters
Does the tool process your data in your browser, or does it send it to a server?
Client-side tools run JavaScript on your own machine. Your data never crosses the network. Close the tab and it is gone. There is nothing to log, nothing to breach, and nothing to subpoena.
Server-side tools upload your input, process it elsewhere, and send back a result. That is not automatically wrong — some things genuinely cannot be done locally — but it means your data now exists on someone else's infrastructure under terms you probably have not read.
Most text-processing tasks can be done entirely client-side. Formatting, encoding, converting, counting, extracting, generating. If a tool that could run locally chooses to upload instead, that is worth a second thought.
How to check
Open the network tab. Press F12, go to Network, clear it, then use the tool. If no request is made when you click the button, the processing happened locally. This takes fifteen seconds and is definitive.
Try it offline. Load the page, disconnect from the network, and use the tool. If it still works, it is client-side. It cannot be anything else.
Read what the site claims, then verify it. Plenty of tools say "your data never leaves your browser". The network tab tells you whether it is true.
When server-side is unavoidable
Some things require a server by their nature. Fetching a remote page to check its meta tags, for instance — browsers are not permitted to request arbitrary other websites, so that has to go through a server. Anything involving a database lookup, a rendered screenshot or a large file conversion is the same.
For these, the question becomes whether you are comfortable with this particular data on this particular service. A public URL is not sensitive. Your internal API response is.
What to look for before trusting a server-side tool
- A privacy policy that says what happens to uploads — specifically, whether they are stored, for how long, and whether they are used for anything else
- HTTPS, without exception
- A named operator. A tool run by an identifiable company with a contact address is accountable in a way that an anonymous site is not
- Retention that is stated rather than implied. "Files are deleted after one hour" is a commitment; silence is not
- An absence of aggressive advertising. A site monetised by ad networks that fingerprint visitors is telling you something about its priorities
The categories to be most careful with
Anything with credentials in it. JWTs, API keys, connection strings, configuration files. A JWT payload is Base64 and trivially decoded — but pasting a live token into a server-side decoder hands someone a working credential. Decode it locally.
Personal data. Customer lists, email exports, anything with names and contact details. Under GDPR and similar regimes, uploading this to a third-party service is processing by a processor, which requires an agreement you almost certainly do not have with a free web tool.
Internal documents. Contracts, financial figures, anything under NDA. The obligation is contractual as well as regulatory.
Source code. Proprietary code pasted into a formatter is a disclosure. It is also, increasingly, potential training data.
A practical policy
You do not need a committee for this. Three rules cover most situations:
- Verify client-side processing for anything non-public. Fifteen seconds in the network tab.
- Use fake data to evaluate a tool. Try it with a sample first. You learn whether it works without disclosing anything.
- If it must be server-side and the data is sensitive, do it locally instead. A short script, a local application, or a command-line tool. Slower once, safer permanently.
Where we stand on this
Since it would be evasive not to say: every tool on this site runs in your browser, with one exception. The Meta Tags Checker has to fetch the page you name, and browsers cannot request arbitrary other sites, so that request is made by our server. The URL you enter is therefore sent to us; nothing else on the site is.
You do not have to take that on trust. Open the network tab and check.
