iTextSharp for HTML to PDF in 2026: it is dead, here is what to use

iTextSharp is end-of-life. The last release was 5.5.13.5 in January 2026, the official GitHub repo is marked DEPRECATED, and it targets.NET Framework 4.6 through 4.8 only. It does not officially support.NET 8 or.NET 10. The modern answers for HTML to PDF in C# are iText 7 with the pdfHTML add-on (AGPL or paid commercial), PuppeteerSharp (Apache 2.0, runs Chromium), or a hosted HTML-to-PDF API (no AGPL, no Chromium to manage).

Key Takeaways

- iTextSharp is deprecated. GitHub repo marked DEPRECATED, last release 5.5.13.5 (January 2026), security fixes only, targets.NET Framework 4.6 through 4.8 only.
- XMLWorker cannot render modern CSS. No flexbox, no CSS Grid, no JavaScript, no media queries, fragile inline CSS only, Latin-1 fonts by default. The capability ceiling is roughly 2010-era CSS.
- iTextSharp 5+ is AGPLv3 plus paid commercial. Most SaaS and closed-source uses require the commercial license, including the apps shipping iTextSharp 5 today. Distribution or operating it as a network service triggers the copyleft.
- Current iText is iText Core 9.6 (April 2026), and HTML to PDF lives in the separate pdfHTML 6.3.2 add-on. Both carry the same dual AGPL plus commercial license.
- The clean 2026 paths: PuppeteerSharp (free, real browser, Chromium operating cost), iText 7 + pdfHTML (modern CSS, paid license unless AGPL is acceptable), or a hosted HTML-to-PDF API (no license dance, no Chromium to manage).

If you searched "iTextSharp HTML to PDF" in 2026, the recipe is not the problem. The library is. Legacy.NET Framework codebases everywhere still ship XMLWorker.ParseXHtml, the AGPL most teams do not realize they were already bound by, the.NET 8 migration that broke the build last sprint. The Stack Overflow answers are a decade old. The official iText KB hints at deprecation in fragments without saying the word out loud.

This page says the word out loud. Then it lays out the four paths forward honestly, with working code for each. If you are picking among broader C# HTML-to-PDF options (DinkToPdf, Weasyprint.Wrapped, PuppeteerSharp, iText 7), see our C# HTML-to-PDF guide. This page goes deep on iTextSharp specifically and on what replaces it.

Is iTextSharp still maintained in 2026?

No. The repo at github.com/itext/itextsharp carries the [DEPRECATED] marker on the README. The last release is 5.5.13.5, shipped in January 2026 as a security-fix-only patch. It targets .NET Framework 4.6.1 through 4.8.1 and does not officially support.NET 8 or.NET 10. The official iText project moved to iText 7 in 2017 and is now at iText Core 9.6 as of April 2026. HTML to PDF support moved to a separate add-on called pdfHTML, currently at version 6.3.2.

There is a community fork called iTextSharp.LGPLv2.Core on NuGet. It is a.NET Core port of the pre-AGPL iText 4 codebase, kept under LGPL v2 for license compatibility. It exists, it has light maintenance, and it does not include XMLWorker, which means it cannot do HTML to PDF in any practical sense. Useful as a bridge for basic PDF generation on.NET 8, not as an iTextSharp HTML-to-PDF replacement.

How to convert HTML to PDF with iTextSharp (for the readers shipping today)

If you are still on iTextSharp because you ship an internal.NET Framework tool that never leaves the LAN, and you cannot move off it today, here is the working recipe. The licensing math (more on that below) is genuinely fine for that case.

Install

Install-Package iTextSharp -Version 5.5.13.5
Install-Package iTextSharp.xmlworker -Version 5.5.13.5

XMLWorker is shipped as a separate NuGet package and is the part that actually does HTML to PDF.

Minimal converter (HTML string to PDF bytes)

using System.IO;
using iTextSharp.text;
using iTextSharp.text.pdf;
using iTextSharp.tool.xml;

