Downloading a single photo from Facebook is easy enough.
Downloading an entire album is a different story.
If an album contains dozens of photos, saving them one by one quickly becomes tedious. I wanted a simpler workflow: paste a Facebook album URL, retrieve all available photos, and download the entire album as a single ZIP file.
That idea eventually became one of the features in FromFB.
In this post, I'll explain the basic architecture behind the feature, some of the problems I had to solve, and a few things I learned while building it.
The Goal
The user experience I wanted was very simple:
Paste Facebook album URL
↓
Analyze the album
↓
Show available photos
↓
Download individual photos
↓
or
↓
Download everything as ZIP
The UI is the easy part.
Most of the work happens behind the scenes.
The application has to identify the URL, extract the available media, prepare the files, and generate an archive without making the user wait unnecessarily long.
Step 1: Detecting What the User Submitted
The first step is URL validation.
A downloader shouldn't simply accept arbitrary input and immediately start making server-side requests.
At a minimum, I need to determine whether the submitted URL is actually a supported Facebook URL and whether it points to content the application knows how to process.
Conceptually, the flow looks like this:
Submitted URL
↓
Validate URL
↓
Identify Facebook content type
↓
Album / Photo / Video / Reel / Unsupported
This is important because the processing logic for an album is very different from the logic required for a single video or image.
It also keeps the backend cleaner.
Instead of having one huge function trying to figure everything out, the application can route different content types to different handlers.
Step 2: Extracting the Album Photos
Once an album is detected, the next task is retrieving its available photos.
The result I want internally is something simple, such as:
[
{
"id": "photo_1",
"url": "https://example.com/photo1.jpg"
},
{
"id": "photo_2",
"url": "https://example.com/photo2.jpg"
},
{
"id": "photo_3",
"url": "https://example.com/photo3.jpg"
}
]
The actual extraction process is naturally more complicated than that, but separating extraction from downloading makes the rest of the system easier to maintain.
The extractor's job is basically:
Facebook album URL
↓
Retrieve album information
↓
Find available photo resources
↓
Normalize results
↓
Return a clean list to the application
The downloader doesn't need to care how those URLs were discovered.
It just needs a predictable result.
That separation became especially useful as I added support for different Facebook content types.
Step 3: Individual Downloads vs. ZIP Downloads
After extracting the photos, I wanted to offer two options.
Users can download individual images, or they can download the complete album.
Individual downloads are straightforward.
ZIP downloads introduce another layer:
Photo URLs
↓
Download photos
↓
Generate filenames
↓
Add files to ZIP
↓
Return ZIP to the browser
For example:
facebook-album/
├── photo-001.jpg
├── photo-002.jpg
├── photo-003.jpg
├── photo-004.jpg
└── photo-005.jpg
Then the application can produce something like:
facebook-album.zip
That sounds simple, but there are a few details that matter.
File Naming
Using the original filenames isn't always practical.
Media URLs can contain long or meaningless identifiers, query parameters, or filenames that aren't especially useful once downloaded.
So I prefer predictable names:
photo-001.jpg
photo-002.jpg
photo-003.jpg
...
This also preserves the order of the album.
If there are 100 photos, padding the numbers keeps sorting consistent:
photo-001.jpg
photo-002.jpg
...
photo-099.jpg
photo-100.jpg
Small detail, but it makes the resulting ZIP much nicer to use.
Temporary Storage
Another question was whether downloaded photos should remain on the server.
For this type of service, I don't want files sitting around permanently.
A better workflow is:
Create temporary job
↓
Download required images
↓
Create ZIP archive
↓
Send archive to user
↓
Remove temporary files
Temporary files still require proper cleanup.
If even a small percentage of jobs fail before cleanup happens, disk usage can slowly grow over time.
So cleanup shouldn't depend only on the successful end of a request.
It's useful to have a second cleanup mechanism that removes abandoned temporary files after a certain period.
For example:
/tmp/downloads/job-123/
/tmp/downloads/job-456/
/tmp/downloads/job-789/
A scheduled cleanup process can periodically remove old directories that are no longer in use.
Memory Usage Matters
A tempting approach is to download every photo into memory and then create the archive.
That works for small albums.
It becomes a bad idea very quickly when users process larger ones.
Imagine:
50 photos × 5 MB = 250 MB
Keeping all of that in memory for a single request is unnecessary.
With multiple simultaneous users, memory consumption can grow very quickly.
The safer approach is to stream or temporarily write files to disk and let the ZIP process work with those files.
Instead of:
Internet → RAM → ZIP
the flow becomes closer to:
Internet
↓
Temporary file
↓
ZIP archive
↓
User
It's slightly more work, but considerably more predictable.
Handling Failed Images
Another issue is partial failure.
Suppose an album contains 40 photos.
The first 35 download correctly, but one remote request fails.
Should the entire operation fail?
Usually, that's not the best user experience.
Depending on the situation, it's often better to continue processing the remaining files and return the successfully retrieved photos.
Conceptually:
for each photo:
try download
if successful:
add to archive
else:
record failure
continue
The user can still get 39 out of 40 images rather than receiving nothing.
This also makes the application more resilient to temporary network problems.
Timeouts
External media downloads are unpredictable.
A remote server may respond immediately, slowly, or not at all.
Without reasonable timeouts, one failed request could keep an entire job stuck.
So each network operation needs limits.
The exact numbers depend on the infrastructure, but the general principle is simple:
Never let one external request block a download job indefinitely.
Retries can also help, but they should be limited.
Something like this conceptually:
Request image
↓
Success? → Continue
↓ No
Retry
↓
Success? → Continue
↓ No
Skip / report failure
Infinite retries are usually worse than the original problem.
ZIP Creation
Once the images are available locally, creating the archive is comparatively simple.
In PHP, the basic idea might look like this:
$zip = new ZipArchive();
$zip->open($zipPath, ZipArchive::CREATE | ZipArchive::OVERWRITE);
foreach ($photos as $index => $photoPath) {
$filename = sprintf('photo-%03d.jpg', $index + 1);
$zip->addFile($photoPath, $filename);
}
$zip->close();
The interesting part isn't the ZIP code itself.
The challenging part is everything around it:
- downloading multiple remote files safely;
- avoiding excessive memory usage;
- handling failed downloads;
- cleaning temporary files;
- preventing duplicate work;
- keeping response times reasonable.
The archive is only the final step.
Preventing Duplicate Processing
There's another optimization that's easy to overlook.
A user may click the download button multiple times.
Two users might also request the same album around the same time.
Without protection, the server could start several identical jobs:
Album A → Job 1
Album A → Job 2
Album A → Job 3
Depending on the architecture, it can be useful to temporarily identify active jobs and reuse the result when appropriate.
For example:
hash(normalized_album_url)
can serve as part of a temporary job identifier.
This isn't always necessary for a small service, but it becomes more useful as traffic increases.
Keeping the Frontend Simple
Despite everything happening in the backend, I wanted the frontend to remain simple.
The user shouldn't have to understand any of this.
They should see something like:
Paste URL
↓
Download
↓
Photos appear
↓
Download individually
or
Download all as ZIP
A good tool hides its infrastructure.
If the user has to understand jobs, archives, media extraction, temporary storage, or retries, the abstraction has failed.
What I Learned
The biggest lesson from building this feature is that the visible part of a downloader is usually the easiest part.
The form itself may contain one input and one button.
Behind that button you may have:
URL validation
→ content detection
→ media extraction
→ network requests
→ temporary storage
→ retry handling
→ archive creation
→ streaming
→ cleanup
This is true for many small SaaS and utility projects.
A feature that looks trivial from the outside can contain a surprising number of edge cases once real users start using it.
The Result
I added the album downloading feature to FromFB, my Facebook media downloader.
The photo downloader can process supported Facebook photo content and lets users download available images individually or package album photos into a ZIP archive.
You can try it here:
https://fromfb.app/en/facebook-photo-downloader
The project also supports other types of Facebook media, but album downloads were particularly interesting to build because they involve much more than simply returning a single file.
I'm continuing to improve the service as I encounter new edge cases.
If you're building something similar, I'd be interested to hear how you handle bulk downloads, temporary storage, and ZIP generation.
