What Online Tools Do With Your Data: We Measured 28
August 28, 2026 · 9 min read
You paste a JWT into an online decoder to check why a session expired. The token authenticates a real user. Does it leave your laptop?
You cannot tell by looking. A client-side tool and a server-side one present exactly the same thing: a box, a button, a result. The privacy policy is not evidence either — it describes intentions, not architecture, and most of these pages do not have one. So on 28 August 2026 we measured it: 28 popular online tools, driven in a real browser, with a unique marker in the payload and a recording of every request that left the page. Two of them turned out to upload what you type — and three of the six that take a file uploaded that.
How the measurement works
Each tool gets a realistic payload — parseable JSON for a formatter, a well-formed token for a JWT decoder, a real query for a SQL formatter, and for the file tools a genuine 128×128 PNG or a valid PDF — with a unique marker string buried inside it, in the image's case as a tEXt metadata chunk so it survives in the raw bytes. Then the tool is driven the way a person drives it: type into the box, click its own button. Every request the page makes is recorded: URL, body, headers, and WebSocket frames. Afterwards, every one of those is searched for the marker.
The check that would have been wrong
The obvious version of this test is to search the request bodies for the text you typed. It misses most real uploads, because tools encode input before sending it. If your text is Base64'd inside a JSON envelope, a plain-text search finds nothing while the upload is sitting right there in the panel.
So the marker is searched for in every form it could take in transit — verbatim, lower-cased, URL-encoded, hex, \u-escaped, and Base64 at all three byte alignments — which comes to seven distinct needles per request for a marker made of letters and digits. That last item matters more than it sounds. A string's Base64 encoding depends on which byte it starts at, so base64(marker) may appear nowhere in a body that unquestionably contains the marker. Checked by construction: with the marker embedded at nine successive offsets inside a larger blob and encoded both ways, the full search found 18 of 18. The naive text search found 0 of 18. That is not a hypothetical: TinyPNG's and iLoveIMG's uploads were both caught this way and by nothing else — the image arrives Base64'd, and the marker only appears at one particular byte alignment.
Separating page noise from tool traffic
Every site fires requests on load — analytics, ad slots, CDN bot checks. Counting those as "it uploaded your data" would be false. So every site is measured twice: once driven normally, and once with identical timing and nothing typed at all. That second pass is the background rate, and only the difference between them can be attributed to what you typed.
The same rule kills a subtler error. If a tool never actually runs, no request can contain your input, and "nothing was uploaded" becomes trivially true of a page that did nothing. Two tools in this sample were left inconclusive for exactly that reason rather than being scored as private.
What we found: the tools you paste into
Fifteen of the 22 paste-based tools produced a conclusive result.
| Tool | Category | Input left the browser? | Says it's private? |
|---|---|---|---|
| jwt.ms | JWT decoder | No | Yes |
| SQLFormat.org | SQL formatter | No | Yes |
| Online YAML Tools | YAML converter | No | Yes |
| JSONLint | JSON validator | No | — |
| jsonformatter.org | JSON formatter | No | — |
| Code Beautify JSON Viewer | JSON formatter | No | — |
| jwt.io | JWT decoder | No | — |
| URLEncoder.io | URL encoder | No | — |
| RegExr | Regex tester | No | — |
| Cryptii | Encoder / cipher | No | — |
| SHA256 (xorbin) | Hash generator | No | — |
| Code Beautify SQL Formatter | SQL formatter | Yes | — |
| MD5 Hash Generator | Hash generator | Yes | — |
| ZeroServer.tools (control) | JSON formatter | No | Yes |
| ZeroServer.tools (control) | JWT decoder | No | Yes |
Seven more could not be scored: three sat behind a bot challenge or a consent wall we would not click through, two exposed no usable input, and two never visibly ran.
What we found: the tools you give a file to
Then we did it again with six tools that take a file rather than a paste — image compressors and PDF utilities — feeding them a real PNG with the marker in its metadata, and a real PDF with the marker as page text.
| Tool | Category | File left the browser? | Says it's private? |
|---|---|---|---|
| Squoosh | Image compressor | No | Yes |
| CompressPNG | Image compressor | No | Yes |
| TinyPNG | Image compressor | Yes | — |
| iLoveIMG Compress | Image compressor | Yes | — |
| iLovePDF Compress | PDF tool | Yes | — |
| Stirling PDF | PDF tool | blocked by a consent wall | — |
That is the single most useful number in this study. Paste-based tools uploaded 2 times out of 15. File-based tools uploaded 3 times out of 5. The moment a tool asks for a file instead of a paste, the odds roughly flip — so if you are about to hand a PDF to a website, assume it is going to a server unless the page tells you otherwise.
The uploads were not subtle once you look: tinypng.com/backend/opt/store took a 62,688-byte body, api4.iloveimg.com/v1/upload took 64,320 bytes, and api11.ilovepdf.com/v1/upload took the PDF. All three are the file itself.
And two of the six do the hard thing instead. Squoosh states that images never leave your device because it works locally, and CompressPNG says its processing happens in your browser with WebAssembly and that there are no uploads and no servers. Both claims are true — measured, not taken on trust. Compressing an image in the browser is genuinely harder to build than posting it to a server, and these two did it.
The result that surprised us most
Every privacy claim in the sample was true. Seven entries across both rounds said something about keeping your data local — five of them other people's tools, plus our own two control pages — and all seven kept it local. Zero contradicted. Nobody was caught lying. That deserves stating plainly, because it is the opposite of what a piece like this is expected to conclude.
The gap is not dishonesty — it is silence. Ten of the fifteen paste tools say nothing at all about where your input goes, and every single tool that uploaded, in both rounds, is in that group. Nothing on those pages is false. Nothing on those pages tells you either.
One phrase to stop trusting
TinyPNG's page says its compressor works "instantly in your browser". It also POSTs your image to its backend — both of those are measured facts.
There is no contradiction there, and it is not a gotcha: TinyPNG has always been a server-side service, and in context that phrase plainly means "no software to install". But it is the clearest example in the whole study of something worth internalising — "in your browser" is not a privacy claim. It is one of the most natural phrases in the world to misread as one. The claims that actually mean something name the mechanism or the absence of a destination, the way Squoosh and CompressPNG do.
Same site, two tools, two answers
The sharpest illustration is a single domain. Code Beautify's JSON viewer never sends your JSON anywhere. Its SQL formatter, four clicks away under the same brand and the same layout, POSTs your query to codebeautify.org/Ql/formateQL — the SQL arrives URL-encoded in the request body, api_key value and all.
Neither page announces which kind it is. A developer who checks the JSON tool once and concludes "this site is client-side" would carry a wrong assumption to the tool next door.
The other paste-based upload is MD5 Hash Generator, which POSTs the string verbatim as a form field. That one is worth naming because of what people hash: a hash tool's input is very often a password someone is testing.
We measured ourselves first, and found something
This site's own pages said the Network panel "stays empty" while you use a tool. That was not true, and the same harness caught it. Typing into a tool here — with no mouse click anywhere on the page — fires four POSTs to cloudflareinsights.com, our CDN's page-performance analytics.
Their payload is the page URL, the referrer and load timings; the canary check confirms they carry none of your input, so the substance of the claim held. But "the panel stays empty" was still wrong, and six places on this site have been corrected to say what the requests actually carry. A study whose author never turns the instrument on themselves is not evidence of anything.
Check any tool yourself, in about a minute
- Open DevTools, go to the Network panel, and clear it.
- Type a distinctive nonsense word into the tool —
ZZQQNONSENSE— and use it normally. - Ignore what fires on page load. Watch what fires while you type and when you press the button.
- Open those requests and search the payloads for your word. Then Base64-encode it and search again — that is the step that catches the uploads a plain search misses, and the one that caught two of the three image uploads here.
For a file tool the shortcut is even simpler: watch the size of the outgoing requests. A request whose body is roughly a third larger than your file is your file, Base64'd.
If your word is in a request body, the tool is server-side. That is the whole test.
What this does not mean
Server-side processing is a legitimate way to build a tool, and for some jobs it is the only way. A "yes" in that table is not an accusation of wrongdoing, and it says nothing about what any operator does with the data afterwards. What it measures is narrower and more checkable: on this date, with this input, these bytes left the browser.
These sites also change. Every number here is a measurement of one day, which is exactly why the method matters more than the table — run it yourself on the tool you were about to use.
Try these free tools
Free & private — all tools run in your browser, nothing uploaded.