Editorial illustration.
Originally published 23 June 2023; rewritten and reviewed on 15 October 2026.
A small “Hello, World” PDF is a useful first experiment. The next document usually contains customer data, several pages and an expectation that it can be downloaded reliably. I would settle ownership of the document and its stream before adding more layout.
Keep the legacy API context visible
The original post used iTextSharp’s Document and PdfWriter classes. Those names identify a particular library generation. Check the package version and licence obligations before adopting the same approach in a new application.
The basic lifecycle is:
Create a bounded output destination
→ Attach the writer to the document
→ Open the document
→ Add validated content
→ Close the document so final structures are written
→ Return or persist the completed output
This outline is deliberately separate from a current package-specific implementation. It makes the ordering requirement visible without implying that every iText version exposes the same methods.
Plan for realistic content
Choose fonts that cover the required characters and confirm how they are embedded. Test long paragraphs, page breaks, tables and images. Avoid deriving server file paths directly from a browser-supplied name.
For a web response, control memory use and the lifetime of the stream. A writer may close a destination stream unless configured otherwise. A response cannot reliably read from a stream that has already been disposed or returned before the document is finished.
Make an export failure distinguishable
Do not send an HTML error page with a PDF filename. Return an appropriate failure response and log a diagnostic reference without exposing personal document content.
Open generated files independently and inspect the actual pages. The lesson from the small sample is useful: a PDF has a lifecycle. Respecting that lifecycle makes it easier to expand from a tutorial into an export feature someone can support.