iTextSharp Alternative for .NET HTML to PDF: What to Buy When iText Quotes You, Priced for One SaaS Team

For a .NET SaaS that has just discovered it is shipping iTextSharp under the AGPL, the compliant exits cost between $594 and $5,995 a year, and two of the five alternatives to iText do not accept the HTML templates the team already has. iText itself sells a commercial license, but only by quote. IronPDF publishes every figure: the smallest compliant purchase for any SaaS is $2,998 in year one, and for the three developer team priced here it is $4,398. QuestPDF and PDFsharp are cheap or free and do not render HTML, so switching to either is a template rewrite. A hosted rendering API takes the HTML as is and meters nothing except renders. Every price below was read from the vendor on 18 September 2026.

Why people search for an iTextSharp alternative in the first place

It is rarely about the code. iTextSharp works, and its legacy 5.x branch is still being published: version 5.5.13.6 went up on NuGet on 22 July 2026 under the AGPL. The reason teams leave is the license. iText's own pricing page describes the open source option plainly: "Unlimited number of PDFs. Disclosure of full source code of application needed, (including your own application)." If your product is closed source and customers use it over a network, the AGPL's disclosure obligation is a problem you cannot engineer around, and the alternative iText offers is a commercial license whose price is "Custom" on both models it lists, an OEM Distribution License and a volume-based Subscription License priced on "the quantity of PDF files you process".

So the search is really "what can I buy today with a number on it". That is the question this article answers, and it is worth knowing before you read any other answer that three of the top results for this query are written by IronPDF, which is one of the vendors being compared. What follows is priced against our own product too, so read the last section with the same caution.

The team we are pricing

One shape, held fixed, because every vendor in this category counts something different. A B2B SaaS with three developers, one of whom works from two machines, a build agent in CI, two production instances behind a load balancer, and 20,000 invoices and statements a month generated from HTML templates that a designer maintains. The company is past $1M in annual revenue, which matters for two of the options below. It generates PDFs and it also reads a few thousand supplier PDFs a month, a second job iTextSharp was quietly doing that we come back to at the end.

Option 1: pay iText for the license you already use

The least disruptive route is to keep the code and buy the commercial license, which removes the AGPL obligation and adds support. The problem is that it cannot be priced from public information. The volume subscription is metered on PDF files processed and quoted per customer, and the OEM license is "calculated depending on your specific use case". If your procurement process needs a number before a sales call, this route does not give you one. It also does not fix the version question: iTextSharp 5 is labelled Legacy on iText's own site, and the current product is iText Core 9 with the pdfHTML add-on for HTML input, so a commercial purchase is likely to come with a migration anyway. Our iText license cost guide covers what is and is not published across the whole .NET field.

Option 2: IronPDF, priced properly for a SaaS

IronPDF is the obvious candidate because it renders HTML with a Chromium based engine and publishes a full rate card. For our team the arithmetic is not the $999 the licensing page leads with. Three developers plus a build agent plus a second machine is five developers by IronPDF's own definition, which counts "INDIVIDUALS or DEVELOPMENT MACHINES" including build machines, so the Plus tier's cap of three is exceeded and the team is on Professional at $2,399 today ($2,999 list). Two production instances are two projects, which Professional's ten covers. Because the product is a paid SaaS, the OEM and SaaS redistribution add-on at $1,999 is required. Year one: $4,398. Every year after that, keeping updates and premium support costs $2,399, or $1,799 on standard support, and if you stop paying you keep the version you have and nothing newer.

That is a fair price for a library that also edits, merges, signs and reads PDFs, and if the team needs those things it is probably the right buy. For the single job of rendering invoices it is the second most expensive route on this page over three years, at $9,196 with premium support, behind only Syncfusion's subscription. The full tier, renewal and add-on ladder, with the definitions of what IronPDF counts, is on our IronPDF pricing and license cost page.

Option 3: QuestPDF, the transparent one that does not take HTML

QuestPDF is the best-priced self-hosted license in .NET: $1,999 for a Professional license covering one legal entity, unlimited developers, servers and deployments, redistribution included, renewing at the same price each year with the version kept if you stop. Our team is over the $1M revenue line so the free Community tier does not apply, and $1,999 flat with nothing to count is genuinely attractive.

The catch is the input. QuestPDF is a fluent C# layout API. You describe the invoice in code, container by container, and there is no HTML renderer. For a team whose templates are HTML maintained by a designer, that is a rewrite of every template and a permanent change in who can edit them. Budget the engineering time honestly and QuestPDF is not the cheapest option; it is a different product that happens to be cheap.

Option 4: PDFsharp, free and the same catch

PDFsharp and MigraDoc are MIT licensed with no conditions at all, and for stamping, merging and generating simple layouts from code they are the right answer. They do not render HTML either. Everything said about QuestPDF's rewrite applies here with a less polished layout model, so the honest price of PDFsharp for our team is the engineering time, not zero.

Option 5: Syncfusion, if you have five developers

Syncfusion's Document SDK renders HTML and publishes a price: $1,199 per developer per year with a five developer minimum, so $5,995 a year with Business Support. Our team has three developers, so it pays for two seats it cannot use. The Community License is free but requires under $1M in revenue, five or fewer developers and ten or fewer employees, all at once, and our team fails the first test. This is the most expensive compliant route for this shape, and it stays the most expensive every year because it is a subscription.

Option 6: stop rendering in process

The last route changes what is being bought. Instead of licensing a library and counting developers, machines, instances and add-ons, the application posts the HTML it already has to a rendering API and gets a PDF back. Sitepdf's Growth plan is $99 a month or $594 a year for 50,000 renders, which covers our 20,000 with room for month end, and every render is archived with a timestamp so the invoice a customer disputes in eighteen months can be produced exactly as it was sent. Nothing about the team's size, its CI or its autoscaling appears on the invoice.

It is not free of trade-offs. Rendering leaves your network, which some compliance regimes forbid, and an API generates documents rather than editing existing ones. If either of those is a hard requirement, go back to Option 2.

The six exits side by side

Read the second column before the third. The two cheapest self-hosted routes are cheap because they are not iTextSharp alternatives for this team at all; they are alternatives for a team that generates PDFs from code. Among the routes that accept HTML, the spread is $594 to $5,995 in year one and $1,782 to $17,985 over three, a factor of ten, and the difference is entirely what each vendor decided to count.

The job you forgot iTextSharp was doing

One more thing before you remove the package. iTextSharp is often doing two jobs in an older codebase: generating documents and pulling text out of PDFs that arrive from outside. None of the rendering routes above replaces the second one, and a team that migrates generation and only then discovers the supplier invoice parser has stopped compiling has done the migration twice. Inventory every PdfReader call before you start. For the extraction side, a service that reads the fields out of incoming PDFs and scans is usually a cleaner replacement than another general purpose library, because it was built for that job and does not carry a license model designed for generation.

If you are still weighing engines rather than exits, the C# PDF library comparison goes through each renderer in turn, and the PDF API pricing page prices the hosted field on the same per-render basis used here.