public static class HtmlToPdf
{
    public static byte[] Convert(string html)
    {
        using var ms = new MemoryStream();
        using var doc = new Document(PageSize.LETTER, 36, 36, 36, 36);
        var writer = PdfWriter.GetInstance(doc, ms);
        doc.Open();
        using var sr = new StringReader(html);
        XMLWorkerHelper.GetInstance().ParseXHtml(writer, doc, sr);
        doc.Close();
        return ms.ToArray();
    }
}

That is the whole pattern most legacy codebases call. Pass an HTML string, get a byte array back, write it to disk or stream it to the caller.

Gotcha 1: it expects XHTML, not HTML

XMLWorker is an XML parser with HTML conventions bolted on. Real-world HTML (unclosed <br>, lowercase attributes without quotes, <img> without alt) breaks the parser silently. Run your input through HtmlAgilityPack first to clean it into well-formed XHTML, or accept that some pages render empty without an error.

Gotcha 2: CSS support stops in 2010

No flexbox. No CSS Grid. No media queries. No modern color functions. No oklch(), no var() custom properties. Inline <style> and style="..." attributes only, and even those handle a fraction of CSS 2.1. If your template uses anything written after 2014, expect it to render wrong or not at all.

Gotcha 3: Unicode and fonts

Default fonts are Latin-1 only. Non-ASCII characters render as squares until you register a Unicode font and tell XMLWorker to use it. The fix most tutorials skip:

var fontProvider = new XMLWorkerFontProvider();
fontProvider.Register("C:\\fonts\\NotoSans-Regular.ttf", "NotoSans");
var cssAppliers = new CssAppliersImpl(fontProvider);
var htmlContext = new HtmlPipelineContext(cssAppliers);
htmlContext.SetTagFactory(Tags.GetHtmlTagProcessorFactory());

Ship the font file with your application. Most non-English invoices that "look broken" are this bug.

Gotcha 4: no JavaScript

XMLWorker reads HTML as text. Chart.js, D3, React with client-side hydration, anything client-rendered renders as the empty container the server sent. If your template depends on JS, iTextSharp is the wrong tool regardless of which version you are on.

The iTextSharp license trap (AGPL in plain English)

Most teams shipping iTextSharp 5 do not realize they are using AGPL code. This is the section every C# tutorial skips, and it is the most expensive thing to skip.

The short version. iTextSharp 5+ (every release after December 2009) is dual-licensed: AGPLv3, or a paid commercial license. The same applies to iText 7+. You pick one. If you pick AGPL, the copyleft applies.

What AGPL actually triggers. Two things. First, distributing the application that uses iTextSharp. Second, operating it as a network service that users interact with. Either of those activities requires you to make the entire application's source code available under AGPL.

Plain English for SaaS teams. Shipping a web app that uses iTextSharp internally to generate PDFs for users is an AGPL trigger. The app is "operating as a network service." The copyleft says the user has the right to the source code of that app. If you cannot ship your source under AGPL, you need the commercial license.

Plain English for desktop teams. Shipping a desktop installer that includes iTextSharp is an AGPL trigger by distribution. Same answer.

What is actually fine. Internal corporate tools that never leave the building, where the users are employees rather than the public, are the rare case AGPL does not bite. The "batch job that emails invoices to accounting, runs on a server in our office, never has a public-facing user" pattern is genuinely OK. Most iTextSharp legacy code lives in that pattern, which is part of why this trap stays hidden.

The commercial license costs money. It is per-developer per year, priced on iText's "How to buy" page. If you cannot accept AGPL and cannot pay, you need a different engine. The next three sections cover the realistic options.

Path 1: migrate to iText 7 plus pdfHTML

This is the in-place upgrade if you want to stay on the iText stack.

What changed

iText 7 (now iText Core 9.6) is a clean-room rewrite. The HTML-to-PDF feature became a separate add-on called pdfHTML, currently at version 6.3.2. It uses a proper CSS parser, supports modern CSS including flexbox and partial CSS Grid, and produces tagged PDFs with PDF/UA-1 and UA-2 accessibility compliance.

Install

Install-Package itext -Version 9.6.0
Install-Package itext7.pdfhtml -Version 6.3.2

Minimal converter

using System.IO;
using iText.Html2pdf;

