Are Free Online Tools Safe? A Privacy Guide

Free online tools are safe when they do their work inside your browser and never send your data anywhere. They're a genuine risk when they quietly upload whatever you paste to a server run by people you've never heard of, under a retention policy you've never read. The confusing part is that the two kinds look identical. Same box, same button, same instant result. Nothing on the surface tells you which one you're using. So the real question isn't whether free tools are safe in general, it's how to tell them apart, and that turns out to be a thirty-second check anyone can run. Here's how.

Are Free Online Tools Actually Safe?

It depends on one thing, and it isn't price. It's where the processing happens.

A browser-based tool loads its code onto your machine and runs it there. You paste something in, JavaScript does the work locally, and the result appears. Nothing was transmitted, so there's nothing on a server to leak, subpoena, or sell. Even if that company were hostile, they'd have nothing of yours to be hostile with.

A server-based tool sends your input across the internet to be processed and returns the answer. Now your data sits on hardware you don't control, for a period you don't set, protected by security you can't audit. That's not automatically bad. It's just a completely different risk profile, and you deserve to know which one you're accepting.

Worth keeping the stakes in view, and the direction of travel is not good. In testimony to Congress's Joint Economic Committee, the US Federal Trade Commission put reported fraud losses at 15.9 billion dollars in 2025, the highest on record and, by the FTC's own count, about 25 percent up on 2024. Fraud reports climbed from 2.6 million to 3 million over the same period, and reported losses have risen nearly 430 percent since 2020. Within the 2025 total, the FTC reported 3.5 billion dollars lost to imposter scams alone, with those losses up nearly threefold since 2020.

One breakdown is worth pausing on, because it says something about where exposure actually starts. In April 2026 the FTC reported that nearly 30 percent of people who lost money to a scam in 2025 said it began on social media, accounting for 2.1 billion dollars. Almost none of this involves online utilities. But it's the environment your data lands in once it's out of your hands, and it's why "who ends up holding this" is a reasonable question to ask of a free text box.

What's the Difference Between Client-Side and Server-Side?

Client-side means your browser does the work. Server-side means someone else's computer does. Here's how that plays out:

Client-side isn't universally better. Some jobs genuinely need a server, because your laptop can't transcode a two-hour video or run a large model. The point isn't that servers are evil. It's that a text formatter, a JSON validator, a case converter, or a base64 encoder has no technical reason whatsoever to upload your content. If one does, that's a choice someone made, and it's fair to wonder why.

The technical foundation for local work is standardised. The W3C File API, currently a Working Draft, defines interfaces like FileReader that read a selected file into memory on the user's own device. Reading and transmitting are separate steps. A developer has to deliberately add the upload.

How Can You Tell Which Kind a Tool Is?

Three checks, in order of effort.

1. Watch the network. Press F12, open the Network tab, clear it, then use the tool. If your content is being uploaded you'll see a POST request appear, and you can click it and read exactly what was sent. If nothing shows up beyond fonts and scripts, the work happened locally.
2. Pull the plug. Load the page, then turn off your wifi and use the tool anyway. A genuine client-side tool carries on working. A server-based one breaks instantly.
3. Read the privacy policy for one specific thing. Not the whole document. Just search it for "upload", "store", "retain", and "third party". If a tool claims local processing but its policy describes storing your files, believe the policy.

The network check is the one that's hardest to spin. Marketing copy is words. A POST request carrying your document is evidence. It has limits though, and the next section covers what they are.

What Can't the Network Tab Test Tell You?

Time to be honest about the limits of the advice above, because a clean Network tab is strong evidence and it isn't a guarantee. It tells you what a page did once, on your machine, in that moment. It doesn't tell you what it will do tomorrow, or what it does for someone else.

Almost no tool ships entirely its own code. Pages pull in scripts from other people's servers: analytics, ad code, fonts, utility libraries. Every one of those is a door into a page that otherwise handles your data perfectly well. The W3C's Subresource Integrity specification, a Working Draft dated 20 March 2026, describes the problem in one line: an attacker who can replace the file on the CDN server has the ability to inject arbitrary content. It's the reason SRI exists, defining what the spec calls a mechanism by which user agents may verify that a fetched resource has been delivered without unexpected manipulation.

This isn't hypothetical. The clearest example is the polyfill.io compromise. Security firm Sansec published its findings on 25 June 2024, reporting that over 100,000 sites were serving malicious code from a compromised CDN, among them JSTOR, Intuit, and the World Economic Forum. A Chinese company had acquired the domain and its GitHub account in February 2024 and started injecting a payload into scripts thousands of sites loaded without thinking about it.

The behaviour of that payload is the part worth studying, because it was built specifically to survive checks like the one this article recommends. Per Sansec, the code only targeted mobile users, redirecting them to a sports betting site through a domain dressed up to look like Google Analytics. It checked cookies for admin identifiers and stayed quiet when it found them. It fired only during certain hours. And it delayed execution when it detected web analytics running, so it wouldn't turn up in anyone's statistics. Someone opening devtools on a desktop at the wrong hour would have seen nothing at all.

So what does that mean for you, practically? Not that the test is worthless. It's still the best signal available, and a tool that fails it has told you something conclusive. But treat it as a snapshot rather than a certificate:

