QuestPDF: Building PDFs as C# Code, Not HTML Templates

The problem QuestPDF targets: layout as code, not as markup

Most .NET PDF work starts with an HTML template and an HTML-to-PDF renderer. That pipeline forces a translation step: the layout is authored in markup and CSS, then converted, and the result is only as predictable as the renderer. QuestPDF takes the opposite route. The README describes it as a way to "design documents the way you design software: with clean, maintainable, strong-typed C# code." The document tree is built from C# expressions, so loops, conditionals and helper methods are part of the layout itself rather than a templating dialect layered on top.

The intended audience is the .NET developer who already owns the data. Invoices, reports and exports usually read from models that live in the same solution. QuestPDF keeps the layout next to those models, which means IntelliSense, refactoring and code review apply to the document the same way they apply to a service class. The README's diff example makes the review point directly: changing a padding value from 12 to 16 shows up as a single-line diff inside a ComposeItem method, not as a change buried in a template file.

That framing also sets the boundary. If your organization already has a design team producing HTML and CSS, or a template that non-developers are expected to edit, moving that layout into C# is a cost, not a benefit.

How the fluent document tree works

A QuestPDF document is a single expression. You call Document.Create, receive a container, and describe a page inside it. The page is divided into Header, Content and Footer slots, and each slot returns a container that you can style and fill. The README's quick start sets page size to PageSizes.A4, margin to 2 centimetres, and a default text style of 20 points, then puts a bold blue heading in the header, a column in the content, and a page number span in the footer.

The content slot is where the component model shows. A Column takes a lambda and exposes Item(), and each item is itself a container that can carry padding, borders or background. Nesting is how composition happens: a row inside a column, a table inside a row, a reusable method that takes an IContainer and an item model. The README's second example shows a foreach loop emitting one element per order item and a conditional emitting a summary element only when Model.ShowSummary is true. There is no separate template engine evaluating those branches; they are ordinary C# control flow.

The feature list in the README groups the capabilities that this tree supports: layout primitives such as tables, rows, columns, lists, layers and multi-column flow; visual content including rich text, SVG, raster images and canvas graphics; positioning controls such as aspect ratio, rotation, scale-to-fit and Z-index; and content flow rules such as page breaks, prevent page breaks, ensure space, repeat and show once. Internationalization is covered too, with RTL layout direction, bidirectional text, text shaping and font fallback. The README states the library provides "60+ production-ready features"; the authoritative list lives on the features overview page rather than in the repository.

Installing QuestPDF and generating a first document

QuestPDF ships as a NuGet package. The README gives the terminal command, and the same package can be added from Visual Studio, Visual Studio Code or JetBrains Rider through their NuGet interfaces.

dotnet add package QuestPDF

After the package is restored, the README's quick start is the shortest path to a real file. It sets the licence, creates a page, and writes hello.pdf to the working directory.

using QuestPDF.Fluent;
using QuestPDF.Helpers;
using QuestPDF.Infrastructure;

// set your license here:
// QuestPDF.Settings.License = LicenseType.Evaluation;

Document.Create(container =>
{
    container.Page(page =>
    {
        page.Size(PageSizes.A4);
        page.Margin(2, Unit.Centimetre);
        page.DefaultTextStyle(x => x.FontSize(20));
        page.Content().Text("Hello PDF!");
    });
})
.GeneratePdf("hello.pdf");

The README leaves the licence assignment as a commented line with LicenseType.Evaluation. That is a signal, not boilerplate: the library expects the licence type to be declared in code, and the README points to the pricing page for which tier applies. Run the program and you should get hello.pdf in the output directory, containing one A4 page with the text at the default size. From there, the invoice tutorial and the features overview on the project site are the documented next steps.

The README also mentions a companion app for live preview and hot-reload, described as letting you see changes without recompiling. The repository itself only contains a src directory and the usual GitHub files, so the companion app is distributed separately, and the README does not document its installation.

