C# PDF Library: HTML to PDF C# and .NET PDF Library Costs Compared

QuestPDF has become the default recommendation in .NET circles for good reason. You describe the document in a fluent C# API, the layout engine handles pagination and measurement for you, and the output is real vector PDF with selectable text. Compared with hand positioning elements in PDFsharp or fighting iText document model, it is a pleasant library to work in, and it is actively developed.

Document.Create(container =>
{
    container.Page(page =>
    {
        page.Size(PageSizes.Letter);
        page.Margin(2, Unit.Centimetre);
        page.Header().Text("Invoice 8842").FontSize(20).SemiBold();
        page.Content().PaddingVertical(1, Unit.Centimetre).Column(col =>
        {
            foreach (var line in invoice.Lines)
                col.Item().Text($"{line.Description}  {line.Amount:C}");
        });
        page.Footer().AlignCenter().Text(t => t.CurrentPageNumber());
    });
}).GeneratePdf("invoice-8842.pdf");

Now the part most comparison articles skip. The QuestPDF README states plainly that the library is "free for individuals, non-profits, open-source projects, and organizations under $1M in annual gross revenue". Above that line you need a paid license: 1,999 USD for Professional, which the pricing page describes as covering "one legal entity shipping PDFs in production, every developer covered at one flat, predictable price", or 4,999 USD for Enterprise where a corporate group needs affiliate wide coverage. Two details are worth knowing before you commit. The Community license is explicitly not an OSI approved open source license, and its own text says the MIT License does not govern use of the software under it. And public sector entities and publicly traded companies are ineligible for the free tier regardless of revenue. If you cross the threshold there is a 90 day transition period, with no back payments for the period when you did qualify.

The hard limit is a design decision, not an oversight. QuestPDF markets itself with the line "Stop fighting with HTML-to-PDF conversion". There is no HTML input, no CSS parser and no plan for one. If you already have a Razor view, an email template or a marketing page that needs to become a PDF, QuestPDF means rebuilding that entire layout by hand in C# and then maintaining two versions of it forever. That is the tradeoff: a beautiful API for documents you author in code, and no path at all for documents you author in markup.

iText is the oldest and most capable PDF toolkit in .NET, and with the pdfHTML add-on it does convert HTML and CSS to PDF. It is also the single most common licensing accident in the ecosystem, which is why itextsharp license and itext license are among the most searched terms in the whole .NET PDF space.

The iText for .NET repository states that the library is "dual licensed as AGPL/Commercial software" and that "The AGPL is a copyleft license, which means that any derivative work must also be licensed under the same terms." iText own licensing page is more direct about what that means in practice: "You may not deploy it on a network without disclosing the full source code of your own applications under the AGPL license" and "You must distribute all source code, including your own product and web-based applications." The network clause is the trap. Unlike the GPL, the AGPL is triggered by users interacting with your software over a network, so an internal ASP.NET Core service that generates invoices for customers can fall inside it. There is also a requirement to retain the producer line and copyright notice in the PDF metadata.

Read that against a normal SaaS product and the conclusion is uncomfortable: if you ship a closed source commercial application and it generates PDFs with iText under the AGPL, you are out of compliance unless you publish your own source. The legitimate answer is a commercial license, which iText offers as either an OEM distribution license or a volume based annual subscription. Neither has a published price. The buying page lists both as custom and directs you to request a quote, so you cannot budget for iText without a sales conversation.

A common misconception deserves clearing up. Older iTextSharp releases, up to version 4.1.6, were LGPL or MPL, and a great deal of code and Stack Overflow advice on the internet still assumes those terms. Everything from iText 5 onward is AGPL. Copying a 2011 answer into a 2026 codebase inherits the newer license, not the older one, because the license that applies is the one attached to the package version you install. If your solution has an iTextSharp package reference that predates the change, that does not make new work under it safe. If your solution has an iTextSharp package reference that predates the change, check the installed version rather than assuming the old terms carried forward.

If licensing risk is what keeps you awake, PDFsharp is the cleanest answer in .NET. The project README states it is "Published Open Source under the MIT License". That is MIT with no revenue threshold, no disclosure obligation, no employee count and no transition period. You can ship it inside a closed source commercial product, at any scale, and owe nothing.

What you get for that is a lower level toolkit. PDFsharp draws on the page: you position text, lines, images and shapes yourself, in device independent units. MigraDoc sits above it and adds a document model with paragraphs, tables and styles, which is the layer most people actually want, and it handles pagination for you. Between them you can produce a professional invoice or report, and the output is small and fast.