• Recheck occasionally for tools you use with sensitive material. Code changes. Ownership changes. A tool that was clean last year may not be the same tool.
• Fewer third-party scripts is a real signal. If the Network tab shows a page loading from a dozen different domains, that's a dozen parties who could change something. A page loading almost everything from its own domain is a smaller target.
• Match the effort to the stakes. Formatting sample JSON needs none of this. Handling a client contract deserves a fresh look, or an offline tool.

None of this is unique to free tools, incidentally. Paid services load third-party scripts too, and the polyfill victims included some very well-resourced organisations. It's a property of how the modern web is assembled, not a symptom of something being free.

Can a Page Prove It Won't Send Your Data Anywhere?

Closer than anything above manages, and it's the one check that survives the problem the last section just described. The Network tab tells you what a page did once. This tells you what the browser will refuse to let it do at all.

The mechanism is a Content Security Policy, a header the page sends and the browser enforces. One directive inside it does the work here: connect-src, which the MDN reference describes as restricting which URLs can be loaded using script interfaces for network connections.

The list it covers is the list that matters for getting your data out: fetch(), XMLHttpRequest, WebSocket, EventSource, navigator.sendBeacon(), and the ping attribute on links. A request to anywhere outside the policy is blocked and never loads.

Read that against the polyfill attack above. That payload worked because injected code could call out to a server of the attacker's choosing. A page serving connect-src 'none' takes that option away, and it takes it away from every script on the page, including one that arrives compromised from a CDN tomorrow. It's the difference between a tool saying it doesn't upload your data and the browser refusing to let it.

How to check, in about twenty seconds:

• Open devtools and go to the Network tab. Reload, click the first request, the document itself, and look at Response Headers.
• Find Content-Security-Policy. If there isn't one, you've learned something too. A tool handling sensitive input with no policy at all has left the door open even if it never walks through it.
• Read the connect-src value. 'none' is the strongest thing you'll see. 'self' means it can talk to its own origin and nowhere else. A long allowlist of other domains is worth reading carefully.

Now the honest limits, because this is a strong signal rather than a proof.

connect-src governs scripted connections. It does not cover navigation, form submissions, or loading images, stylesheets and scripts, which sit under form-action, img-src and the rest. So a page could in principle still leak something through a permissive img-src by requesting an image with your data in the URL. Reading the whole policy rather than one directive is the thorough version.

And a policy can change on the next deploy, the same way the code can. But there's a real asymmetry worth having: the Network tab shows you one moment's behaviour, while a restrictive policy constrains every moment until someone deliberately loosens it. For anything sensitive, a tool with a tight connect-src deserves more trust than one that merely looked quiet when you watched it.

Can a Tool Fake Working Offline?

Yes, and this is the blind spot in the airplane mode test recommended above. Worth knowing before you treat that test as proof.

The logic of the offline check is sound. Turn the network off, use the tool, and if it still works then the processing must be happening on your device. Nothing can reach a server that isn't reachable.

That reasoning holds for the processing. It doesn't hold for what happens next.

Why the page loads at all with no network

Modern sites can register a service worker, which the W3C Service Workers specification describes as a worker that wakes to receive events, operating independently of any particular page. It can intercept network requests through fetch events and keeps a request and response store similar in design to the HTTP cache.

That's the mechanism behind offline-capable web apps generally, and it's a genuinely good thing. But it means a page loading without a network tells you a service worker cached it. On its own, it tells you nothing about where your data ends up.

The part that should give you pause

There's a companion capability called Background Synchronization. Mozilla's documentation on the Background Synchronization API describes it plainly: it lets web apps defer tasks so they run in a service worker once the user has a stable connection again. A sync event fires as soon as the network comes back, and queued requests go out then.

The documentation's own example is an email client that lets you compose messages with no connection and sends them when one returns.

Read that against the offline test and the problem is obvious. A tool could accept your file with the network off, queue an upload, and send it the moment you reconnect. You'd have watched it work offline and concluded it was client-side.

And the timing is worse than you'd guess. The W3C spec notes service workers are started and kept alive by their relationship to events rather than to documents, and may run without an attached document. Mozilla makes the same point directly: the tasks run in the service worker, which continues after the user has closed the page. So the upload doesn't need your tab open to happen.

How to close the gap

Two additions, neither of which takes long.

Check whether a service worker is registered. In Chrome devtools, the Application panel has a Service Workers section. If nothing is registered, Background Sync isn't available to that page and the offline result means what you hoped it meant.

Watch the network tab after you reconnect. This is the one people skip. Run the tool offline, then turn the network back on with devtools still open and the Network tab recording, and wait a minute. A queued upload shows up here and nowhere else.

Some proportion is worth keeping. Background Sync has limited browser support and isn't yet Baseline, it needs a secure context, and the overwhelming majority of tools that work offline are exactly what they appear to be. Nobody is building a covert sync queue into a JSON formatter.

But if the data mattered enough that you ran the offline test in the first place, spending another minute watching the reconnect is a reasonable trade. And it's the same principle running through this whole guide: a test that can only confirm what you hoped isn't much of a test.