Where QuestPDF is the wrong tool

QuestPDF generates documents. It does not read, parse or modify existing PDFs. If your task is filling an AcroForm, extracting text, merging third-party PDFs or stamping a signature onto a file someone else produced, this library does not address it, and no part of the README claims otherwise.

The licence is the second constraint, and it is easy to misread. The README states the library is free for individuals, non-profits, open-source projects, and organizations under $1M in annual gross revenue. Above that threshold, the community terms no longer apply. GitHub reports the repository licence as NOASSERTION, meaning the platform could not map LICENSE.md to a standard identifier, so the pricing and licence pages on the project site are the places to resolve the actual terms rather than the repository metadata.

There is also a cost that the README does not discuss: the layout is code, so changing it requires a build and a deploy. A team that expects marketing or operations staff to tweak an invoice header without a release will find that HTML templates, however awkward, match their workflow better. The companion app's live preview narrows the feedback loop during development, but the README does not describe any editing path for non-developers.

QuestPDF compared with PdfSharp and iText

The comparison that matters is where the layout is authored. PdfSharp is a low-level drawing library: you work with XGraphics, coordinates and explicit text measurement, and you decide where every element lands. QuestPDF works at the opposite level. You describe a hierarchy of containers, and the library's layout engine decides positions, wrapping and page breaks. If you need to place a line at an exact coordinate, PdfSharp is the more direct instrument; if you need a table that flows across pages and repeats its header, QuestPDF's repeat and ensure space rules are built for that.

iText sits closer to a document object model. You construct elements and add them to a document, which is nearer to QuestPDF's approach than PdfSharp's canvas is, but the two libraries differ in how the document is expressed and in their licensing models. QuestPDF's distinguishing choice is that the document is a C# expression tree with no intermediate template format, so the same language features that build your application build the report.

None of these differences are settled by the README, which does not benchmark against either library. The practical question is not which is faster but which level of control your document needs. Coordinate-level control argues for PdfSharp. Structural layout with dynamic content argues for QuestPDF.

Maintenance, release cadence and what the licence means for upgrades

The repository was last pushed on 2026-09-17, four days before this writing, and it is not archived. Releases are frequent and date-versioned: 2026.9.0 on 2026-09-14, 2026.8.0 on 2026-08-24, and 2026.7.3 on 2026-08-12. That cadence means version numbers do not follow semantic versioning in the familiar major.minor.patch sense, so a pinning strategy based on a leading major digit will not work. Pinning to an exact version is the only way to control when a document's output can change.

Upgrade cost is not only about API breaks. A PDF is a rendered artefact, and a layout engine change can shift pagination, text wrapping or spacing even when the C# compiles unchanged. The README's own pitch, that you can review document changes like any other code, applies to the source diff, not to the rendered result. Teams generating invoices or regulated reports should keep a rendered sample in their test suite and compare output across upgrades rather than trusting the diff alone.

The licence has a direct upgrade implication. Because the free tier is defined by organization size and use, a company that grows past $1M in annual gross revenue changes tier without changing a line of code. The README links to the pricing and licence pages on questpdf.com for the terms; the repository's LICENSE.md is present but GitHub reports its identifier as NOASSERTION. This is a description of the project's stated terms, not legal advice, and the project's own licence page is the source to read before shipping.

Editorial conclusion

QuestPDF fits teams already writing C# who want document layout to live in the same repository, review process and type system as the rest of the application, and it is free for individuals, non-profits, open-source projects and organizations under $1M in annual gross revenue. It is the wrong choice if your layout already exists as HTML and CSS, or if you need to edit PDFs rather than produce them. Before adopting, read the pricing page and confirm which licence tier your organization falls into, because the README sets the licence through QuestPDF.Settings.License and the repository's LICENSE.md carries a NOASSERTION identifier that GitHub does not map to a standard licence.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. QuestPDF/QuestPDF on GitHub
4. README
5. Releases