The habit is universal: search "compress PDF online", click the first result, drag the file in, download the result. For a meme or a screenshot, who cares. But the files people actually run through these tools are employment contracts, ID scans, bank statements, medical reports, and client deliverables — and dragging one into the wrong website means a stranger's server now holds a copy of it.
This isn't an accusation that upload-based tools are dishonest. Most publish retention policies and follow them. The point is subtler: the two architectures differ in what you're forced to trust. A server-side tool asks you to trust its operator's promises. A client-side tool removes the need for that trust, because the file physically never leaves your device. This post explains how each one works, where each genuinely wins, and — most usefully — how to verify for yourself which kind any tool actually is.
What actually happens when you upload a file
When a tool works server-side, dropping your file triggers an HTTP POST that transmits every byte of it to the operator's infrastructure. HTTPS protects the file in transit — nobody on the network path can read it — but that's where its protection ends. TLS says nothing about what happens at the destination. Once the upload completes, your file exists in the server's memory, usually on its disk, often in a cloud storage bucket, sometimes in a processing queue, and occasionally in logs or crash dumps the operator never intended to keep.
The standard reassurance is a retention policy: "files are deleted automatically after one hour." That may well be true. But notice what kind of statement it is — a promise, not a mechanism. You have no way to observe whether deletion happened, whether backups were included, or whether a subprocessor (the cloud vendor, a queue service, an error tracker) retained fragments. For personal use that's usually an acceptable risk. For work documents it can be a real problem: in many organizations, sending a client's file to an unvetted third-party service is itself a data-handling incident, regardless of what the service later did with it — under GDPR-style rules, that upload can make the service a data processor with obligations nobody signed off on.
There's also a mundane cost: round-trip time. Your file has to travel up your connection (usually the slow direction), wait its turn in a processing queue, then travel back down. That's why upload-based tools feel sluggish on big files and why many of them meter free usage — server CPU time costs the operator real money per file, so heavy users get pushed toward paid tiers.
How client-side processing works instead
Modern browsers quietly became capable enough to make the upload unnecessary for most everyday file operations. The File API lets JavaScript read a file you select into memory without transmitting it anywhere — it becomes an ArrayBuffer inside your tab, no different from any other variable. From there, a canvas can decode, resize, and re-encode images; the Web Crypto API computes SHA-256 hashes natively; and pure-JavaScript libraries can parse and rewrite entire PDF document structures — merging pages, rotating them, stamping watermarks — by manipulating bytes directly in memory.
The lifecycle of your file in this model is short and local: it's read into tab memory, transformed by code running on your CPU, handed back to you as a download, and gone when you close the tab. There is no server component involved in the transformation at all — which also means there's no retention policy to evaluate, because there's nothing to retain.
Two practical consequences follow. Speed: with no upload, no queue, and no download, processing time is bounded by your own hardware — a 20 MB image compresses as fast as your CPU can re-encode it, not as fast as your uplink can push it. And economics: since each file costs the operator nothing to process, client-side tools have no structural reason to impose per-file limits or paywalls the way compute-metered upload services do.
What client-side tools genuinely can't do
Honesty matters here, because "everything should be client-side" is as wrong as "uploads are fine." Some jobs really do need a server. AI-based work — cutting a person out of a busy photo, OCR on a scanned document, speech-to-text — runs on models that are hundreds of megabytes to gigabytes in size; shipping them to a browser tab is impractical, so those tools upload, and the good ones are upfront about it. High-fidelity format conversion with proprietary engines (the kind that makes PDF-to-Word almost perfect) mostly lives server-side too. So does anything involving collaboration, shared links, or files larger than a browser tab's memory budget comfortably holds.
A useful rule of thumb: if a free tool performs seemingly heavy AI magic instantly, your file went to a server — that's not cynicism, it's just where that kind of compute lives. The question worth asking is never "is this tool client-side?" in the abstract, but "does this operation need a server, and if it doesn't, why is this tool uploading?"
The 30-second test: check any tool yourself
You don't have to take any website's word for this — including ours. The browser will show you exactly what a page transmits.
1. Watch the network. Open DevTools (F12) and switch to the Network tab before you drop your file in. Then process the file and watch what appears. A client-side tool generates no request anywhere near the size of your file. An upload-based tool produces an unmistakable POST or PUT whose payload size roughly matches the file you gave it. Ignore the small stuff — analytics beacons and ad requests are a few kilobytes; your 4 MB PDF is not.
2. Pull the plug. The stronger version: load the tool's page, then disconnect — DevTools has an "Offline" throttling preset, or just switch on airplane mode. Now process your file. A genuinely client-side tool keeps working with the network gone, because it never needed the network in the first place. An upload-based tool fails immediately.
One caveat so the test doesn't mislead you: many client-side tools lazy-load their processing library (a few hundred KB of JavaScript) the first time you use them. That's a download of code to your machine, not an upload of your data — check the request's direction and size before concluding anything. Do the offline test after the page has fully loaded once and this ambiguity disappears.
There's also a browser-enforced layer worth knowing about: a site's Content-Security-Policy can restrict where its own scripts are allowed to send data. GlaeKit's CSP, for instance, permits network connections only back to the site itself and its ad provider — so even the page's own JavaScript couldn't quietly ship your file to some third-party endpoint; the browser would refuse the connection. You can inspect any site's CSP in the Network tab under the page's response headers.
Run the test on our tools
Every GlaeKit tool is built client-side — that's the design premise of the whole site. Open the PDF Compressor, the Image Compressor, or the Hash Generator with the Network tab open, or offline entirely, and watch them keep working. We'd rather you verify than trust.
Frequently asked questions
Isn't HTTPS enough to make uploads safe?
HTTPS encrypts the file while it travels, so networks between you and the server can't read it. It says nothing about what the server does after arrival — storage, backups, logs, subprocessors, or retention. Transit security and custody are different problems; HTTPS only solves the first.
A tool says files are deleted after an hour. Is that trustworthy?
It's a policy, and most operators do follow their policies — but it's unverifiable from the outside, and it doesn't cover copies in backups, queues, or logs. Client-side processing makes the question moot: nothing was received, so there's nothing to delete.
Can browser-based tools handle large files?
Comfortably into the hundreds of megabytes for documents and images, since the file just occupies tab memory. The practical ceiling is your device's RAM and the browser's per-tab limits — multi-gigabyte video work is where client-side processing genuinely starts to strain.
Does "client-side" automatically mean a tool is trustworthy?
No — the same JavaScript that processes your file locally could, in principle, also transmit it. "Client-side" is a claim like any other, which is exactly why the Network-tab and offline tests in this post matter: they let you confirm the claim instead of extending trust. A restrictive Content-Security-Policy adds a browser-enforced backstop.
Why are upload-based tools often slower and rate-limited?
Because each file consumes the operator's bandwidth and CPU, which costs real money — so free tiers get queues, size caps, and daily limits. A client-side tool spends your CPU instead, which is why it can process files instantly and without per-file limits.