Can You Check Any of This on a Phone?

Not the way the last two sections described, because phones don't have a Network tab. But there's one test that actually works better on a phone than on a desktop, and it takes about ten seconds.

This matters more than it first sounds, and the polyfill case above is exactly why. That payload only fired for mobile users. Read that alongside everything this article has recommended and the shape of the problem appears: the people who couldn't open devtools were the ones being targeted. That isn't a coincidence. If you're building something to survive inspection, you aim it at the audience that can't inspect.

So here's the test that does work. Load the tool's page and let it finish loading. Turn on airplane mode. Now use the tool. If it still does its job with the radio off, the processing is happening on your device, because there's nothing else it could be. If it errors, hangs, or spins, something needed a server.

Airplane mode is a single toggle in Control Centre or quick settings, which makes this genuinely easier on a phone than the equivalent faff on a laptop. It's the one piece of verification in this whole article where mobile has the advantage.

Be clear about what it proves, though. It shows the work happens locally. It does not prove nothing gets sent afterwards. A tool could hold what you gave it and transmit once you reconnect, and airplane mode would look perfectly clean throughout. So treat it as evidence of local processing rather than proof of zero transmission, which is the same distinction the Network tab section drew.

Proper inspection on mobile is possible, but it needs a computer and a cable, which rather makes the point:

• Android. Chrome supports remote debugging over USB, so you connect the phone, open the inspector on a Windows, Mac or Linux machine, and get the same Network tab you'd have on the desktop.
• iOS. Apple's Web Inspector does the equivalent: enable it on the device, connect by cable, and the phone shows up under Safari's Develop menu on a Mac. From Chrome 115 you can inspect Chrome on iOS the same way after switching on Web Inspector in its content settings.

Which is the honest conclusion. If you're going to verify something properly, you'll be sitting at a computer regardless, so you may as well do the sensitive work there too.

For everything else on a phone:

• Verify once on a desktop, then use the same URL on mobile. Not airtight, given the polyfill payload discriminated by device, but far better than never having looked.
• Watch which browser you're actually in. Tapping a link inside a social or messaging app usually opens an in-app browser rather than your real one. Different container, different rules, and not the environment you checked.
• One risk does drop on mobile. Phone browsers mostly don't run extensions, so the whole category covered in the next section largely doesn't apply. Small consolation, but real.
• Match effort to stakes, again. Counting words in a draft on your commute is fine. Anything you'd mind seeing leaked can wait until you're at a desk.

Can a Browser Extension See What You Paste?

Yes. And this is the hole the Network tab test can't close, because the leak doesn't use the network at all.

An extension with permission for a page can read that page. Google's own Chrome for Developers documentation on content scripts states it plainly: content scripts run in the context of web pages, and using the standard Document Object Model they can read details of the web pages the browser visits, make changes to them, and pass information to their parent extension. That last clause is the one that matters. Reading the page and handing what it finds to the extension are both local operations.

So picture what happens on a genuinely client-side tool. You paste a contract into a text box. The tool never transmits it, exactly as promised. An extension with host permissions reads it straight out of the DOM. Nothing appears in the Network tab of the page you're looking at, because the page didn't send anything. The tool kept its promise and your contract left anyway.

Permissions are the thing to watch. Chrome's model lets an extension request access to specific sites or to every site you visit. An extension holding broad host permissions can read any page you open, and most people grant that at install time without reading the prompt.

This isn't theoretical, and the interesting part is that the extensions doing it were legitimate right up until they weren't. Sekoia's Threat Detection Research team published an analysis on 22 January 2025 of a campaign that worked like this. Attackers phished extension developers with fake Chrome Web Store emails, got them to authorise a malicious OAuth application called "Privacy Policy Extensions," and used the resulting permission to see, edit, update and publish to push tainted updates into extensions people already trusted. Around a dozen were compromised in December 2024, with Cyberhaven's own extension hit on 24 December and disclosed on the 26th. Sekoia notes the same infrastructure shows evidence of campaigns going back to at least 2023, and that the approach could affect hundreds of thousands of end users with minimal effort or sophistication. The payloads went after OpenAI API keys, ChatGPT authentication tokens, and Facebook Business credentials and session cookies.

Read that alongside the polyfill case above and a pattern emerges. Both attacks compromised something already installed and trusted rather than tricking anyone into visiting a bad site. Your own vetting was done correctly and then quietly invalidated by an update.

What actually helps here:

• Audit your extensions. Open your browser's extensions page and look at what each one can access. Anything claiming access to all sites should be earning it.
• Remove what you don't use. Dormant extensions still hold their permissions, and an abandoned one is a prime acquisition target.
• Restrict access where the browser lets you. Chrome allows you to set an extension to run on click, or only on specific sites, instead of everywhere.
• Use a clean profile or private window for genuinely sensitive work. Extensions are typically disabled in incognito unless you explicitly allow them, which is the simplest way to take them out of the picture.

The honest summary is that client-side processing protects you from the tool's operator, which is a real and worthwhile thing. It doesn't protect you from software you installed yourself and gave permission to watch. Those are different threats and only one of them shows up in the Network tab.

