PDF file page and size limitation clarification

Doconut Product Family
1

Hello,

Could you please confirm the maximum PDF file size limit (in MB/GB) supported by the Doconut Viewer for viewing PDFs in the application?

Currently, we are testing a PDF file of approximately 485 MB with 1,595 pages , but the file is not opening properly in the Doconut Viewer.

Could you also confirm the maximum number of pages supported for a PDF document?

We need this information to determine the maximum PDF file size and page count that can be accepted by our application and to communicate the supported limits to the client.

2

Hi @Mohit_Tandel,

Doconut has no fixed limit on the number of pages or on the file size, so your 485 MB, 1,595-page PDF
is not being rejected by a product limit. Pages are rendered on the server one at a time, as the
browser asks for them.

The practical limit is the memory of your server. While a document is open, the server holds the file
(budget at least its size on disk) plus every page already viewed, for each user who has it open. So
the limit to give your client depends on your server and on how many documents are open at once. The reliable way to set it is to test your largest file on a server like the production one.

For PDFs this large, these help:

  • CachePages = false on PdfConfig, so viewed pages are not kept in memory.
  • A lower ImageResolution on PdfConfig. The default is 200; try 100 to 150.
  • A shorter TimeOut (the default is 60 minutes) and a call to CloseDocument when the user leaves,
    so the memory is released sooner.
  • Running the application as 64-bit.

For documents this large we recommend the background publishing mode. It renders the document once, in the background, and then serves its pages from a shared folder or from cloud storage. The web application then does not hold the document in memory for each user who views it, and the viewer opens as soon as the first page is ready.

This mode belongs to the architecture we introduced with Doconut.NET8 and have kept improving since. As of 26.9.0 all four packages share that architecture: Doconut.NET8, Doconut.NET6, Doconut.NETStandard and, new in this release, Doconut.NETFramework. If you are on an older version, tell us which one and we will explain what the update involves.

To see why this file does not open, please send us:

  1. The Doconut package and version, and your .NET version.
  2. What happens exactly: the error text, a viewer that never finishes loading, or blank pages.
  3. The memory of the server, and whether the application runs as 32-bit or 64-bit.
  4. How the file reaches the viewer (a path, a stream, an upload) and the configuration you pass when opening it.

If you can share the file, we will test it here.

3

Hi Gabriel,

Thank you for the detailed information.

Please find our environment and issue details below:

Doconut Package: Doconut.NETStandard 25.10.0

Dot Net Version: .NET core 6.0

Issue: We are getting the following error:
System.NullReferenceException: Object reference not set to an instance of an object.

The Doconut viewer successfully displays the PDF cover page, but subsequent pages are not rendered correctly. Page 2 displays a red X/error icon,
and the remaining pages do not display the actual document content. Please investigate and resolve the page-rendering issue to ensure that all
PDF pages display correctly.

Application: Running in 64-bit mode.
Document Input: The PDF is passed to the viewer through a URL.

The PDF size is approximately 485 MB with 1,595 pages.

We have attached a screenshot showing the issue.
image.png (2.4 KB)

Please let us know if you need any additional configuration details or if there are any recommended settings for handling this large PDF.

Thanks.

4

Hi @ravi0092,

Thank you for the details: Doconut.NETStandard 25.10.0 on .NET 6, 64-bit, the PDF loaded from a URL, and the NullReferenceException after the first page. That gives us what we need to start.

We are investigating it and will get back to you shortly. If you can share the PDF, or a smaller file that shows the same behaviour, it will help us reproduce it on our side.

5

Hi @ravi0092,

Thank you for the additional details.

Doconut does not impose a fixed limit on PDF file size or page count. The practical limit depends on
the server resources, the PDF’s internal complexity, and the number of documents being viewed at the same time.

However, because the first page renders successfully and the following pages fail with a NullReferenceException, we cannot conclude that this is solely a hardware limitation. We are investigating whether the failure is related to the document, the way it is obtained from the URL, the current configuration, or Doconut.NETStandard 25.10.0.

To reproduce and diagnose the issue, please provide:

  1. The original PDF, or a smaller PDF that reproduces the same behavior.
  2. The complete exception stack trace, including inner exceptions, and the related application logs.
  3. The server’s total and available RAM when the error occurs.
  4. The complete PdfConfig and DocOptions values used when opening the document.
  5. The code path used to download the PDF from the URL and pass it to Doconut.
  6. Confirmation that the fully downloaded PDF opens correctly and all its pages can be accessed in
    another PDF application.

As an additional diagnostic test, please download the PDF to a local file and open exactly that file with Doconut. This will help us determine whether the failure occurs while obtaining the document from the URL or while rendering it. Please also tell us whether page 2 fails consistently when it is requested directly.

In the meantime, you may test with CachePages = false and an ImageResolution between 100 and 150 to reduce memory consumption. Please run this test with a single document and a single user. These settings are diagnostic measures and do not yet represent a confirmed resolution.

We also noted that you are using Doconut.NETStandard 25.10.0, which is an older release from the previous Doconut.NETStandard generation. Starting with Doconut.NETStandard 26.8.0, released on August 31, 2026, the package moved from .NET Standard 2.0 to .NET Standard 2.1 and adopted the current Doconut architecture. The current architecture uses dependency-injection-based registration,
asynchronous document sessions, unified middleware and resource delivery, a modular plugin model,
and the distributed publishing path. These changes improve lifecycle management, extensibility, and
multi-node deployment support.

This architecture change is a breaking upgrade rather than a drop-in package update. We recommend
following the .NET Standard migration guide and validating the migration in a staging environment before deploying it to production. The current Doconut.NETStandard release is 26.9.0.

As a maintenance practice, we recommend reviewing and applying Doconut updates monthly, after staging validation, and keeping the core package and all Doconut plugins on the same version. This ensures that the application receives the latest compatibility improvements, rendering fixes, and platform updates. The release notes document each monthly update.

The upgrade recommendation is separate from the current investigation: we will first reproduce the
reported behavior against Doconut.NETStandard 25.10.0 and will provide an update once we identify the cause.