DEV Community: Constantin Alex

I deleted my Rust helper and moved zip extraction into the browser. Here's what it cost.

Constantin Alex — Mon, 19 Oct 2026 18:57:20 +0000

A couple of weeks ago I wrote about LinkUnzip, a Chrome extension that pulls files out of a zip on the internet without downloading the zip. It reads the zip's table of contents with an HTTP Range request, then downloads only the bytes of the files you want and writes them straight into a folder.

The idea worked. The install didn't.

To write files into a real folder, version 1.0 needed a small helper program on your PC. I wrote it in Rust and the extension talked to it through Chrome's native messaging. It was fast. It was also a Windows .exe from someone nobody has heard of, unsigned, so Windows SmartScreen warned about it. A few people told me straight up that the helper was a dealbreaker. And of the first five people who uninstalled the extension, four were on Linux or ChromeOS, where the helper didn't exist at all. They installed it, found out it couldn't work, and left.

So for 1.1.0 I moved the whole engine into the browser. Here's how that went, including the parts where the browser is slower.

What the browser already has

It turns out almost everything the Rust helper did has a browser API now:

fetch with a Range header gets any slice of the zip.
DecompressionStream("deflate-raw") inflates zip data natively. Zip uses raw deflate, without the zlib header, and Chrome supports exactly that.
CRC-32 is about 40 lines of JavaScript with a lookup table.
The File System Access API (showDirectoryPicker, createWritable) writes into a real folder the user picked.
An offscreen document gives the engine a page that keeps running after the popup closes.

The core is pretty small. Simplified, one file looks like this:

// fetch one file's compressed bytes and inflate them as they arrive
const res = await fetch(zipUrl, { headers: { Range: `bytes=${start}-${end}` } });
if (res.status !== 206) throw new Error("the server ignored the Range header");

const plain = res.body.pipeThrough(new DecompressionStream("deflate-raw"));
await plain.pipeTo(await fileHandle.createWritable());

The real code does more: it groups neighbouring files into one request, skips each file's local header, counts CRC-32 and size on the way through, and only gives the file its real name once both match. But that's the heart of it, and it's all stuff the browser ships.

Where the browser is slower

I measured both versions on the same machine.

The Blender 4.2 zip is 365.8 MB with 5,518 files. The Rust helper extracted all of it in 15 to 17 seconds. The browser version takes 52 seconds.

The download isn't the problem. The folder is. Chrome runs file system operations one at a time, and each file needs about four of them: get a handle, create a writable, write, close. At roughly 2 ms each, that's about 7 ms per file no matter how many connections are downloading in parallel. For a zip of big files you don't notice. For a zip of thousands of tiny files you do. In a benchmark with 70,000 tiny files, Chrome took 500 seconds where plain Node took 101.

I decided that's fine as long as the extension says so. The helper still exists as an optional extra for people who want the speed.

Chrome has opinions about where you save

My first test build asked you to pick a folder. Then I tried to pick Downloads and Chrome said no. The folder picker refuses Downloads, Desktop and Documents themselves. You can pick a folder inside them, but not the folder itself. For most people "put it in Downloads" is the whole point, so that was a problem.

The fix was to use Chrome's own downloads for the default case. Each checked file becomes a Blob and goes through chrome.downloads.download into Downloads/<zip name>/. No picker, no permission prompt. Three things I learned the hard way:

If the Blob has no type, Chrome renames every file to .txt. application/octet-stream fixes it.
Chrome holds back some file types (.dll, .ini, .cfg, .manifest and a few more) until you click Keep on each one. The extension now counts them before it starts and warns you.
It's slow: about 150 ms per file, so 6 or 7 files a second. For a zip with thousands of files the popup now tells you how long it will take and suggests picking a folder instead, which is the fast path (that 7 ms per file).

The bug that only showed up for real users

The first build worked in all my tests. Then I tried it as a normal user and got "the engine didn't start".

Chrome stops an extension's background service worker when it's idle. My offscreen page, the one doing the actual work, outlived the worker and was left holding a dead connection. When the worker woke up again, it saw that the page already existed and waited for it to say hello. It never did.

Now a busy page reconnects by itself, an idle leftover page gets a second and a half and is then replaced, and running extractions survive a worker restart. The test suite stops the worker on purpose, both while idle and in the middle of an extraction, so this can't quietly come back.

A bonus: preview

Once the engine could pull one file out of a zip, showing that file was a small step. Every file in the list now has an eye icon that opens it in a tab: text and code, CSV as a table, images, PDF, audio and video. Only that one file is downloaded.