Can a Web Page Read Your Clipboard Without You Pasting?

Not silently, no. And this is worth knowing because it's the fear that sits underneath the whole topic. You copy a password out of your manager, then open a text tool in another tab. Can that page just help itself to what's on your clipboard?

The browser is designed to stop exactly that. The W3C Clipboard API and events specification, a Working Draft dated 24 June 2026, sets out when a page is allowed to read clipboard data at all. It comes down to three routes. The action is invoked from the browser's own interface, meaning a Paste menu entry or the keyboard shortcut. Or the site has been given permission to read the clipboard through a browser-specific mechanism. Or the code is running in an app that already holds clipboard read permission.

Read that list again and notice what isn't on it. "The page felt like it" is not a route. For the asynchronous clipboard methods the spec runs a permission check first, and where permission isn't granted the call is rejected with a NotAllowedError rather than quietly returning your data. Mozilla's documentation for Clipboard readText adds another constraint: reading from the clipboard can only be done in a secure context, so an HTTP page can't do it at all.

Writing is the looser half, which surprises people who assume it works the other way round. The spec allows a page to write to the clipboard when the action comes from the browser's own Copy interface, or from a scripting thread allowed to show a popup. That's why a "copy to clipboard" button on a tool page works without ever asking you anything, while a "paste from clipboard" button often triggers a permission prompt. Same clipboard, different risk, different rules.

One more detail from the spec that's quietly reassuring. Synthetic clipboard events, meaning ones a script fires itself rather than ones you triggered, can't modify the actual system clipboard. So a page can't fake a copy event to swap what you're carrying.

What this means in practice:

• Opening a tool page doesn't leak your clipboard. The permission model is doing real work here. Your copied password isn't readable just because a tab is open.
• Treat a clipboard permission prompt as a decision, not a nuisance. If a page asks to read your clipboard and you didn't click anything resembling paste, decline it. A legitimate paste button doesn't need to ask out of nowhere.
• Pasting is still you handing it over. None of this protects you once you press Ctrl+V. The permission model guards against theft, not against your own paste into a server-side tool.
• Clear the clipboard after copying a credential. Copy something harmless afterwards. Good password managers clear it automatically after a timeout, and it costs you nothing to check yours does.

The honest summary: the clipboard is better protected than most people assume, and the risk in a paste-based tool has almost nothing to do with the clipboard API and everything to do with where the text goes after you paste it. Which is the rest of this guide.

Can a Client-Side Tool Still Track You?

Yes, and this is the caveat that undercuts the whole client-side argument if you're not careful about what you're actually claiming. A tool can process your data entirely in your browser, never send a byte of it anywhere, and still know exactly who you are every time you come back.

Because there are two separate questions hiding in "is this tool private." One is what happens to your data. That's what the Network tab test answers, and client-side processing genuinely settles it. The other is what happens to you, and nothing above touches that.

The mechanism is browser fingerprinting. The W3C's Mitigating Browser Fingerprinting in Web Specifications, a Group Note published 25 September 2025, defines it as the capability of a site to identify or re-identify a visiting user, user agent, or device via configuration settings or other observable characteristics. No account, no cookie, no upload required.

The Note splits it into kinds that are worth telling apart:

• Passive fingerprinting works from what your browser sends anyway, without running any code. HTTP headers, your User-Agent string, your IP address. A completely static page gets this for free.
• Active fingerprinting uses JavaScript to look at more: window size, installed fonts, connected devices, performance characteristics. Here's the uncomfortable part. Client-side tools run a lot of JavaScript by design, because that's how they avoid uploading your file. The same capability that keeps your data local is the capability that reads your configuration.
• Cookie-like fingerprinting re-identifies you through state the site stored earlier, which the Note notes can circumvent your cookie-clearing.

Two lines from that document deserve to be read slowly. Fingerprinting, it says, allows for tracking of activity without clear indications that such collection is happening. And tools such as clearing cookies or using a VPN do not prevent further correlation.

Read together, that's a warning about the defences most people think they already have. You cleared your cookies. You turned on the VPN. Neither necessarily breaks the link.

So what's the honest advice? Mostly that you should stop conflating two different things:

• Client-side processing protects your content, not your identity. Both matter, but they're not the same promise, and a site claiming "we never see your files" has said nothing about whether it recognises you.
• Judge it by what's actually at stake. Being re-identified by a JSON formatter is a very different problem from a contract leaking. For most tool use, fingerprinting is a nuisance rather than a risk.
• Fewer third-party scripts helps here too. Same signal as the supply chain section above. The parties who can fingerprint you are the parties whose code runs on the page, so a page loading from one domain has fewer of them than one loading from twelve.
• Don't expect to win this one outright. Anti-fingerprinting measures in privacy-focused browsers help, but the W3C's own framing is mitigation rather than prevention. Treat it as reducing exposure, not eliminating it.

Worth being clear about the status of that document too. It's a Group Note endorsed by the Privacy Working Group, not by W3C itself nor its Members, so it's guidance for spec authors rather than a standard anyone has to follow.

What Stays Behind on Your Own Device?

More than most people expect, and this is the blind spot in the entire client-side argument.

