File limits and upload troubleshooting

Image to PDF: current input limits

Image to PDF checks the following limits before accepting an image. These are application guards, not promises that every supported file will finish on every device.

A 6,000 × 4,000 photo has 24 million pixels. One uncompressed RGBA copy alone takes about 96 million bytes; decoding and PDF creation need additional memory. The same photo may occupy only a few megabytes on disk. That is why pixel dimensions matter as well as file size.

A PDF size target controls the output attempt, not these input guards. When you select a target, the tool tries different image quality and scale settings and reports the result it actually achieved. A target can be missed. Read the result message and inspect the downloaded pages before sharing.

When a file will not upload or convert

1. Read the named error. An empty file needs to be exported again from its source. A damaged image should first open successfully in an image viewer. An unsupported format needs conversion, not just a new filename.
2. Try one small file. In Image to PDF, add a single ordinary JPEG or PNG. If that works, add the remaining images in smaller groups to find the file or batch size causing trouble. Valid images stay in the queue when another image is rejected.
3. Separate a loading problem from a file problem. If the processing library reports a loading failure, restore the connection and use Retry. Libraries must download before the browser can process the document.
4. Reduce the working set. Close other heavy tabs, reduce image dimensions or select fewer PDF pages. Keep your originals. Repeatedly submitting the same large batch does not give the tab more memory.
5. Check the output. Open the saved PDF, count the pages, inspect their order and zoom in on small text. A successful conversion message does not establish that the chosen compression settings suit your document.

For choosing between resizing and compression, see the file-size reduction guide. If another tool fails, report the tool name, browser, file format, approximate size and exact error. You do not need to send a private document to describe the problem.

How this was measured

• Test dateAugust 11, 2026 (UTC)
• Operating systemUbuntu 24.04.4 LTS (linux 6.18.5-fc-v20, x64)
• CPUIntel(R) Xeon(R) Processor @ 2.80GHz — 4 cores
• Installed memory15.7 GB
• Chromium151.0.7922.34
• Firefox153.0
• WebKit26.5
• Browser modeHeadless, default flags, one fresh browser per run
• Playwright1.62.1
• Node.jsv22.22.2
• Per-run timeout180 seconds
• Library sourceslocal cache (scripts/measure/.engine-cache) — no network during the sweep
• Fixture seed1366773063

The harness drives the real tool pages the way a person does: it loads the page, waits for the processing library to arrive, puts a file into the file input, presses the button, and waits. Completion is detected by wrapping URL.createObjectURL before the page's own script runs, so the moment the tool produces its output blob is the moment the clock stops, and the blob's size is the recorded output size. Tool-specific drivers select the file input and action button; those selectors are part of the harness configuration.

Test files are generated from a fixed seed, so two runs feed the tools byte-identical inputs:

• PDF file size — A 10-page text PDF padded with one raw-RGB image XObject to reach the target size. Rungs: 1, 5, 10, 25, 50, 100, 250, 500 MB.
• PDF page count — Text-only pages with no images, so the variable is page count rather than bytes. Rungs: 10, 100, 500, 1000, 2500 pages.
• Image file size — Square RGB PNG of incompressible noise, stored uncompressed to hit the target size. Rungs: 1, 5, 10, 25, 50, 100 MB.
• Image pixel count — Square RGB PNG of a smooth gradient, so the file stays small and the variable is pixel count. Rungs: 1, 5, 10, 25, 50, 100 MP.
• Pasted or loaded text — ASCII words, one line of twelve per newline. Rungs: 1, 5, 10, 25, 50, 100 MB.

Each tool is walked up its ladder by binary search rather than one rung at a time, which finds the same answer — the largest fixture that finishes — in three or four runs instead of eight. A run that produces neither a result nor an error within 180 seconds is recorded as a timeout and left as a timeout. It is not retried until it passes.

The processing libraries (pdf-lib, pdf.js, Tesseract.js and the rest) are served from a local cache during the sweep instead of from their CDNs, so CDN latency cannot show up inside a processing time. The raw completed results are public in measurements.json. The reproducible harness source is retained in the private project repository and is not publicly downloadable.

Two different ceilings

When a tool stops working there are two quite different reasons, and most people meet the first one:

