Why we compress files in the browser instead of on a server

Sanjay Bharti — Mon, 27 Jul 2026 16:10:13 +0000

Almost every "compress your PDF" or "compress your image" tool works the same way under the hood: you upload the file to their server, it gets processed there, and a smaller copy comes back. It's the obvious way to build it — but for the product we were building, it was the wrong default. Here's the reasoning, without the code.

The problem with the upload-to-server model

Two issues, one small and one big.

The small one: it's a round trip. For a large file, you pay the upload cost and the download cost just to make it smaller — before you've even uploaded it to wherever it actually needs to go.

The big one is trust. The whole reason people compress a file is usually to upload it somewhere official — a visa portal, a KYC step, a government form. That means the files are exactly the ones you'd least want sitting on a random third-party server: payslips, bank statements, IDs. A server-side compressor asks the user to hand that document to another company they've never heard of, purely to shave a few hundred KB off it. That's a lot of trust to ask for a utility function.

So we asked a different question: does compression actually need a server at all?

The browser can do more than people assume

For a large class of files, the answer is no — the platform already ships the tools:

Images can be decoded, resized, and re-encoded entirely client-side. The Canvas API is the workhorse here: draw the image to a canvas at a smaller dimension, then export it with canvas.toBlob() at a chosen quality factor. No upload required.
Hitting a specific size target (say, "under 200 KB") is a loop you can run locally: encode, measure the resulting byte size, adjust quality or dimensions, repeat until it fits. All in memory, on the user's machine.
Heavier formats like PDFs are harder because their weight usually lives in embedded images — but the ecosystem has matured. Between WebAssembly builds of mature libraries and pure-JS PDF tooling, a lot that used to require a server binary now runs in a tab.

The point isn't that client-side is trivial — it's that the "you must upload it to a server" assumption is mostly a leftover habit, not a hard requirement.

What you get by keeping it local

Once the file never leaves the device, some nice properties fall out for free:

No round trip — the file is prepared in place and goes straight to its real destination.
Works offline once the code is loaded.
Nothing to breach — there's no server-side store of user documents, because there's no server-side handling of them at all. You can't leak what you never received.

For a tool people reach for with sensitive documents, "the file never leaves your device" stops being a marketing line and becomes the actual architecture.

The honest trade-offs

Client-side isn't a free lunch. You're bounded by the user's device memory for very large files, and browser codecs give you less fine-grained control than a server toolchain like Ghostscript. For general-purpose, do-anything conversion, a server still wins. But for the specific job of getting a document under an upload limit without surrendering it to a third party, doing it in the browser is the better trade — and increasingly a practical one.

We build this into a Chrome extension called Auto Compress — it compresses the file right at the upload step, on-device. If you want to see it in action it's free for trial: https://autocompress.live. Happy to get into the weeds on any of this in the comments.

DEV Community: Sanjay Bharti

Why we compress files in the browser instead of on a server