Every check in this guide so far asks one question: does your data get uploaded? That's the right question, and it's only half of them. "Your data never leaves your device" is a claim about the network. It says nothing whatsoever about what's still sitting on the device once you close the tab.

On your own laptop that's usually fine. On a work machine, a shared desktop, a library terminal or a hotel business centre, it's the actual exposure, and it's the one nobody warns you about because everyone is busy congratulating client-side tools for not uploading anything.

Where it actually lands

localStorage. The big one. The WHATWG's HTML Standard section on web storage describes it as storage that spans multiple windows and lasts beyond the current session. There's no expiry. Close the browser, restart the machine, come back next month, and it's still there.

The specification is blunt about what that can mean. It tells browser makers to treat persistently stored data as potentially sensitive, noting it's quite possible for emails, calendar appointments, health records or other confidential documents to end up stored in this mechanism. That's the standards body describing the risk in its own text, not a security vendor selling something.

sessionStorage. The better-behaved sibling, scoped to a single transaction and cleared when the tab closes. Plenty of tools use it. You can't tell which one a tool picked by looking at the interface.

The cache. The page and its scripts, which is exactly what makes the offline test earlier in this guide work. Usually harmless, occasionally more than the scripts.

The URL. This is the sharp one and it catches people who are otherwise careful. Some tools encode your input into the query string or the fragment, so you can bookmark or share a result. Convenient, and it means your input is now in your browser history, in address bar autocomplete, and potentially in whatever your browser syncs between devices. A client-side tool that never sends a byte to a server can still write your data straight into your history.

How to check in about thirty seconds

You already know how to open the tools for this. Same panel as the network check earlier, different tab.

Open DevTools, go to the Application tab, and look under Local Storage and Session Storage for the site's origin. If a tool has kept what you typed, you'll see it sitting there in plain text. It takes longer to read this paragraph than to run the check. The section on telling client-side from server-side covers opening DevTools if you haven't done it before.

And glance at the address bar while you work. If your input shows up in the URL, you've learned something without opening anything.

What to do about it

• On your own machine, mostly relax. Then clear that origin's storage after you've run anything genuinely sensitive through it. One right-click in the Application panel does it.
• On a shared machine, use a private window. Private and incognito modes discard storage when the window closes, which is the behaviour you want. And close the window rather than just the tab, because that's what actually ends the session.
• Check what your browser syncs. If you're signed into your browser, some categories travel to your other devices. Worth knowing which ones before you paste something into a tool that puts input in the URL.
• Prefer tools that forget. A tool that reloads empty is telling you something useful. A tool that helpfully restores your last input is telling you where that input has been sitting.
• If it's a work device, this is a policy question too. Residue on a company laptop is company data on a company asset, which the section on doing this at work covers.

None of this is an argument against client-side tools. Processing in the browser is still the better architecture and the rest of this guide stands. The point is narrower: "never uploaded" and "leaves no trace" are two different promises, and only one of them is being made. If you've already run something sensitive through a tool and want the fuller cleanup, the section on what to do if you already pasted something picks it up from there.

Advertisement

What Data Do Free Tools Actually Collect?

Even a fully client-side tool isn't collecting nothing, and it's worth being clear-eyed about that rather than pretending otherwise. There are usually three layers:

• Your content. The text, file, or numbers you put in. This is the layer that actually matters, and the one client-side tools genuinely don't receive.
• Standard web request data. Your IP address, browser and operating system, referring page, and the time. Every web server logs this just by serving you a page. It says nothing about what you typed.
• Analytics and advertising. Which pages you visited, how long you stayed, roughly where you are. This site runs Google Analytics and AdSense, and so do most free tools, because that's what pays for them. Our privacy policy spells out what that covers.

The distinction people miss: a tool can know that someone in your city opened a JSON formatter at 2pm without knowing a single character of the JSON. Those are wildly different levels of exposure, and lumping them together makes it harder to think about the one that counts.

Can You Get Your Data Deleted Afterwards?

Sometimes, and it's worth knowing the mechanism exists. But manage your expectations, because the legal right and the practical outcome aren't the same thing.

If the operator falls under UK or EU data protection law, you have a right to erasure. The ICO's guidance on the right to erasure sets out when it bites: when the organisation no longer needs the data for the purpose it was collected for, when you withdraw consent you'd given, when you object and your interests outweigh theirs, and always for direct marketing. They must respond without undue delay and at the latest within one month, telling you whether they've erased it or refused. They can take up to two extra months for complex cases, but they have to tell you inside the first month and explain why.

So far so good. Now the caveats, and there are several:

• It only works if the law reaches them. A one-person tool hosted somewhere with no data protection regime and no contact address is not going to process your request.
• You need to know who to ask. Plenty of free tools publish no operator name, no company, and no privacy contact. That absence is itself a signal about how the rest is run.
• Backups are the awkward part. Deleting from a live database is straightforward. Purging a file from rolling backups, logs, and any copy a third-party processor took is harder, and honest operators say so.
• You can't verify compliance. If they reply saying it's deleted, you're taking their word for it. There's no receipt you can independently check.

