Editorial illustration.
Originally published 23 June 2023; rewritten and reviewed on 15 October 2026.
The HTML looks correct in a browser, but the generated PDF has missing fonts and a table split across the wrong page. A PDF library returning without an exception is only the start of verification. The renderer’s supported layout model determines what it can produce.
Identify the generation of the library
The original article used iTextSharp with XML Worker. That is a legacy approach, not a general browser engine for arbitrary HTML and CSS. iText’s legacy product page explains the product’s place and points new implementations toward its current offerings.
Before changing a maintained system, establish the installed packages, supported runtime and licence terms. A migration to a different iText generation is not merely a namespace replacement.
Treat the HTML and resources as controlled inputs
Use a template designed for the chosen renderer. Resolve fonts, images and styles through a controlled resource policy. Do not allow untrusted HTML to make arbitrary network or filesystem requests while rendering.
Encode user-provided values as text where they enter the template. Apply limits to document size, image dimensions and processing time. A PDF export endpoint also needs permission checks for the records being exported.
Verify the pages, not just the file
Test long names, multiple pages, non-ASCII text, empty sections and missing images. Open the PDF in a separate viewer and inspect page breaks, margins and reading order. Where selectable text or accessibility matters, include those requirements in the acceptance criteria.
For a legacy project, retain a representative output set before changing packages or templates. Compare the result after each change. The valuable outcome is a document someone can read and rely on, with a rendering process the team understands—not simply a download ending in .pdf.