Neither reads HTML. There is no CSS engine anywhere in the stack, and the documentation does not claim one. Every article you find suggesting PDFsharp for HTML to PDF is describing a third party bridge that parses a narrow subset of HTML and drops most of the CSS on the floor. If your source document is markup, this is the wrong branch of the tree entirely.

The practical way to choose between the two free code first libraries: QuestPDF has the far nicer API and better layout engine, PDFsharp has the simpler license and a longer track record. If you are under the revenue threshold and expect to stay there, take QuestPDF. If you are a large company, or a public sector body, or publicly traded, or you simply do not want a license question resurfacing at your next funding round or audit, PDFsharp costs nothing under any circumstance.

When your document really is HTML, the libraries that work are the ones that ship a browser engine inside the package. IronPDF is the best known. You hand it an HTML string, a file or a URL and it renders through a bundled Chromium, so modern CSS, web fonts and JavaScript all behave the way they do in a browser, and the text stays selectable.

var renderer = new ChromePdfRenderer();
renderer.RenderingOptions.PaperSize = PdfPaperSize.Letter;
renderer.RenderingOptions.PrintHtmlBackgrounds = true;

var pdf = renderer.RenderHtmlAsPdf(invoiceHtml);
pdf.SaveAs("invoice-8842.pdf");

IronPDF publishes its prices, which is more than iText does. As read on 9 August 2026 the perpetual tiers are Lite at 999 USD for one developer, one location and one project, Plus at 1,499 USD for three of each, Professional at 2,399 USD for ten of each, and Unlimited at 4,799 USD. There is a 30 day free trial with full functionality, but no free tier for production use. Perpetual pricing means no recurring fee, though ongoing support and updates are a separate consideration.

Syncfusion offers a PDF library inside its component suite, and its Community License is genuinely free but the eligibility conditions are the tightest in this comparison. Syncfusion states the free license is for "Companies and individuals with less than $1 million USD in annual gross revenue, 5 or fewer developers, and 10 or fewer total employees", and adds that an organization "may not have ever received more than $3,000,000 USD in capital from an outside source, such as private equity or venture capital". Three separate ceilings plus a funding history test. A ten person startup that raised a 4M USD seed round is ineligible on the funding clause alone even though it passes revenue and headcount.

The shared constraint for this whole camp is architectural rather than commercial: these are server side libraries that need a Chromium engine present on the machine. That is fine on a virtual machine or a container you control. It is a real problem inside a Blazor WebAssembly app, which has no server process at all, and awkward on a constrained serverless platform. The Blazor HTML to PDF page works through that hosting question in detail, because in Blazor your hosting model rules half these options out before you compare a single feature.

Aspose.PDF sits in the same commercial camp and is worth a look if your requirement runs past rendering into editing, form filling and format conversion, though it prices on developers and offices rather than volume, and one remote team can fail the cheapest tier without processing a single extra document. The full ladder, from $1,199 to $59,950, is broken down on our Aspose PDF pricing page.

You can skip the commercial engines and drive a browser directly. PuppeteerSharp is the .NET port of Puppeteer, and Microsoft ships Playwright for .NET as a first class library. Both are open source, both download and control real Chromium, and both produce exactly the output the browser print pipeline produces, because that is literally what they call.

using var playwright = await Playwright.CreateAsync();
await using var browser = await playwright.Chromium.LaunchAsync();
var page = await browser.NewPageAsync();

await page.GotoAsync("https://app.example.com/invoices/8842",
    new() { WaitUntil = WaitUntilState.NetworkIdle });

await page.PdfAsync(new()
{
    Path = "invoice-8842.pdf",
    Format = "Letter",
    PrintBackground = true
});

Two options matter more than the rest. PrintBackground = true is off by default, which is the single most common cause of an invoice arriving with white boxes where the branded header should be. And waiting for network idle, or better for a specific selector, is what stops you capturing a page before its data has loaded.

The license is free. The operating cost is not. You are now responsible for a browser: installing its system dependencies in your Docker image, keeping the Chromium version current for security, capping concurrency so a burst of report requests does not exhaust memory, disposing pages and contexts so handles do not leak, and handling the cold start every time a fresh container launches its first browser. On AWS Lambda this collides with hard platform limits. The published quotas are 50 MB for a zipped deployment package and 250 MB unzipped including layers, which a full Chromium does not fit inside, so you end up on container images or a stripped build. None of this is unsolvable. It is simply infrastructure work that a licensing table never shows you, and on a small team it usually costs more per year than the license you avoided.