The same logic applies to the reassuring line you see everywhere: "files are automatically deleted after one hour." It might well be true. You have no way to confirm it, and it tells you nothing about what was logged, what a third-party script saw, or what got copied before the timer ran out.

Which brings this back to the theme running through the whole article. Erasure is a remedy, and remedies are worth having. But the only fully reliable control is the one you exercise before you upload, which is choosing a tool that never receives the data in the first place.

Why Does Data Minimisation Matter So Much?

Because data that was never collected can't be breached, subpoenaed, sold, or leaked by a future owner of the company. It's the only protection that doesn't depend on anyone keeping a promise.

This is a formal principle, not just a preference. The W3C Privacy Principles, adopted as a W3C Statement on 15 May 2025 after three years of development, put it directly: sites and other actors "should restrict the data they transfer to what's either necessary to achieve their users' goals or aligns with their users' wishes and interests." The document also notes that the principle "applies to all personal data, even if it is not known to be identifying, sensitive, or otherwise harmful."

Regulators say the same thing with more teeth. The UK's Information Commissioner's Office treats data minimisation as principle (c) of the UK GDPR, requiring personal data to be adequate, relevant and limited to what's necessary. Its guidance is blunt about the consequence: holding more data than you actually need "is likely to be unlawful", and organisations "must not collect or retain personal data on the off-chance that it might be useful in the future."

For a tool operator, the cleanest way to satisfy all of that is not to receive the data in the first place. Which is exactly what client-side processing does. If you want the fuller model for managing privacy risk, the NIST Privacy Framework is the standard reference. Version 1.0 is still the finalised release, and NIST has published version 1.1 as an initial public draft, so if you see 1.1 quoted as current, it isn't yet.

Do AI Chatbots Count as Online Tools?

They do, and they're now the most common way data leaves an organisation without anyone noticing. Worse, the client-side test from earlier is useless here. There's no version of an AI chatbot that runs entirely in your browser, because the model is far too large to sit there. Every prompt you type goes to somebody else's server. That's not a design flaw you can shop around, it's the whole architecture.

The NCSC has published the clearest official statement on this. Its guidance on the risks of large language models puts the first point bluntly: the query will be visible to the organisation providing the LLM, so in the case of ChatGPT, to OpenAI. No ambiguity there.

The second point corrects a panic that's become common, and it corrects it in both directions. NCSC notes that an LLM does not, as of writing, automatically add information from your queries to its model for other people to query. So the fear that you paste a client's name and someone else's chatbot starts saying it next week is not how these systems work. But they follow that immediately with the part people skip: those queries are stored, and will almost certainly be used for developing the service or the model at some point.

Read those together and you get a realistic picture. Not instant exposure. Retention, and eventual use, by a company whose future ownership, breach history and policy changes you cannot predict.

Which is why NCSC's actual advice is a test rather than a rule. They advise not to include sensitive information in queries to public LLMs, and not to submit queries that would lead to issues were they made public. That second one is the useful one to carry around. Before you paste, ask whether you'd be comfortable if this exact text appeared publicly with your name on it. If the answer is no, don't paste it, regardless of what the privacy policy currently promises.

Three practical things follow from that:

• Check whether you're on a tier that trains on your data. Business and enterprise tiers are commonly excluded from model training by default while free consumer tiers often are not. This is the single setting most worth finding, and it usually lives in data controls rather than privacy.
• Treat unapproved AI tools as shadow IT. Everything in the shadow IT section below applies unchanged. An AI tool your employer has not assessed is the same category of problem as any other unvetted service, just with a much lower barrier to using it.
• Redact before you paste, not after. Swap real names, account numbers and client identifiers for placeholders. You almost always get the same quality of answer, and the data minimisation principle covered above applies exactly as it does anywhere else.

And be honest about the pressure here. AI tools are useful enough that people will use them whether or not there's a policy, which is precisely why a blanket ban tends to push the behaviour somewhere less visible rather than stopping it.

What Should You Never Paste Into an Online Tool?

Some things don't belong in a browser text box regardless of how the tool works, because the exposure isn't only about transmission.

• Live passwords and API keys. Even locally, the value now sits in your clipboard, possibly your browser history, and maybe an autofill cache. If you already did it, rotate the key rather than hoping.
• Personal data belonging to other people. Customer lists, patient records, employee details. That's not yours to risk, and in most jurisdictions there are rules about where it can go.
• Unreleased or confidential material. Contract drafts, proprietary source code, anything under NDA.
• Identity documents. Passport scans, national ID numbers, bank statements.

For credentials specifically, generate them properly rather than testing them in random utilities. Our password security guide covers how to do that, and the hash generator guide explains what hashing does and doesn't protect.

What If You Already Pasted Something Sensitive?

Most people reading a guide like this have already done the thing it warns about. That's fine. The useful question isn't whether you should have, it's what actually reduces the damage now, and the answer depends entirely on what kind of secret it was.

Sort it by whether the thing can be changed:

Credentials, keys and tokens: rotate immediately. This is the clear-cut case and the one where speed genuinely matters. The UK National Cyber Security Centre lists rotating exposed or potentially exposed credentials as an immediate action when compromise is suspected, and notes that a stolen API key can be exploited indefinitely unless it's manually revoked or rotated. It doesn't expire on its own. Rotate the key, revoke the old one rather than just issuing a new one alongside it, and turn on multi-factor authentication where the account supports it.

