ZIP to PDF — turning an image bundle into a single document, one page per image
A photo-album or screenshot ZIP is awkward to share: forty files to open one at a time. This route reads the archive in the browser tab, decodes the supported image entries and re-renders them into a PDF, one page per image. It is an album builder rather than a file converter — text members are skipped, and image properties that a PDF page cannot carry are dropped.
ZIP metadata outside the entry table (comments, extra fields, timestamps with sub-second precision) is not rewritten.
Processed on your device. Files aren’t sent anywhere.
Which entries become pages
The first 24 supported image entries, in archive order, become PDF pages. Other files are omitted from the PDF, but the reader still validates their archive records and sizes. A broken or oversized non-image member can therefore reject the operation too.
| Entry in the ZIP | Album response |
|---|---|
| PNG, JPG, JPEG, WebP, GIF, BMP | decoded and placed on its own page |
| Text, JSON, source or other non-image files | skipped; no conversion and no OCR |
| Animated GIF | first frame only |
| Directory entries | skipped |
| Archive with no supported images | rejected instead of producing an empty PDF |
What re-rendering discards
Images are decoded by the browser and re-rendered into fresh PNG data. Animation is not preserved; a GIF supplies a still frame. The original ICC profile metadata is not copied, although the browser may apply colour conversion while decoding.
There are no caption or timestamp controls and no entry-order setting for this output: pages follow archive order, and the page carries the image and nothing else.
Size limits and the 24-image window
Decoding images costs memory, so the route bounds both the archive and each image.
- Up to 24 supported images are placed; later image entries are not added.
- Each image is capped at 4 megapixels; larger ones are scaled down rather than rejected.
- Input is capped at 12 MiB, with at most 200 entries and 8 MiB per member.
- The archive may expand to at most 32 MiB of payload; a ratio above 60x between expanded and compressed size aborts the run before any page is drawn.
- Unsafe paths, duplicate or invalid names, ZIP64/split storage, encryption, symlinks and Unix special-file types reject the read. The album also validates non-image members before omitting them from the PDF.
Running the album
The bundle is read entry by entry inside the tab; nothing is uploaded and no server extracts anything.
One document to print or forward, instead of a folder of files to open one by one.
The point of an album output
Checking the result
- Drop the .zip into the archive studio and choose PDF as the target.
- Confirm the page count matches the number of supported images you expected, not the entry count.
- Look for images that were scaled down — very large photos render smaller than their source.
- Check an animated GIF: only the first frame appears.
- If conversion rejects, read the file-list reason. No supported images is one possibility; a damaged image, invalid archive, unsupported member or size limit can also prevent the album.
- For the rest of the bundle's contents, use the JSON inventory or the text listing routes.