• The page refuses the file. A tool may check the file size, dimensions or batch count before processing. That guard is a product decision, not a measurement of device capacity. An error such as “exceeds 50 MB” describes a tool guard.
• The browser gives up. Above the guard, the real limits are the JavaScript heap and the way these libraries work. These tool implementations read the whole selected file before processing; that is an implementation choice, not a claim about every PDF.js integration. A browser tab that has to hold the source file, a parsed object graph of it, and the output at the same time is using several times the file's size in RAM.

The tables below report the guard where a tool has one, and what was measured underneath it.

PDF file size: what completed

Largest fixture each tool finished, per engine. “Time” and “What happens above” are the Chromium run — a failed run is shown explicitly rather than assigned a successful file-size limit.

PDF page count: what completed

Largest fixture each tool finished, per engine. “Time” and “What happens above” are the Chromium run — a failed run is shown explicitly rather than assigned a successful file-size limit.

Peak memory

Only Chromium exposes performance.memory to a page. Firefox and WebKit do not, so there is no peak-heap figure for them here and none has been carried across from the Chromium column — those measurements simply do not exist.

The last column divides sampled JavaScript heap by input size. It is not total tab RAM: worker memory, native canvas allocations and other browser overhead may be absent. Do not use this ratio to estimate a safe file size.

Why the ceiling is where it is

The heap, not the disk. A browser tab gets a JavaScript heap of a few gigabytes at most, and on mobile far less. A 100 MB PDF is not 100 MB of memory once it is open: pdf-lib holds the original bytes, then a parsed object for every page, font and image inside it, then builds the output document alongside the input. The overhead depends on document structure. The table reports sampled JavaScript heap only; it does not measure total process memory.

WebAssembly memory is its own budget. The tools built on WebAssembly — the PDF encryption pair, and Tesseract for OCR — get a linear memory that grows in 64 KB pages and, on a 32-bit WASM build, cannot exceed 4 GB no matter how much RAM the machine has. Memory growth can fail when the requested allocation cannot be supplied. This dataset does not measure total WebAssembly memory.

How the file is loaded matters. The tested QuickMerge integrations read selected files into memory before processing. This describes our integration, not every possible PDF.js configuration. Holding full input and output buffers can cause a sharp failure when an allocation exceeds the tab's available memory.

Rasterising changes the arithmetic. Three tools — compress, redact, and PDF to image — render each page to a canvas before writing it back out. A canvas costs four bytes per pixel regardless of how simple the page is, so a full-page render at print resolution is tens of megabytes of memory per page, and page count matters more than file size.

The main thread is doing the work. Some processing steps run on the page's main thread; other steps use workers. A long synchronous step can delay repainting and input handling. Total processing time in the historical tables is not a measurement of how long the interface was unresponsive.

What this page is not

The caveats here are not fine print; they are the reason the numbers are worth anything.

• One machine. Intel(R) Xeon(R) Processor @ 2.80GHz, 4 cores, 15.7 GB of RAM, on Ubuntu 24.04.4 LTS (linux 6.18.5-fc-v20, x64). Performance on other devices has not been established by this sweep.
• One run per combination. These are single measurements, not averages over repeated trials, and there are no error bars. This dataset cannot establish whether a difference between engines is repeatable.
• Headless browsers. Headless Chromium, Firefox and WebKit are not identical to the browsers on your desk, particularly around GPU-backed canvas work.
• Synthetic files. The fixtures are generated, not collected. A real PDF containing embedded fonts, images and vector art may behave differently from a generated file of the same size.
• WebKit is not iPhone Safari. The WebKit column is Playwright's Linux WebKit build. Safari on iOS has a different JavaScript engine configuration and much tighter per-tab memory limits, and is outside this dataset. Do not read the WebKit column as an iPhone result.
• Binary search assumes monotonicity. The search takes it for granted that if a tool handles a given size it also handles every smaller one. That is true of everything observed here, but it is an assumption the method makes.

The public measurement dataset contains the completed records and fixed fixture seed. The harness source is not public, so this page does not claim that an outside visitor can reproduce the run from the repository.

For the completed cross-engine subset, see the measured browser-support results.