Whichever library you land on, the same architectural error shows up in almost every first implementation: generating the PDF inside the HTTP request that asked for it. A Chromium render of a real invoice takes somewhere around one to three seconds. Kestrel handles that fine at low volume, but under load those threads are occupied and your API latency tracks your PDF engine rather than your application.

The pattern that holds up is the same in every stack. Accept the request, queue the job, return a 202 with a location the client can poll or a webhook you will call, and generate the document on a background worker. In .NET that is a hosted service with a channel for small workloads, or Hangfire, or an Azure Storage queue with a worker service for anything serious. This matters more with an in process engine than with an API, because an in process Chromium competes with your web application for the same memory on the same machine, and a memory spike during a large report takes the whole site down rather than just failing the report.

The other thing to decide early is where the finished file lives. Writing PDFs to the local disk of a container works right up until you scale to two instances and half your download links start returning 404 because the file is on the other machine. Object storage from the start, with the document id in your database rather than a file path, saves a painful migration later. The document generation API page covers the queue and template merge pattern in more depth, and bulk HTML to PDF covers what changes when you are rendering thousands of documents in a batch rather than one at a time.

A hosted rendering API runs managed Chromium on someone else infrastructure. From C# it is an ordinary HttpClient call, so there is no NuGet package with a license attached, no engine in your deployment artifact, no browser pool to tune, no cold start, and no Lambda package limit to work around. It behaves identically from an Azure App Service, a container, a Lambda, a Blazor WebAssembly app or a developer laptop, because from your application it is just an outbound HTTPS request.

var res = await http.PostAsJsonAsync("https://api.sitepdf.com/v1/render", new
{
    url = "https://app.example.com/invoices/8842",
    format = "Letter",
    margin = "normal",
    archive = true
});

var doc = await res.Content.ReadFromJsonAsync<RenderResult>();

Send a url and Chromium loads the page the way a signed in visitor would, JavaScript included, so a Chart.js dashboard renders as a chart rather than an empty container. Send an html string instead when your Razor view is rendered in memory and never served at a public address. The output is true vector text, so it stays selectable, searchable and accessible rather than being a picture of a document.

The archive flag is the part no NuGet package offers. It stores a timestamped snapshot of exactly what Chromium rendered, retrievable later by id, so eighteen months on you can show precisely what a given statement looked like at the moment you produced it. For finance, insurance, healthcare and anything with a records retention requirement, that dated record is usually the reason to render through an API rather than in process. See the PDF generator API page for the full call surface, website archiving for how the record works, and PDF API pricing for what every vendor in this category charges per 1,000 documents. For the other side of that decision, our PDF SDK pricing and licensing comparison records what IronPDF, QuestPDF, Syncfusion, Apryse and five more actually publish.

The honest limit: an API is a network call, so it adds latency an in process library does not have, it needs outbound network access, and it will not work in an air gapped environment. If you generate forty invoices a month from data you already hold, QuestPDF under its free tier will beat this on every axis and you should use it. The case for an API strengthens with HTML source documents, with volume, with serverless hosting, with a licensing department that does not want another perpetual agreement, and with any requirement to prove what you rendered.

Work down this list and stop at the first line that matches you.

• Your document is built from data and your company is under 1M USD revenue. Use QuestPDF. Best API in .NET, free at your size, and nothing else on this list is simpler.
• Your document is built from data and you are large, public sector or publicly traded. Use PDFsharp with MigraDoc. MIT with no conditions beats a license negotiation.
• Your document is already HTML and you can publish your application source. iText 7 with pdfHTML under the AGPL is a legitimate free option. Almost nobody shipping commercial software can accept this clause, so read it properly before assuming you can.
• Your document is already HTML, you ship closed source, and you want a package on your own servers. IronPDF from 999 USD, or Syncfusion if you clear all three of its community ceilings including the funding history test.
• You want Chromium fidelity for free and you have infrastructure people. PuppeteerSharp or Playwright for .NET. Set PrintBackground = true, cap concurrency, and budget for the container work.
• You want Chromium output without a license, a browser or a deployment problem, or you need a dated record of what you produced. Use a rendering API. Every constraint in the two sections above comes from the engine living inside your own process.

If you are working in a specific framework rather than plain .NET, the Blazor HTML to PDF page covers the Server and WebAssembly split, and the same decision in other stacks is laid out on HTML to PDF in Node.js, Python PDF generation and HTML to PDF in Spring Boot. For the head to head against the specific tools people shortlist alongside these, see the best HTML to PDF API comparison.