A size ceiling on PDF uploads has a real cost. It is also one of the most over-claimed numbers in enterprise software, so this article gives you a method for measuring your own instead of a figure invented for you.

Introduction

Legacy document-management systems often enforce a hard ceiling of 25 megabytes for PDF uploads. The restriction feels benign — most documents are well under it — until a file is not, and somebody has to do something about it by hand.

We should be straightforward about our own position here, because it would be strange not to: the free viewer at Doconut.app also stops at 25 MB for a PDF. That is our ceiling, and this article is not an argument that ceilings are indefensible. It is an argument that you should know what yours costs before you pay to move it.

A note on the numbers in this article, or rather their absence. Cost models in this genre usually rest on a survey nobody can inspect and a benchmark nobody can source. We have none, so we are not going to print any. What follows is the arithmetic and the questions — you supply the values from your own systems, where they are real.

1. What a rejected upload actually costs

When a PDF exceeds the limit, somebody splits, compresses or recreates it. That is the direct cost, and it has three components you can measure:

Volume. How many uploads are rejected for size? Your application log knows. If it does not record the rejection reason, that is the first thing to fix, because everything below depends on this number and nobody's estimate of it is any good.

Handling time. How long does the workaround take? Time it on five real files rather than guessing. Compressing a scanned contract in Acrobat and re-uploading is not the same job as splitting a 400-page manual into parts that each stand alone.

Ticket rate. What proportion of those rejections become a support ticket rather than being solved at the desk? Pull it from your ticketing system by search term.

The arithmetic is then unremarkable:

rejections per quarter
  x handling time in hours
  x blended hourly rate
+ (rejections x ticket rate x cost per ticket)
= direct quarterly cost

The reason to run it yourself is that the result varies by more than an order of magnitude between organisations, depending almost entirely on volume. For a team that hits the limit twice a month, the honest answer is that this costs nothing worth measuring, and you should stop reading. For a claims department processing scanned files all day, it is a real line item.

2. The indirect cost worth taking seriously

Delay and lost deals are the usual second act, and we are going to skip the revenue modelling, because attributing a lost sale to an upload limit requires evidence that almost nobody has.

One indirect cost is worth naming, though, because it is qualitatively different: splitting a document damages it.

A PDF split into three parts is three files that can be sent separately, versioned separately and archived incompletely. Signatures do not survive the operation — a digitally signed PDF that is split has an invalid signature in every fragment, because the signature covers the bytes of the whole file. Metadata, tags and the structure that makes a PDF/A archivable are inconsistently preserved by whatever tool the user reached for.

If your retention or audit obligations assume the document is one object, a size limit that routinely forces splitting is a compliance problem wearing a productivity costume. That is worth escalating regardless of what the labour arithmetic says.

3. Before you buy anything, check what is in the files

This step is skipped often enough to be worth its own section, because it sometimes ends the project.

Take fifty of the rejected files and look at what makes them big. In our experience of the formats, the usual answer is images at their original capture resolution: a contract scanned at 600 dpi in colour when 200 dpi greyscale would be legible, or a report whose photographs went in straight off a phone. A PDF like that is often several times larger than it needs to be, and fixing it at the source — the scanner profile, the export setting — removes the rejections without any procurement at all.

Sometimes the answer is genuinely a large document, and then you have a real requirement. The point is to know which case you are in.

4. What to ask a vendor, including us

If you do need to raise the ceiling, the questions that matter are not about the ceiling:

Where is the limit enforced, and why? A limit set by an application's own upload handling is a different thing from one imposed by the rendering engine. Ours is the former: 25 MB is what our public site accepts, not what the engine can draw.
What happens at the limit? Rejection at upload with the number named is kinder than a timeout at 90 % — the user learns something either way, but only one of them is quick.
What does the memory curve look like? Rendering a large PDF costs server memory. If you self-host, that cost moves to your infrastructure, and "unlimited" means "limited by hardware you are now buying".
What is preserved? If you are raising the limit to stop splitting files, confirm that the document survives intact — signatures, tags and metadata included.

For the record, so this article contains no number we cannot stand behind: the Doconut SDK is a .NET component you install in your own environment, where the practical size ceiling is your server's memory rather than a policy of ours. We are not going to print a megabyte figure for it, because it depends on your hardware and your documents, and any single number would be marketing rather than measurement.

5. Actionable steps

Instrument the rejections. Log the reason and the file size. One quarter of real data beats any model.
Sample the files. Fifty rejected PDFs will tell you whether you have a size problem or a scanner-settings problem.
Run the arithmetic above with your own volumes and rates, and be willing to conclude the cost is too small to act on.
Check the compliance angle separately. If splitting breaks signatures or audit trails, that argument stands on its own and does not need a cost model behind it.
Pilot with your worst files. Not samples. The 300-page scanned bundle that started the conversation.

Conclusion

A size ceiling is a real constraint with a real cost, and it is also the easiest place in enterprise software to be sold a number. The cost is whatever your volume, your handling time and your rates make it — which might be substantial, and might be nothing.

Measure it before you move it. And if you just have one PDF that is a little too large to read today, Doconut.app takes 25 MB, costs nothing, and deletes the file when you close the tab.

Working out whether the SDK fits? The download page has the trial, and testing it against your own heaviest documents will tell you more than any calculator.