Passwords: change them, and anywhere you reused them. The reuse part is what catches people. One password pasted into one tool becomes a problem across every account sharing it.

Things you can't rotate: shift to damage limitation. A client contract, medical details, someone's home address, an unreleased document. You can't reissue those, so the moves are different. Send an erasure request if there's an operator to send it to. If the data belonged to someone else, particularly a client or an employer, tell them rather than hoping, because organisations usually have reporting duties with clocks attached and you starting that clock late makes it worse.

A few things worth doing in every case:

• Write down what went where and when. The tool, the URL, the rough time, and what was in it. If this later becomes a formal incident, that note is the thing nobody has.
• Check the account the tool touched for sessions or devices you don't recognise, and sign out of everything if the option exists.
• Don't just delete your browser history and call it handled. That clears your side. It does nothing to whatever the server kept.
• Resist the urge to go quiet about it. Nearly every case that turns serious does so because someone waited.

And keep it proportionate. Pasting a paragraph of marketing copy into a word counter is not an incident. Pasting a production database connection string into one is. The response should match which of those you actually did.

What Changes If You're Doing This at Work?

The stakes, mostly. And who has to report it.

Reaching for a free online tool at work has a name in security circles. The UK's National Cyber Security Centre calls it shadow IT, or grey IT, defined as those unknown IT assets used within an organisation for business purposes. Its read on why people do it is refreshingly free of blame: shadow IT is rarely the result of malicious intent, and it's normally due to staff struggling to use sanctioned tools or processes to complete a specific task. Which describes very nearly every case. You needed to reformat some JSON, the approved software doesn't do it, and there's a free tool one search away.

The problem NCSC identifies isn't the individual choice. It's the aggregate blindness that follows. If shadow IT is prevalent, the guidance says, risk management becomes very difficult because your organisation won't have a full understanding of what it wants to protect. Nobody can defend data they don't know has left.

Here's the part that genuinely changes the maths. If what you pasted contained personal data about identifiable people, so customers, patients, colleagues, job applicants, and it went to a server, that may be a personal data breach in the legal sense rather than just a mistake. Under UK GDPR, organisations have a duty to report certain personal data breaches to the ICO within 72 hours of becoming aware of them, where feasible. The ICO's guide to personal data breaches sets out how that works. The clock starts when the organisation finds out, not when it happened. So the day you tell someone is the day it starts, and staying quiet doesn't pause it. It just spends the budget before anyone can use it.

Read that against the section above on what to do after you've already pasted something. For personal use, telling someone is optional. At work it usually isn't, and the timeline is short.

So the practical version:

• Find out what's sanctioned before you need it. Most organisations have an approved list somewhere. During an incident is the wrong moment to go looking for it.
• Client-side tools are far easier to justify. If the data never left the device, there was no transfer to a third party and no processor relationship to document. That's a very different conversation from "I uploaded it to a site I found."
• Report it the same day. The 72 hours belongs to your employer, not to you, and they can't spend time you've already used.
• Don't bury it. NCSC is explicit about the dynamic here: if you blame or punish staff, their peers will be reluctant to tell you about their own unsanctioned practices, and you'll have even less visibility of the potential risks. That cuts both ways. If you manage people, how you react the first time decides whether you hear about the second.

None of this means avoiding free tools at work. It means the thirty-second Network tab check pays a lot better there than it does at home. At home a bad answer costs you something. At work it can cost your employer a notification, a regulator, and a permanent line in a breach register.

How Do You Vet a Tool Before Trusting It?

Six checks, and the first three take under a minute:

1. Is it HTTPS? A padlock in the address bar. Without it, everything is readable in transit. This is table stakes in 2026.
2. Does the Network tab stay quiet? The single most reliable signal there is.
3. Does it still work offline? Instant confirmation of local processing.
4. Is there a real privacy policy? Not a stub. It should say specifically whether your input is stored and for how long.
5. Does it demand a signup it doesn't need? A case converter asking for your email is collecting something other than what it needs to do the job.
6. Can you tell who runs it? A named operator with a contact route is accountable. An anonymous page with twelve ad units is not.
7. What's watching from your own browser? The one check that isn't about the tool. If an extension can read every page you open, the tool's privacy properties stop being the whole story.

Every check above points at the tool. There's one thing worth doing that points the other way, from you outward. Global Privacy Control is a signal your browser sends with every request, a header that reads Sec-GPC: 1, telling each site you don't want your personal data sold or shared for cross-context advertising. Brave and DuckDuckGo send it by default. Firefox has a setting for it. Several extensions add it to Chrome.

And it isn't just a polite request in some places. California's Attorney General has said sending a GPC signal is a legally binding exercise of opt-out rights under state law. Colorado's universal opt-out registry, published in February 2024, named GPC the only signal it recognises as legally binding. Connecticut and New Jersey have published guidance saying much the same, and around ten more states with broad consumer privacy laws provide for global signals of this kind. In 2025 the California Privacy Protection Agency ran an investigative sweep with the California, Colorado and Connecticut attorneys general looking specifically at businesses ignoring it.