public static class HtmlToPdf
{
    public static byte[] Convert(string html)
    {
        using var ms = new MemoryStream();
        HtmlConverter.ConvertToPdf(html, ms);
        return ms.ToArray();
    }
}

One static call. The pdfHTML add-on does the CSS parsing, font handling, and page-break logic for you.

Same license, modern rendering

iText 7 plus pdfHTML carries the same AGPL plus paid commercial dual license as iTextSharp 5. Migrating buys you modern CSS support and accessibility compliance. It does not buy you a license escape. If AGPL was the problem, this path does not fix it.

Best for: teams that already have an iText commercial license, want PDF/UA accessibility, and are willing to pay for it.

Path 2: self-host headless Chrome with PuppeteerSharp

For the C# team that wants a real browser doing the rendering, PuppeteerSharp is the.NET answer. It is the official.NET port of Puppeteer and runs a headless Chromium under the hood.

What you get

Modern CSS, including everything Chromium ships. Full JavaScript execution. Web fonts. oklch(). Container queries. Selectable text, vector output, accessible PDFs. The whole modern web.

What you pay for

A Chromium binary in your deploy, somewhere between 150 MB and 250 MB depending on the trim. Memory leaks at sustained concurrency unless you recycle the browser. Zombie processes inside containers if you do not handle SIGTERM correctly. The Apache 2.0 license is a clean win compared to AGPL.

Minimal example

using PuppeteerSharp;

await new BrowserFetcher().DownloadAsync();
await using var browser = await Puppeteer.LaunchAsync(
    new LaunchOptions { Headless = true });
await using var page = await browser.NewPageAsync();

await page.SetContentAsync("<h1>Invoice #1041</h1>");
await page.PdfAsync("invoice.pdf",
    new PdfOptions { Format = PaperFormat.Letter, PrintBackground = true });

For the production patterns (waiting for a selector before capturing, running on Linux containers, scaling concurrency without leaking browser processes), see our deeper PuppeteerSharp HTML-to-PDF tutorial. It is the right next read once you decide this is your path.

Best for: teams comfortable with operational ownership, who want a permissive license, and who do not mind Chromium in the deploy.

Path 3: use a hosted HTML-to-PDF API (the AGPL-free option)

When you cannot accept AGPL, cannot pay the iText commercial price, and do not want Chromium in your deploy, a hosted API is the clean answer. Transformy gives you two rendering engines behind one request: a Chrome engine for modern CSS and JavaScript, and a wkhtmltopdf engine for fast, deterministic invoice-style documents.

When to reach for it

Three signs. Your HTML needs JavaScript and XMLWorker cannot touch it. Your team would rather not own Chromium in production. The AGPL question is a live concern and the commercial license is not in this year's budget.

Minimal C# call

using System.Net.Http;
using System.Net.Http.Headers;
using System.Text;
using System.Text.Json;

using var http = new HttpClient();
http.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue(
    "Bearer", Environment.GetEnvironmentVariable("TRANSFORMY_API_KEY"));

var payload = JsonSerializer.Serialize(new
{
    html = "<h1>Invoice #1041</h1>",
    engine = "chrome",
    wait_for = ".invoice-total",
});

var response = await http.PostAsync(
    "https://api.transformy.io/v1/render",
    new StringContent(payload, Encoding.UTF8, "application/json"));

var result = await response.Content.ReadFromJsonAsync<RenderResult>();
// result.PdfUrl points at the rendered PDF.

public record RenderResult(string PdfUrl);

One authenticated POST, one PDF URL back. The same auth and request shape applies to engine: "wkhtmltopdf" when you want the lighter, faster path for stable invoice templates (the wkhtmltopdf tutorial covers when that engine wins).

Best for: teams that want to skip the license dance and skip Chromium operations entirely.

iTextSharp vs iText 7 vs PuppeteerSharp vs a hosted API

The honest decision table:

Two things to notice. iTextSharp 5 is the only row with "Not officially" in the.NET 8 column. iText 7 and iTextSharp 5 share the same license: migrating to iText 7 buys you modern rendering, not a license escape.

What about iTextSharp. LGPLv2. Core?

