Troubleshoot PDF Uploads, Templates, and Builder Problems

PDF problems can happen at three different stages: protected upload/intake, PDF.js page preparation, or Template/Request builder validation. Identify the failing stage first so you do not rebuild a Template when the source PDF itself was rejected—or re-upload a PDF when the real problem is an invalid field assignment.

If the Source File Is Rejected

QCDS signing Templates currently require a PDF source. Convert DOC/DOCX or other documents to PDF before upload. The default file-inspection ceiling is 100 MB, subject to the installation's configured limits and PHP/server upload limits.

QCDS detects the actual MIME type and validates the PDF container. It rejects malformed PDF headers/end markers/cross-reference structure, PDF/archive polyglots, and blocked active content such as JavaScript, launch actions, embedded files/file specifications, or rich media.

If the Upload Is Held in Quarantine

Every source upload enters QCDS quarantine before it becomes an active immutable document object. Server-side validation runs first, followed by the configured document safety inspection.

A malware/safety detection rejects the file. If the safety engine times out or is unavailable, the installation policy either fails closed or leaves the upload safely Held for retry. Review the QCDS storage/document-safety health rather than moving the quarantined file into public storage.

If the PDF Upload Succeeds but Pages Do Not Appear

QCDS stages the accepted PDF and uses its bundled PDF.js runtime in the authenticated interface to create immutable normalized JPEG page renders at the controlled render profile. External server tools such as LibreOffice or Poppler are not required for this PDF path.

Every page must finish before the document is ready. QCDS rejects incomplete/out-of-order render manifests, mismatched page counts, unsupported page geometry/rotation, wrong image type, or a different render attempting to overwrite an existing immutable page. The configured page maximum defaults to 1,000.

If Template Validation Blocks Publish

Publishing runs server validation. Common blocking errors include:

  • no ready PDF document, duplicate/missing document keys, or incomplete canonical page metadata;
  • a field/asset referencing a missing document/page or sitting outside the printable page;
  • a retired/unsupported field type or invalid field definition;
  • a Signed Date with an invalid Signature/Initials link, assignment mismatch, or non-read-only configuration;
  • an unavailable asset version, unknown variable, or invalid rule definition.

Warnings such as very small fields, overlapping items, or a required participant role with no required action deserve review but are separate from hard validation errors.

If the Request Builder Fails at Send

A published Template can still require Request-specific fixes before Send Now—for example, concrete signer ownership for signer-controlled fields, a Request Text value, or a valid Signed Date link. Use Check to catch current browser-side field/assignment issues, then let Send Now perform the authoritative server validation.

Isolate Difficult PDFs Safely

If the cause is unclear, try a small ordinary PDF in the same workspace. If the simple PDF completes intake, page preparation, and builder validation, compare the failing source for corruption, active/embedded content, extreme size/page count, or unsupported structure. Preserve the original failing file privately if support needs it; do not post customer documents publicly.

Community Discussion

Want to compare workflows, share practical tips, or discuss how you use this QCDS feature? Visit the QC Digital Signature Community. For private support, bug reports, account-specific issues, or feature requests, use the QuantaCade support system.