Research - 8 min read
Why PDF File Size Is Not the Same as Browser Memory
A tested explanation of QuickerConvert workload guards, decoded pixel memory, exact boundary behavior, cancellation, and why compressed megabytes do not predict browser cost.
By QuickerConvert Team (organizational author) - Published
A 5 MB image can consume far more than 5 MB after a browser decodes it. A PDF can also create page canvases, copied byte arrays, thumbnails, and output buffers while the original file is still open. On July 19, 2026, we reran QuickerConvert's workload boundary suite to check exact limits, one-unit-over failures, cancellation, and preservation of already-open files. These are engineering guard tests, not proof that every device has the same memory ceiling.
Compressed bytes and decoded pixels answer different questions
File size describes the compressed bytes stored on disk or selected by the browser. Rendering cost depends heavily on decoded dimensions. A 6,000 × 4,000 image contains 24 million pixels. One basic RGBA copy needs 96,000,000 bytes, about 91.6 MiB, before extra canvases, thumbnails, library objects, or output buffers. A well-compressed JPEG can therefore look small in a file picker while still becoming expensive in memory.
- File-size estimate: the bytes selected or downloaded.
- Decoded-image estimate: width × height × four color bytes.
- Real peak memory: decoded pixels plus temporary copies, page data, previews, and output.
We tested boundaries and one-unit-over failures
The automated suite passes synthetic files and pixel metrics into the same guard functions used by the app. It checks a normal case, the exact configured boundary, and a value just above the boundary. This catches off-by-one behavior and makes the limits reviewable. It also confirms that rejecting a new batch does not clear the documents a user already opened.
- General selection: up to 100 files and 300 MiB aggregate input at once.
- General PDF page guard: up to 750 pages, with a warning beginning at 300 pages.
- Incoming over-limit files are rejected while existing workspace files remain unchanged.
- The limits are per workspace run, not a promise that every boundary case will be fast.
Image and raster work need separate guards
Input images use a 60-megapixel per-image guard and a 640 MiB combined decoded-image guard, with a warning at 256 MiB. PDF-to-image style raster exports use different limits: 80 megapixels for one output page and 240 megapixels across a batch, with a warning at 100 megapixels. A single long-image export uses a 90-megapixel total guard. These checks exist because a compressed upload limit alone cannot describe canvas work.
- Five 8,000 × 5,000 images equal 200 million pixels and about 762.9 MiB for one RGBA copy, so the decoded-memory guard rejects that batch.
- One raster page at exactly 80 MP is accepted; one pixel above is rejected by the boundary test.
- A seven-page raster batch at 40 MP per page reaches 280 MP and is rejected above the 240 MP total guard.
OCR has tighter limits because it does more work
OCR must render a page and run recognition rather than only copying PDF objects. The current OCR guards allow up to 75 pages, 40 megapixels for one rendered page, and 200 megapixels across the run. A warning begins at 20 pages or 80 megapixels. The implementation estimates peak decoded work differently for OCR because recognition can need multiple working buffers. Large scans should be split into smaller ranges or rendered at Balanced quality.
- Normal ten-page synthetic workload: accepted without a warning.
- Twenty-page warning boundary: accepted with a warning.
- One page above 40 MP or a run above 200 MP: blocked with a specific recovery instruction.
Cancellation is a product requirement, not a cosmetic button
The tests abort an already-cancelled workload and require it to stop promptly, remain distinguishable from an ordinary failure, and keep current files and settings. Source-integration checks also verify workload guard dialogs and cancellation wiring in Merge PDF, Images to PDF, PDF to Images, and OCR. A user who cancels an expensive render should not lose the documents they already selected.
- A cancelled job reports cancellation rather than a generic conversion error.
- The original files remain open in the workspace.
- A rejected new batch does not mutate the existing selection.
- Cancellation cannot guarantee that every browser releases every allocation immediately.
What these tests do not measure
The suite validates QuickerConvert's configured guard logic; it does not measure a universal browser crash point. Available memory differs across phones, desktops, tabs, browsers, PDF structures, zoom levels, and operating systems. The estimate also cannot include every allocation made inside PDF.js, canvas, OCR, ZIP, or PDF-writing libraries. The limits can change after profiling and should be treated as dated product behavior, not as a hardware specification.
- A file below a guard can still be slow, damaged, encrypted, or unusually complex.
- A high-memory desktop does not make every large run appropriate for a phone.
- Close other heavy tabs, keep originals, use smaller ranges, and review the result.
- If the app warns before continuing, the warning is part of the workflow—not evidence that the file is corrupt.
Conclusion
Do not judge browser workload by compressed megabytes alone. Page count, decoded dimensions, temporary copies, and the type of operation all matter. QuickerConvert's current guards are designed to stop known expensive shapes of work while preserving the user's files, but they do not remove the need to split very large jobs and review every exported copy.