Maximum PDF size in a browser

Is there a maximum PDF size in a browser?

No, not in the sense of a number written in a specification. No browser defines a maximum PDF size, because the browser does not know what a PDF is: it knows what a file is, what a block of bytes is, and what a drawing surface is. The ceiling shows up when one of those three breaks.

That changes the useful question. Instead of "how big can it be", the question to ask is "which limit will I hit first", and the answer depends on what you are going to do with the file. Reading and reordering pages costs memory proportional to the file. Rasterising costs memory proportional to page area times page count, and is always far more expensive.

Which hard limits exist, with numbers?

The canvas limit is on area, not on side length: in Safari, 4097 by 4096 fails but 5120 by 3072 passes, and both are larger than 4096 on one side. When the limit is exceeded there is no loud error: the context comes back empty or transparent, and what you get is a blank page.

How much memory does drawing one page cost?

A canvas holds four bytes per pixel: red, green, blue and alpha. The arithmetic is direct, and it is the number that decides everything that follows.

A PDF uses 72 points per inch as its base unit, so the drawing scale converts straight into resolution. An A4 sheet measures 595.276 by 841.890 points. Across the three levels of our compression that gives:

The last column divides the 384 MB budget of Safari on iOS by the cost of one page. It gives the order of magnitude, not a guarantee: Safari does not release a canvas the instant it stops being referenced, it holds on to it for a while, so the real page count before failure is lower than the division suggests.

Notice what the table says about page format, not only page count. An A0 poster (841 by 1189 mm) drawn at the medium level gives 18,077,306 pixels, above the 16,777,216 that Safari accepts: that page comes out blank. At the strong level it gives 9,720,908 and it passes. In Chrome, the 268,435,456 pixel limit is only reached by a square page nearly three metres on a side.

What changes between 32 and 64 bit?

The address space changes, and with it the ceiling of a single contiguous block of bytes. In a 32 bit process the length of a block is held in a signed 32 bit integer, so no block can exceed 2,147,483,647 bytes. It is a hard limit independent of the RAM in the machine: you can have 32 GB installed and still hit it.

In a 64 bit process that ceiling disappears, and what governs instead is the browser allocator and free memory. In Chrome, the allocator does not usually hand out more than around 2 GB for a single block, even in 64 bit.

Where you still meet 32 bit in 2026: old Windows installations and Android phones with 32 bit processors. If your browser is 32 bit and the PDF is over 2 GB, it never even gets read.

What changes on a phone?

Three things, all of them for the worse.

• Less memory per tab. A phone has less RAM and the system kills tabs far more readily than a computer does. On an iPhone the page reloads on its own and you lose the work.
• The Safari canvas budget on iOS, which is 384 MB since iOS 15 and 224 MB before that. It is a limit that exists in no desktop browser.
• Slower processors. Drawing and JPEG encoding run on the main thread, so the tab stops responding during the operation. On a phone that lasts longer and looks like a fault.

At what point does BestPDFInTheWorld choke?

Part by part, and the first thing to say is what we do not know: we have never measured a ceiling of our own with test files, so there is no number here of the form "above X MB it fails". What there is, is what can be stated with certainty about the implementation.

• On the free tier the cut is ours and it is at 10,485,760 bytes, that is 10 MB, checked per file before compression starts. Above that the operation never begins.
• With an active subscription we check no size at all. The check is skipped entirely and the ceiling becomes the browser. That is a deliberate decision, but it means a subscriber can pick a file the browser cannot take and watch the tab die with no warning from us.
• Many of the thirty-three tools draw nothing. Merge, split, rotate, delete pages, images to PDF, number, watermark and protect only manipulate document structure. The cost is on the order of a few multiples of the file size, and these are the ones that take larger files.
• Compress and PDF to image rasterise, and so they fail first. The cost grows with page area times page count, per the table above.
• PDF to Word does not rasterise, but it walks the whole document to extract the text, and keeps the result in memory to the end.
• Reading and decoding the PDF run in a Web Worker, with their own memory and off the main thread. Canvas drawing and JPEG encoding run on the main thread, which is why the page stops responding during a long compression.
• There is no per page progress bar and no cancel button. A long operation is indistinguishable from a stuck one, and that is a defect of ours.

How do I work with a large PDF without killing the tab?

1. Split before doing anything else. Splitting does not rasterise, and going from one 400 page file to eight of 50 moves the problem somewhere else.
2. Delete the pages you do not need before compressing. Fewer pages is less canvas.
3. Pick the strong level on long documents. It costs 2,428,740 bytes per A4 page instead of 8,022,576, that is a third.
4. Do it on a computer, not on the phone, when the document is long. The iOS canvas budget is the tightest limit of them all.
5. Close the other tabs. The memory belongs to the process, and a tab playing a video is taking it from you.
6. Always keep the original. If the tab dies halfway there is no recovery: nothing was saved anywhere, because there is no server.

Sources

• MDN, elemento canvas
• Chromium, dimensão máxima do canvas (issue 339725)
• WebKit, limite de memória total de canvas (bug 195325)
• PQINA, Total canvas memory use exceeds the maximum limit
• Mozilla, ArrayBuffer acima de 2 GB em processos de 64 bits