For completeness. iTextSharp.LGPLv2.Core is a community-maintained NuGet package that ports the pre-AGPL iText 4 codebase to.NET Core. The license is LGPL v2, which is dramatically more permissive than AGPLv3 (no copyleft-by-network-service trigger). It runs on.NET 8 and.NET 10.

The catch. It does not include XMLWorker. The HTML-to-PDF feature is the part that was added later, after the AGPL switch. So iTextSharp.LGPLv2.Core is useful for basic PDF generation in C# on modern.NET without paying for iText 7, but it is not an iTextSharp HTML-to-PDF replacement. Reach for it when you need to compose PDFs programmatically. Reach for one of the four paths above when you have HTML to convert.

FAQ: iTextSharp HTML to PDF

Is iTextSharp deprecated in 2026?

Yes. The repo at github.com/itext/itextsharp carries the [DEPRECATED] marker on the README. The last release was 5.5.13.5 in January 2026, security fixes only. The official iText project recommends migrating to iText 7+ with the pdfHTML add-on for HTML to PDF.

Does iTextSharp work with.NET 8 or.NET 10?

Not officially. iTextSharp targets.NET Framework 4.6.1 through 4.8.1 and throws compatibility warnings under.NET 8 and.NET 10. The community fork iTextSharp.LGPLv2.Core runs on modern.NET but does not include XMLWorker, so it cannot do HTML to PDF in any practical sense.

What replaced iTextSharp for HTML to PDF in C#?

Three paths. iText 7 with the pdfHTML add-on is the official successor, with modern CSS and PDF/UA accessibility, on the same AGPL plus paid commercial license. PuppeteerSharp is a permissive Apache 2.0 path that runs a real headless Chromium. A hosted HTML-to-PDF API is the option when you do not want AGPL, do not want a commercial license, and do not want Chromium in your deploy.

Is iTextSharp free for commercial use?

Not in most cases. iTextSharp 5+ (every release after December 2009) is dual-licensed under AGPLv3 and a paid commercial license. AGPL triggers on distribution or on operating the application as a network service. SaaS apps, desktop apps, and most corporate customer-facing tools therefore need the commercial license. Internal corporate tools that never leave the company are the rare case AGPL does not bite.

What is XMLWorker and why does it not render modern CSS?

XMLWorker is the HTML parsing component of iTextSharp 5. It was written against a fraction of CSS 2.1 and never got an upgrade because iTextSharp itself stopped receiving feature work after the move to iText 7 in 2017. It does not support flexbox, CSS Grid, media queries, or modern color functions, and it has no JavaScript execution. For modern CSS, you need iText 7 + pdfHTML, PuppeteerSharp, or a hosted Chrome-engine API.

iTextSharp vs iText 7: what is the actual difference?

iText 7 is a clean-room rewrite of the iText library. It has a different API, a proper CSS parser via the pdfHTML add-on, accessibility support, and active maintenance. iTextSharp 5 is frozen. Both carry the same AGPL plus paid commercial dual license, so migrating buys you modern rendering and accessibility, not a different licensing posture.

Conclusion: pick a 2026 path, not a 2016 one

iTextSharp is end-of-life. XMLWorker cannot render modern CSS, modern.NET does not officially support it, and the AGPL license that has always been there is a real constraint for SaaS teams who never noticed. There are three clean paths forward: iText 7 with pdfHTML if you already have a commercial license and want to stay on the iText stack, PuppeteerSharp if you want a permissive license and are comfortable owning Chromium, or a hosted HTML-to-PDF API if you want to skip the license question and the Chromium operations work entirely.

A practical decision path. (1) If you ship an internal.NET Framework tool that never leaves the building and you cannot move off it today, the iTextSharp recipe above will keep working. (2) If you are migrating off iTextSharp and have an iText commercial license, go to iText 7 plus pdfHTML. (3) If you want permissive licensing and can operate Chromium, go to PuppeteerSharp. (4) If neither AGPL nor a Chromium binary in your deploy works for you, call a hosted API.

Render your first PDF on the Transformy free tier with the C# example above. One authenticated POST, one PDF URL back, and no AGPL dance to think about.