# Working with large documents

Note

The information on this page applies to both our SOAP services as well as our REST Sign API. Learn about our different signature services in our introduction to our electronic signature APIs.

# Background

It is highly advisable to keep document sizes to a minimum at all times. During a signing process, the following data transmissions will occur, with slight variations depending on the signing method:

  1. The original document is sent in binary form from your server to Signicat.
  2. Signicat prepares the original document for the signing process, encoding it in a format suitable for web data transmission. Base64-encoding a document will increase the document size by about one third.
  3. The end-user is required to download the original document, usually in a binary format so that it can be displayed in a PDF reader without conversion.
  4. The end-user is required to download the base64-encoded document, which is what will be signed.
  5. The base64-encoded original is signed and wrapped in an XML signature format along with additional information. This process may add another 33% to the document size.
  6. The signed document is transferred from the end-user and back to Signicat.
  7. Your application downloads the document.

Given that the original document is 1 MB, the following transmission sequence will take place: 1 MB + 1 MB + 1.33 MB + 1.77 MB + 1.77 MB = 6.87 MB. Consider the following diagram:

click-to-zoom

The x-axis shows the original document size in KB, so 740 KB ≈ 0,7 MB, 2143 KB ≈ 2 MB, etc. This diagram illustrates the amount of data required to be passed back and forth between the end-user and Signicat during a signing process. As you can see, the total payload will exceed 10 MB when the original document is larger than 2.5 MB, or 20 MB when the original is 4.2 MB. In addition, if you are using Signicat’s PackagingService to create PAdES or LTV-SDO output, the size of the final result document will be even larger than that; in terms of document sizes only (disregarding data transfer), a 4.2 MB original will result in a 10 – 15 MB PAdES result.

Transferring these data amounts comes at a cost. It will reduce response times and make the application seem slower. It will also increase the sensitivity when it comes to network connectivity. Therefore try to keep your documents as small as possible.

The largest possible document size will vary, depending on the signing method. In general, it will never be possible to use a document which results in a signed document size that exceeds 10 MB. The diagram above tells us that this restricts the original document to a maximum size of ≈ 4.2 MB.

In cases where a PAdES package might exceed the limits outlined above, the risk of an error occurring during the packaging process (due to timeouts, memory starvation or similar issues) is higher the bigger the package is. In such cases, Signicat recommends the use of detached signature, which is performed by not including the source document in the XAdES (resulting XML document attached to the PAdES).

This is achieved through a change in the configuration, so you must ask Signicat to make this change if you intend to use this method. By using this method, the resulting PAdES will have a manageable size and performance should improve. The validity of the electronic signature will not be affected. All of this applies for the XAdES as well, but you will be required to keep the source document linked to the XAdES, if needed (for instance, for audits).

# How to minimise document size

  • Let the user sign only what needs to be signed.
  • Avoid bitmap (graphics) intensive documents. Do not include photos, graphs, charts and uncompressed logos in the document.
  • Most PDF documents can be compressed and reduced in size without apparent loss of quality using readily available compression mechanisms.
  • If the PDF is generated from Adobe programs such as InDesign and Acrobat you can choose “Smallest file size” when exporting the PDF.
Last updated: 20/09/2023 12:20 UTC