One photo out of the COCO train2017 dataset, an 18.01 GB zip, downloads 219 KB for the preview. For CSV it stops even earlier: the first 1,000 rows of movies.csv from the MovieLens 32M dataset cost 23.3 KB out of a 227.9 MB zip. Checking whether a dataset is the one you want before downloading 18 GB of it is honestly the feature I use most now.

What still doesn't work

Servers that ignore Range requests and send the whole file every time. GitHub's green "Download ZIP" button is one of them. For those you still need the helper, which streams the file once from start to end.
RAR, 7z and password-protected zips.
I've only tested it on Windows so far. It should work in Chrome on Mac, Linux and ChromeOS, since nothing in it is Windows-specific any more, but I haven't seen it with my own eyes yet.

Try it

It's free and open source, no account, nothing to install besides the extension:

Chrome Web Store: https://chromewebstore.google.com/detail/dapeiljhjlaelolngnoagobeojcpkica?utm_source=devto&utm_medium=article
Code: https://github.com/CincaAlex/LinkUnzip

If you're on Mac or Linux I'd really like to know if it works for you. And if you've hit the same Chrome limits with the File System Access API, how did you get around the one-operation-at-a-time thing? I couldn't find a way.

I didn't have room for a zip and its files, so I learned how to skip the zip

Constantin Alex — Fri, 09 Oct 2026 12:59:33 +0000

A while ago I had to unpack a 60 GB zip. The files would have fit on my laptop. The zip plus the files didn't.

That's the annoying part of "download it, extract it, delete the zip". For a moment you need room for both. Usually that's fine. That day it wasn't, and I got stuck on a question: do I actually need the zip on my disk at all?

Turns out, not really.

The trick

A zip file keeps its table of contents at the very end. It's called the central directory, and it lists every file in the archive, how big it is and where exactly it starts inside the zip.

The second piece is something most servers already support: HTTP Range requests. You can ask a server for just a slice of a file, like "give me bytes 1000 to 2000". It's the same thing that lets you skip ahead in a video or resume a download.

Put those together and you get this:

Ask the server how big the zip is.
Download only the end of it and read the table of contents.
Now you know every file and where it lives, so download just the bytes of the files you want.
Unpack each one as it arrives and write it straight into a folder.

The zip itself never gets saved anywhere.

The numbers

This is the part that still feels a bit like cheating to me.

COCO train2017 is a popular machine learning dataset: an 18.01 GB zip with 118,287 photos. Getting one photo out of it downloaded 12.2 MB in total, and 11.9 MB of that was just the table of contents. It took between 3.7 and 6.8 seconds over four runs.

For a full archive: the Blender 4.2 zip is 365.8 MB with 5,518 files. Extracting all of it wrote 925.6 MB of files with 0 B of zip on disk, in 15 to 22 seconds on my home connection. The normal way, you'd need 1.26 GB free for the zip and the files together.

To be clear, for a whole archive it downloads about the same amount as a normal download. It's not faster magic. You save the space the zip would take, and when you only need part of an archive, you only download that part.

From a script to an extension

It started as a small command line tool in Rust, just for me. You gave it a link and a folder, and it did the rest.

Then I got tired of copying links into a terminal and wanted it on a right-click. So it became a Chrome extension. The catch: an extension can't really write a whole folder tree to your disk on its own. So there's a small Windows helper program, and the extension talks to it through Chrome's native messaging. The extension shows the list and the buttons, the helper does the downloading and writing.

Now it's: right-click a zip link, see what's inside and how much space it needs, pick the files, done.

Things that broke along the way

GitHub doesn't play along. The "Download ZIP" button on GitHub doesn't support Range requests at all, so the whole trick falls apart there. I ended up writing a second mode that reads the zip once from start to finish and unpacks files as they go by. No preview, but still no zip on disk.

Zips can be nasty. A zip can contain a file called CON or NUL.txt, which Windows simply refuses to create. Worse, it can contain paths like ../../something that try to write outside the folder you picked. All of that has to be checked before a single byte gets written.

Every file gets checked. Each file is written under a temporary name first, its checksum and size are compared with what the zip says, and only then does it get its real name. If the connection drops halfway, you don't end up with a half-written file that looks fine.

The Chrome Web Store review. An extension that talks to a native program and can ask for cookies (for downloads that need your login) gets a careful review. Explaining every permission clearly took a while, but it went public this week.

The honest limits

Windows only for now
It needs the helper installed (per user, no admin rights)
No RAR or 7z yet, and no password-protected zips
The installer isn't code-signed yet, so Windows SmartScreen shows a warning the first time

Try it or read the code

It's free and open source, no account and no tracking. It's called LinkUnzip.

Code: https://github.com/CincaAlex/LinkUnzip
Website: https://linkunzip.app

I'm curious whether other people run into this too, or if it's just me. And if you know a zip link it chokes on, I'd really like to hear about it.