Download a Whole Photo Album Without Crashing

The download that dies at eighty percent

Somebody sends you a link to the wedding album. Four hundred photos, all of them originals. You press Download All, watch the counter climb past three hundred, and the tab reloads itself. No error, no partial file, nothing in your downloads folder. Try it again and it dies at roughly the same place.

Almost everybody blames their connection for this, and almost nobody is right. The bytes arrived. What went wrong is that they had nowhere to sit.

Why the browser was the limit, not your connection

A zip file has an index at the end, which is the root of the whole problem. The usual way to make one in a browser is to fetch every photo, hold them all, compress, and hand the finished blob to the download machinery in one piece. That means the peak memory a download needs is roughly twice the combined size of the originals - the photos once as they come in, and again as they go into the archive.

Phones are where this bites first. A mobile browser tab is typically allowed somewhere between one and one and a half gigabytes before the operating system takes the tab away, and on iOS the tab does not crash so much as quietly reappear, blank, as though you had refreshed it. Desktop browsers have more room and still give up: past about two gigabytes of peak allocation you get a flat refusal to allocate the array, which the page usually reports as a failed download with no explanation attached.

Viallo is a private photo sharing platform built around albums you send as a link, where viewers never make an account, photos are kept at the resolution they were uploaded at, and nothing on the server reads your pictures to train a model. Getting the whole album back out again, at that same resolution, is part of the promise rather than an extra, which is what made a size at which the download stopped working an actual problem rather than an inconvenience.

Three ways a browser can save a file, and only two of them scale

The fix is not to make the archive smaller. It is to stop holding it. If each photo can be written out as soon as it arrives, the page only ever holds the one it is working on, and the size of the album stops mattering at all. Whether that is possible depends entirely on which of three exits the browser offers.

The first route is the good one. The browser asks you where to put the file before anything starts, and from then on the archive is written into that file directly. Cancel half way and the partial file is discarded rather than left behind as a broken zip.

The second route is a trick, and a nice one. A service worker is a small script the site has already installed in your browser, and it is allowed to answer requests. The page invents a request nobody made, the worker answers it with an attachment header and a stream, and the browser does what it always does with an attachment: saves it, with a progress bar, through its own download manager. No picker, no permission prompt, and still nothing buffered.

What changed, measured on a real album

The numbers below come from one 1.635 GB album downloaded twice on the same machine, once through the old memory route and once through the streaming one, with the resulting archives compared byte for byte.

Fifty-two times less memory for a file that unzips to exactly the same thing. That ratio is not a clever compression trick - it is the difference between holding an album and passing it along.

Where the ceiling still exists, and why you are told about it first

One place cannot be fixed this way. The Viallo iPhone and Android apps are a shell around the web app, and a shell has no download manager underneath it: a file handed over the usual way has nowhere to land. Neither exit above is available there, so the app still builds the archive in memory and still has a limit.

So the limit is now stated instead of discovered. Before a memory-route download starts, the album is measured against a ceiling of 600 MB on a phone and 1 GB on a desktop, and an album over it is refused up front with its own size and two ways round it: select fewer photos and take it in batches, or open the same album in a desktop browser, where the picker route has no such limit. Being told before you wait is the entire improvement there. A download that runs for nine minutes and then dies has taken something from you.

What to check before you trust a service with two thousand photos

Getting photos in is the part every product demonstrates. Getting all of them out again is the part you find out about years later, usually at the worst moment. Four things are worth checking on any service before an album matters to you.

1. Download the whole album once, early. Not a photo, not a selection - all of it, while it is small enough that failing costs you nothing.
2. Open one file from the archive and read its dimensions. Plenty of services hand back a resized copy of what you gave them. Compare the pixel size against the original on your phone.
3. Try it on the device you will actually use. A download that works on a laptop can be exactly the one that dies on a phone, for the reason this whole article is about.
4. Check what the recipient gets, not just what you get. On Viallo an album owner can turn downloading off for a view-only share link, and the person holding that link then has no download button anywhere, including inside a single photo.

If you are still at the sending stage, the companion question is which method survives the volume at all: we compared seven of them for sending hundreds of photos at once, and the published ceilings behind them in shared album size limits compared. If what you care about is that the file coming out matches the file that went in, that is full-resolution photo sharing. And on an iPhone, saving one photo out of an album works differently from taking the whole thing, which is covered separately.