Be clear about what it doesn't do, though. It's still a draft specification at W3C rather than a finished standard, it covers selling and sharing rather than every kind of processing, and it does nothing whatsoever about a tool that uploads your text to a server in the first place. It costs you one toggle and it puts a legal obligation on some of the companies receiving it. Switch it on, then carry on doing the checks above anyway.

None of this requires technical skill beyond pressing F12. And it's worth doing once for the tools you use regularly, rather than every single time.

What Mistakes Should You Avoid?

Five patterns cause most of the trouble:

• Assuming paid means private. Plenty of paid services upload everything. Plenty of free ones upload nothing. Price and architecture are unrelated.
• Trusting a "we don't store your data" badge on its own. It's a claim. Verify it in the Network tab, which takes less time than reading the badge.
• Using the first search result. Utility searches attract low-quality clones with heavy ad loads and vague policies. Pick a tool once, deliberately, and bookmark it.
• Forgetting the browser remembers. Local processing protects against the operator, not against whoever else uses your machine, and not against an extension reading the page. Clear the field when you're done with something sensitive.
• Treating all data as equally sensitive. Lorem ipsum needs no protection. A client contract does. Spending your caution where it matters is the whole skill.

The underlying habit is simple. Before you paste, ask what would actually happen if this specific text ended up in a database somewhere. Usually the answer is nothing at all. Occasionally it's serious, and that's the moment to check. If you want a starting set of tools that already pass these tests, our online developer tools guide runs through them.

What Else Do People Ask?

Are free online tools safe to use?

Many are, but safety depends entirely on where your data goes. A tool that processes everything in your browser never sees your data at all. A tool that uploads to a server has your data on someone else's machine, subject to their retention policy and their security. The word free tells you nothing either way. Check how it handles data, not what it costs.

Do online tools upload your files to a server?

Some do and some don't. Browser-based tools use JavaScript APIs like the W3C File API to read files into memory on your own device, so nothing is transmitted. Server-based tools send the file away to be processed and returned. Both look identical from the outside, which is why you have to check rather than assume.

How can you tell if a tool processes data in your browser?

Open your browser's developer tools, go to the Network tab, and use the tool. If your data is being uploaded you'll see a POST request carrying it. If nothing appears beyond the page assets, the work happened locally. You can also disconnect from the internet after the page loads. A truly client-side tool keeps working.

Is it safe to paste passwords or API keys into an online tool?

No, not as a habit. Even a genuinely client-side tool leaves the value in your clipboard, your browser history, and possibly a form autofill cache. For live credentials the answer is simply don't. Rotate the key instead of testing it, or use an offline tool. Treat any secret you paste anywhere as potentially compromised.

Does free mean they're selling your data?

Not necessarily. Plenty of free tools are funded by advertising, which pays for the page rather than the data you type into it. But free with a mandatory signup is a different proposition, because now they have an identity to attach behaviour to. The question worth asking is what the business model is, and whether it needs your content to work.

Sources: W3C Privacy Principles, W3C Statement published 15 May 2025 (w3.org); W3C File API Working Draft (w3.org); UK Information Commissioner's Office guidance on data minimisation, principle (c) of the UK GDPR, on the right to erasure, and on personal data breaches including the duty to report to the ICO within 72 hours of becoming aware (ico.org.uk); UK National Cyber Security Centre, "Spotlight on shadow IT," for the definition of shadow IT, the finding that it is rarely the result of malicious intent and normally due to staff struggling to use sanctioned tools, and the warning that punishing staff reduces visibility of unsanctioned practices (ncsc.gov.uk); US Federal Trade Commission Consumer Sentinel data on 2025 reported fraud losses, including "FTC Data Show People Reported Losing $3.5 Billion to Imposter Scams in 2025," June 2026, and "New FTC Data Show People Have Lost Billions to Social Media Scams," April 2026, and the FTC's prepared statement to the Joint Economic Committee, "The Rising Scam Economy," 25 March 2026, for the 15.9 billion dollar 2025 total, report counts and the rise since 2020 (ftc.gov); NIST Privacy Framework, version 1.0 final with version 1.1 at initial public draft as of August 2026 (nist.gov); W3C Subresource Integrity, Working Draft 20 March 2026, on CDN compromise and resource verification (w3.org); Sansec research, "Polyfill supply chain attack hits 100K+ sites," published 25 June 2024, on the compromised cdn.polyfill.io payload and its evasion behaviour (sansec.io); Chrome for Developers documentation on content scripts, on their ability to read page details via the DOM and pass information to the parent extension (developer.chrome.com); Sekoia Threat Detection Research, "Targeted supply chain attack against Chrome browser extensions," published 22 January 2025, on the OAuth phishing campaign, the December 2024 Cyberhaven compromise, and the credentials targeted (sekoia.com); MDN Web Docs, Content-Security-Policy: connect-src, on which script interfaces the directive restricts (fetch, XMLHttpRequest, WebSocket, EventSource, sendBeacon and the link ping attribute), that violating requests are blocked, and that navigation, form submissions and image, script and stylesheet loading fall under other directives instead (developer.mozilla.org). All linked above.