Compressing one PDF is free everywhere. Compressing the forty in a folder is where free tiers stop. The usual excuse is server cost, which is true when files get uploaded, processed on someone else's hardware and downloaded again. Do the work in the browser and that cost disappears, so a 3-file cap is a business decision.
But browser-side batch processing swaps the bottleneck from server capacity to your device's memory. How I handled it:
- Bounded concurrency: 3 files at a time in Web Workers, rather than all at once (memory spike, crashed tab) or strictly sequential (slow)
- Streamed ZIP output: each result is added to the archive as it finishes instead of being held in memory until the end
- Per-file failure isolation: one corrupt or password-protected PDF is reported and skipped, not a failed run
- A pre-flight memory warning (~500 MB desktop, ~150 MB mobile) that is an honest estimate, not a paywall prompt
- Libraries (pdf-lib, pdf.js) bundled with the page, so it works offline
Operations: PDF compress/merge/watermark/page-to-image, and image convert/resize/compress/EXIF-strip. The EXIF one is the one I care about most. Phone photos carry GPS coordinates, and people share them without realizing.
🔗 https://www.forgeplug.com/tools/bulk-file-ops
If you've done heavy batch work in the browser, I'd like to hear how you handle memory pressure on mobile.
Top comments (0)