DEV Community: IronSoftware

iText / iTextSharp to IronPDF: three steps and you're done

IronSoftware — Mon, 18 May 2026 10:24:00 +0000

The signal was quiet at first. The legacy iTextSharp 5.x package sits on NuGet at version 5.5.13.5, frozen on the .NET Framework, receiving only occasional security fixes. The actively maintained successor — the current itext package (formerly itext7) — has a different API, ships HTML-to-PDF as a separately purchased add-on (itext.pdfhtml), and carries the AGPL or a paid commercial license. Teams using either line face the same choice: stay and absorb the licensing and API cost, or move to a differently-licensed renderer.

This article covers the path to IronPDF specifically. It's a code-first walkthrough — the conceptual parts are short, the working snippets are long. If you're evaluating the jump and want to know exactly what changes, this gets into the details.

The fundamental architecture difference

This is worth surfacing early because it changes what "migration" means here.

Both itext (current line) and iTextSharp (legacy 5.x line) build PDFs by composing objects in code — Document, Paragraph, Table, Cell, and friends. HTML-to-PDF in the current line is handled by the itext.pdfhtml add-on (a separate purchase) and supports a defined CSS subset; it does not execute JavaScript during rendering. The legacy iTextSharp line has HTMLWorker, which supports a small subset of HTML 4 and almost no modern CSS.

IronPDF works primarily as an HTML renderer — you give it HTML/CSS, and Chromium renders it to PDF. It also supports PDF manipulation (merge, split, watermark, etc.).

This means the migration path splits into two tracks:

If you're using iText / iTextSharp to generate PDFs from HTML -> straightforward substitution
If you're using it as a programmatic document builder -> rewrite the generation logic as HTML templates, then render

Track 2 is more work but often produces better results, since HTML/CSS is a more maintainable way to define document layouts than building them programmatically.

This article covers both tracks.

Why migrate (without drama)

Eight reasons teams make this switch:

iTextSharp 5.x is end-of-life — the legacy package receives security fixes only; new development should not target it.
AGPL licensing friction — iText's AGPL license requires that any software distributed with it also be AGPL, unless you purchase a commercial license. Teams with proprietary applications either buy a subscription or move to a differently-licensed library.
pdfHTML is a separate paid add-on — the current itext package does not include HTML-to-PDF; the itext.pdfhtml add-on is sold separately on top of the core itext package.
Subscription-only commercial licensing — iText's commercial license is sold as an annual subscription based on PDF processing volume; a perpetual option is not advertised on the public pricing page.
HTML-to-PDF fidelity — itext.pdfhtml supports a defined CSS subset, not a full browser engine, and does not execute JavaScript at render time. The legacy HTMLWorker covers even less.
API verbosity — building a simple table requires substantial boilerplate. HTML/CSS templates with a renderer library often require less code.
Debugging document layout — debugging a PDF built from programmatic API calls is harder than debugging an HTML template that you can preview in a browser.
Coordinate-system mental shift — iText uses PDF coordinates (bottom-left origin); web developers joining the team have to context-switch every time they touch the layout code.

Comparison table

Aspect	iText / iTextSharp	IronPDF
Focus	Programmatic PDF builder + manipulation	HTML-to-PDF + PDF manipulation
Pricing	AGPL (open source) or commercial subscription	Commercial, perpetual option available
API Style	Document object model — programmatic	HTML renderer + document model
Learning Curve	High (low-level API, PDF coordinate system)	Medium (web-developer friendly)
HTML Rendering	`itext.pdfhtml` add-on (CSS subset, no JS); `HTMLWorker` on legacy 5.x	Chromium-based (full CSS3 + JS)
Page Indexing	1-based	1-based
Thread Safety	Not thread-safe by default	Renderer instance reuse — see async docs
Namespace	`iText.Kernel.Pdf` / `iText.Layout` (current); `iTextSharp.text` (legacy)	`IronPdf`

Note on page indexing: iText uses 1-based page numbers throughout (GetNumberOfPages(), GetPage(n), PdfMerger.Merge(doc, 1, n)). IronPDF's PageCount returns the total page count; specific page-range methods like CopyPages(startIndex, endIndex) operate on indices — audit each call site against the IronPDF API docs rather than assuming the iText convention carries over verbatim.

Migration complexity assessment

Effort by feature

Feature	iText / iTextSharp approach	Effort to migrate
HTML string to PDF	`HtmlConverter.ConvertToPdf()` (current) / `HTMLWorker.Parse()` (legacy)	Low
Programmatic document building	`Document` + `Paragraph` + `Table` API	High — rewrite as HTML template
Merge PDFs	`PdfMerger` (current) / `PdfCopy` (legacy)	Low
Split PDF	Manual page copy	Low
Watermark / stamp	Canvas overlay + `PdfExtGState` (current) / `PdfStamper` (legacy)	Low
Password protection	`WriterProperties.SetStandardEncryption()` (current) / `PdfStamper.SetEncryption()` (legacy)	Low
Form filling	`PdfAcroForm` (current) / `AcroFields` (legacy)	Medium
Digital signatures	`PdfSigner` (current) / `PdfSignatureAppearance` (legacy)	Medium
Reading existing PDF text	`PdfTextExtractor.GetTextFromPage()`	Medium
PDF metadata	`pdfDoc.GetDocumentInfo()` (current) / `PdfReader.Info` (legacy)	Low
Page rotation	`page.GetRotation()` (current) / `PdfReader.GetPageRotation()` (legacy)	Low

Decision matrix

Scenario	Recommendation
Generating PDFs from HTML templates	IronPDF is a natural fit; minimal rewrite
Programmatic PDF construction (complex tables, precise positioning)	Evaluate whether HTML/CSS templates can replace it — often yes
AGPL constraint is the trigger	Compare commercial license terms (iText annual subscription vs IronPDF perpetual option)
Heavy PDF form filling (AcroForms)	Confirm IronPDF form API coverage against your form types

Before you start

Prerequisites

A supported .NET target (IronPDF supports modern .NET; check the IronPDF compatibility matrix for current ranges)
Full HTML template inventory if replacing programmatic PDF building
Browser preview setup for HTML template development

Find iText / iTextSharp references in your codebase

# Find all iText and iTextSharp using statements
rg "using iText\b|using iTextSharp" --type cs -n

# Find library references
rg "iTextSharp|iText\." --type cs -n

# Find Document/PdfWriter patterns (core classes)
rg "PdfWriter|PdfReader|PdfStamper|PdfDocument|PdfMerger" --type cs -n

# Find HTML conversion paths
rg "HtmlConverter|HTMLWorker" --type cs -n -i

# Find form filling paths
rg "PdfAcroForm|AcroFields|SetField" --type cs -n

Remove iText / iTextSharp, install IronPDF

# Remove current iText packages
dotnet remove package itext
dotnet remove package itext.pdfhtml
dotnet remove package itext7
dotnet remove package itext7.pdfhtml

# Remove legacy iTextSharp 5.x if present
dotnet remove package iTextSharp

# Install IronPDF
dotnet add package IronPdf

# Restore
dotnet restore

Quick start migration (3 steps)

Step 1: License configuration

Before (iText — AGPL by default, commercial license loaded via subscription):

using iText.Kernel.Pdf;
using System.IO;

// iText: no license key for AGPL use. Commercial subscription customers
// load a license via the iText licensing add-on (separate package).

After (IronPDF):

using IronPdf;

// Set once at application startup
IronPdf.License.LicenseKey = "YOUR-LICENSE-KEY";
// Guide: https://ironpdf.com/how-to/license-keys/

Step 2: Namespace imports

Before (current itext):

using iText.Kernel.Pdf;
using iText.Layout;
using iText.Layout.Element;
using iText.Layout.Properties;
using iText.Html2pdf;       // requires itext.pdfhtml add-on
using System.IO;

Before (legacy iTextSharp 5.x):

using iTextSharp.text;
using iTextSharp.text.pdf;
using iTextSharp.text.html.simpleparser;
using System.IO;

After:

using IronPdf;
using IronPdf.Rendering;

Step 3: Basic HTML-to-PDF

Before (current iText with pdfHTML add-on):

using iText.Html2pdf;
using System.IO;

class HtmlToPdfExample
{
    static void Main()
    {
        string html = "<h1>Hello World</h1><p>Content here.</p>";
        using var fs = new FileStream("output.pdf", FileMode.Create);
        HtmlConverter.ConvertToPdf(html, fs);
    }
}

After (IronPDF):

using IronPdf;

IronPdf.License.LicenseKey = "YOUR-LICENSE-KEY";

var renderer = new ChromePdfRenderer();
var pdf = renderer.RenderHtmlAsPdf("<h1>Hello World</h1><p>Content here.</p>");
pdf.SaveAs("output.pdf");
// Guide: https://ironpdf.com/how-to/html-string-to-pdf/

API mapping tables

Namespace mapping

iText / iTextSharp	IronPDF	Notes
`iText.Kernel.Pdf` / `iTextSharp.text.pdf`	`IronPdf`	Core PDF operations
`iText.Layout` / `iTextSharp.text`	`IronPdf`	Document model
`iText.Html2pdf` / `iTextSharp.text.html.simpleparser`	N/A	Replaced by Chromium renderer

Core class mapping

iText / iTextSharp class	IronPDF class	Description
`PdfWriter` + `PdfDocument` + `Document`	`ChromePdfRenderer`	PDF generation entry point
`PdfReader`	`PdfDocument.FromFile()`	Open existing PDF
`PdfDocument(reader, writer)` / `PdfStamper`	`PdfDocument` + methods	Modify existing PDF
`PdfMerger` / `PdfCopy`	`PdfDocument.Merge()`	Combine PDFs

Document loading methods

Operation	iText (current)	iTextSharp 5.x	IronPDF
HTML string	`HtmlConverter.ConvertToPdf()`	`HTMLWorker.Parse()`	`renderer.RenderHtmlAsPdf(html)`
URL	Download HTML + convert	Not native	`renderer.RenderUrlAsPdf(url)`
Existing PDF	`new PdfDocument(new PdfReader(path))`	`new PdfReader(path)`	`PdfDocument.FromFile(path)`
From bytes	`new PdfReader(new MemoryStream(bytes))`	Similar	`PdfDocument.FromBinaryData(bytes)`

Page operations

Operation	iText / iTextSharp	IronPDF
Page count	`pdfDoc.GetNumberOfPages()` / `reader.NumberOfPages`	`pdf.PageCount`
Paper size	`PageSize.A4` constant	`ChromePdfRenderOptions.PaperSize`
Margins	`Document.SetMargins()`	`ChromePdfRenderOptions.Margin*`
Page rotation	`page.GetRotation()` / `reader.GetPageRotation(n)`	`pdf.Pages[i].PageRotation`

Merge/split operations

Operation	iText / iTextSharp	IronPDF
Merge	`PdfMerger.Merge()` / `PdfCopy` + `PdfReader` per file	`PdfDocument.Merge(pdf1, pdf2)`
Split	Manual page copy iteration	`pdf.CopyPages(startIndex, endIndex)`

Four complete before/after migrations

1. HTML to PDF

Before (current iText with itext.pdfhtml add-on):

// NuGet: Install-Package itext.pdfhtml
using iText.Html2pdf;
using System.IO;
using System;

class HtmlToPdfMigration
{
    static void Main()
    {
        // pdfHTML supports a defined CSS subset; no JavaScript execution
        string html = @"
            <html><body>
                <h1>Invoice #1234</h1>
                <table border='1' cellpadding='4'>
                    <tr><th>Item</th><th>Price</th></tr>
                    <tr><td>Widget A</td><td>$50.00</td></tr>
                    <tr><td>Widget B</td><td>$75.00</td></tr>
                </table>
                <p><b>Total: $125.00</b></p>
            </body></html>";

        using var fs = new FileStream("invoice.pdf", FileMode.Create);
        HtmlConverter.ConvertToPdf(html, fs);
        Console.WriteLine("Saved: invoice.pdf");
    }
}

After (IronPDF — full CSS3 support, shorter):

using IronPdf;

IronPdf.License.LicenseKey = "YOUR-LICENSE-KEY";

string html = @"
    <html><head><style>
        h1 { color: #333; }
        table { border-collapse: collapse; width: 100%; }
        th, td { border: 1px solid #ccc; padding: 8px; }
        th { background: #f5f5f5; }
    </style></head><body>
        <h1>Invoice #1234</h1>
        <table>
            <tr><th>Item</th><th>Price</th></tr>
            <tr><td>Widget A</td><td>$50.00</td></tr>
            <tr><td>Widget B</td><td>$75.00</td></tr>
        </table>
        <p><strong>Total: $125.00</strong></p>
    </body></html>";

var renderer = new ChromePdfRenderer();
var pdf = renderer.RenderHtmlAsPdf(html);
pdf.SaveAs("invoice.pdf");

2. Merge PDFs

Before (current iText PdfMerger):

// NuGet: Install-Package itext
using iText.Kernel.Pdf;
using iText.Kernel.Utils;
using System;

class MergePdfsExample
{
    static void MergePdfs(string[] inputPaths, string outputPath)
    {
        using var writer = new PdfWriter(outputPath);
        using var pdfDoc = new PdfDocument(writer);
        var merger = new PdfMerger(pdfDoc);

        foreach (string path in inputPaths)
        {
            using var sourcePdf = new PdfDocument(new PdfReader(path));
            merger.Merge(sourcePdf, 1, sourcePdf.GetNumberOfPages());
        }

        Console.WriteLine($"Merged {inputPaths.Length} files to {outputPath}");
    }

    static void Main() => MergePdfs(
        new[] { "part1.pdf", "part2.pdf", "part3.pdf" },
        "merged.pdf"
    );
}

After (IronPDF):

using IronPdf;

IronPdf.License.LicenseKey = "YOUR-LICENSE-KEY";

var merged = PdfDocument.Merge(
    PdfDocument.FromFile("part1.pdf"),
    PdfDocument.FromFile("part2.pdf"),
    PdfDocument.FromFile("part3.pdf")
);
merged.SaveAs("merged.pdf");
// Guide: https://ironpdf.com/how-to/merge-or-split-pdfs/

3. Watermark

Before (current iText — canvas overlay with PdfExtGState):

using iText.Kernel.Pdf;
using iText.Kernel.Pdf.Canvas;
using iText.Kernel.Pdf.Extgstate;
using iText.Kernel.Font;
using iText.IO.Font.Constants;
using System;

class WatermarkExample
{
    static void Main()
    {
        using var reader = new PdfReader("input.pdf");
        using var writer = new PdfWriter("watermarked.pdf");
        using var pdfDoc = new PdfDocument(reader, writer);

        var font = PdfFontFactory.CreateFont(StandardFonts.HELVETICA_BOLD);
        var gs = new PdfExtGState().SetFillOpacity(0.3f);

        for (int i = 1; i <= pdfDoc.GetNumberOfPages(); i++)
        {
            var page = pdfDoc.GetPage(i);
            var pageSize = page.GetPageSize();
            var canvas = new PdfCanvas(page);

            canvas.SaveState()
                  .SetExtGState(gs)
                  .BeginText()
                  .SetFontAndSize(font, 60)
                  .SetTextMatrix(
                      (float)Math.Cos(Math.PI / 4), (float)Math.Sin(Math.PI / 4),
                      -(float)Math.Sin(Math.PI / 4), (float)Math.Cos(Math.PI / 4),
                      pageSize.GetWidth() / 4, pageSize.GetHeight() / 2)
                  .ShowText("CONFIDENTIAL")
                  .EndText()
                  .RestoreState();
        }

        Console.WriteLine("Watermarked: watermarked.pdf");
    }
}

After (IronPDF):

using IronPdf;
using IronPdf.Editing;

IronPdf.License.LicenseKey = "YOUR-LICENSE-KEY";

var pdf = PdfDocument.FromFile("input.pdf");
var stamper = new TextStamper
{
    Text = "CONFIDENTIAL",
    FontColor = "#808080",
    FontSize = 60,
    Opacity = 30,
    Rotation = 45,
    VerticalAlignment = IronSoftware.Drawing.AnchorType.Middle,
    HorizontalAlignment = IronSoftware.Drawing.AnchorType.Middle
};
pdf.ApplyStamp(stamper);
pdf.SaveAs("watermarked.pdf");
// Guide: https://ironpdf.com/how-to/custom-watermark/

4. Password protection

Before (current iText — WriterProperties.SetStandardEncryption):

using iText.Kernel.Pdf;
using System;
using System.Text;

class SecurityExample
{
    static void Main()
    {
        byte[] userPassword  = Encoding.UTF8.GetBytes("readonlyaccess");
        byte[] ownerPassword = Encoding.UTF8.GetBytes("admincontrol");

        var writerProperties = new WriterProperties()
            .SetStandardEncryption(
                userPassword,
                ownerPassword,
                EncryptionConstants.ALLOW_PRINTING,
                EncryptionConstants.ENCRYPTION_AES_128);

        using var reader = new PdfReader("document.pdf");
        using var writer = new PdfWriter("secured.pdf", writerProperties);
        using var pdfDoc = new PdfDocument(reader, writer);

        Console.WriteLine("Encrypted: secured.pdf");
    }
}

After (IronPDF):

using IronPdf;

IronPdf.License.LicenseKey = "YOUR-LICENSE-KEY";

var pdf = PdfDocument.FromFile("document.pdf");
pdf.SecuritySettings.UserPassword  = "readonlyaccess";
pdf.SecuritySettings.OwnerPassword = "admincontrol";
pdf.SecuritySettings.AllowUserCopyPasteContent = true;
pdf.SecuritySettings.AllowUserPrinting = PdfPrintSecurity.FullPrintRights;
pdf.SaveAs("secured.pdf");
// Guide: https://ironpdf.com/how-to/pdf-permissions-passwords/

Critical migration notes

Audit page-index references

iText uses 1-based page numbers throughout — GetNumberOfPages(), GetPage(n), and PdfMerger.Merge(doc, 1, n) all start at 1. IronPDF's API surface is different: PageCount is the total count, and specific page-range methods like CopyPages(startIndex, endIndex) and indexing into pdf.Pages follow IronPDF's own conventions. Don't assume the iText convention carries over verbatim — audit each call site against the IronPDF page-manipulation docs when porting loops.

Document builder → HTML template migration

If your codebase builds PDFs programmatically using Document, Paragraph, Table / PdfPTable, and related classes, migrating to IronPDF means rewriting those as HTML templates. This isn't a mechanical substitution — it's a design change.

A practical approach:

For each PDF type your system generates, create an HTML template (Razor, Liquid, Handlebars — any templating engine works)
Render the HTML template to a string
Pass the string to IronPDF's renderer

The HTML template approach is typically more maintainable and easier to iterate on, but it does require the initial rewrite investment.

AGPL licensing

If AGPL was the migration trigger, confirm IronPDF's commercial license terms cover your distribution model before switching — this is a legal/business decision separate from the technical migration. iText's commercial license is sold as an annual subscription based on PDF volume; IronPDF offers a perpetual option in addition to subscription.

iText form filling (AcroForms)

If your code uses PdfAcroForm (current iText) or AcroFields (legacy iTextSharp) to fill PDF forms, test IronPDF's form-filling API against your specific form types before committing to the migration. Forms are one of the more variable corners of the PDF spec, and behavior differs across renderers.

Performance considerations

Renderer reuse

// Reuse renderer for batch generation
var renderer = new ChromePdfRenderer();
renderer.RenderingOptions.PaperSize = IronPdf.Rendering.PdfPaperSize.A4;

foreach (var template in GetDocumentTemplates())
{
    var html = RenderTemplate(template); // your template engine
    using var pdf = renderer.RenderHtmlAsPdf(html);
    pdf.SaveAs($"doc_{template.Id}.pdf");
}

Async for web applications

// Async pattern for ASP.NET controllers
[HttpGet("generate")]
public async Task<IActionResult> GeneratePdf()
{
    var renderer = new ChromePdfRenderer();
    var html = await _templateEngine.RenderAsync(model);
    var pdf = await renderer.RenderHtmlAsPdfAsync(html);

    return File(pdf.Stream, "application/pdf", "document.pdf");
    // Async guide: https://ironpdf.com/how-to/async/
}

Memory disposal

// PdfDocument implements IDisposable
using var pdf = PdfDocument.FromFile("input.pdf");
// ... operations ...
pdf.SaveAs("output.pdf");
// Disposed at end of block

Edge cases worth flagging

Complex table layouts — iText's programmatic table API gives precise control over cell sizing. HTML/CSS tables in a renderer work differently. Test your most complex table layouts explicitly.
Exact positioning — iText supports absolute PDF coordinates (bottom-left origin). In HTML, absolute positioning is CSS-based (top-left origin). The mental model differs.
Font embedding — both libraries embed fonts differently. Check font rendering in output PDFs, especially with custom fonts.

Migration checklist

Pre-migration

[ ] Classify all PDF generation code: HTML-based vs programmatic document builder
[ ] Find all iText / iTextSharp usages: rg "iText|PdfWriter|PdfStamper|PdfMerger|PdfCopy" --type cs
[ ] Identify form-filling (PdfAcroForm / AcroFields) usage and test IronPDF form API coverage against your forms
[ ] Identify digital signature usage and test IronPDF signing API against your workflow
[ ] Check AGPL licensing impact on your project (legal/business, not technical)
[ ] Inventory HTML templates (if any) for render comparison
[ ] Confirm IronPDF .NET version compatibility for your target framework
[ ] Set up an IronPDF trial license in dev environment

Code migration

[ ] Remove itext, itext.pdfhtml, itext7, iTextSharp NuGet packages
[ ] Add IronPdf NuGet package
[ ] Replace using iText.* / using iTextSharp.* with using IronPdf (and using IronPdf.Editing for stamping)
[ ] Replace HTML-to-PDF (HtmlConverter / HTMLWorker) with ChromePdfRenderer
[ ] Replace PdfMerger / PdfCopy merge pattern with PdfDocument.Merge()
[ ] Replace canvas-overlay watermark / PdfStamper watermark with pdf.ApplyStamp()
[ ] Replace WriterProperties.SetStandardEncryption() / PdfStamper.SetEncryption() with pdf.SecuritySettings
[ ] Audit page-index references (both libraries use 1-based, but mixing collection-style and method-style indexing is a common bug source)
[ ] Rewrite programmatic document builders as HTML templates (scope this separately)
[ ] Add IronPDF license key to config

Testing

[ ] Render each HTML template and compare output
[ ] Test merge on representative document sets
[ ] Test watermark on single-page and multi-page documents
[ ] Test password protection: confirm correct/incorrect credential behavior
[ ] Test form filling if applicable
[ ] Test digital signatures if applicable
[ ] Load test concurrent rendering at expected peak

Post-migration

[ ] Remove iText license file if a commercial subscription was in place
[ ] Remove iText / iTextSharp from dependency list
[ ] Update architecture documentation
[ ] Monitor memory baseline (Chromium renderer vs iText have different profiles)

That's the migration

The hardest part of an iText or iTextSharp migration isn't usually the API mapping — it's the cases where someone spent significant effort building precise document layouts programmatically that now need to be reimplemented as HTML templates. The 1:1 conceptual mapping doesn't exist. That's the honest assessment.

For teams that are primarily HTML-to-PDF (using HtmlConverter or HTMLWorker), the migration is genuinely straightforward. For teams with complex programmatic document construction, budget more time.

Which feature was hardest to replicate in your migration, and why? Particularly interested in teams who had complex table layouts or form-filling requirements — those tend to be where the depth of the feature difference shows up.

Migrating from FO.NET to IronPDF: drop-in replacement guide

IronSoftware — Mon, 18 May 2026 09:23:00 +0000

The FO.NET migration question usually starts with a specific failure: an XSL-FO stylesheet that worked for a decade stops rendering correctly on a new server, or the team discovers FO.NET has had no meaningful updates in over a decade, or a new requirement comes in that FO.NET simply cannot fulfill. XSL-FO is a powerful layout specification, but FO.NET is one of the more obscure implementation choices for .NET projects, and its maintenance trajectory is what it is — the legacy Fonet package on nuget.org was last published in April 2011 targeting .NET Framework 2.0, and the community Fonet.Standard fork hasn't shipped since May 2020.

This article is structured around the troubleshooting path: identifying what's broken, deciding what to migrate, and making the switch to IronPDF systematically. The conceptual gap between XSL-FO and HTML-to-PDF is real and worth understanding before writing any code.

Why Migrate (Without Drama)

Abandonment — FO.NET has no active maintenance. The legacy Fonet NuGet was last published in April 2011 (v1.0.0, .NET Framework 2.0). The Fonet.Standard fork was last published May 2020. .NET runtime changes (especially .NET Core+) may break it silently or loudly.
.NET Core / .NET 5+ compatibility — The original Fonet build targets .NET Framework 2.0. The Fonet.Standard fork targets .NET Standard 2.0 and is also no longer actively developed.
XSL-FO expertise — The team that understood XSL-FO may have left. HTML + CSS is far more accessible to modern .NET developers, and the W3C closed the XSL-FO Working Group in 2013.
Runtime exceptions on upgrade — Upgrading the .NET runtime or OS frequently reveals FO.NET incompatibilities.
Docker/Linux — The legacy build depends on System.Drawing GDI+ APIs that effectively limit it to Windows. Linux containers will fail.
Feature gap — Modern requirements (CSS3 flexbox/grid, JS-rendered charts, modern web font loading) are incompatible with XSL-FO processing.
Tooling — XSL-FO editors and validators are rare. HTML templates can be built and debugged in any browser.
Pipeline complexity — XSLT to XSL-FO to FO.NET to PDF is a multi-step transformation chain. HTML to IronPDF to PDF is one step.
XSL-FO spec maintenance — XSL-FO itself is a stable but aging W3C spec with no further development since 2013.
Error diagnosis — FO.NET errors are often cryptic XML processing exceptions with no actionable message.

Side-by-Side Comparison

Aspect	FO.NET	IronPDF
Focus	XSL-FO processor to PDF	HTML/URL to PDF via Chromium
Maintenance	Abandoned (last legacy release 2011; fork last 2020)	Actively maintained
Pricing	Free (Apache 2.0)	Commercial — see ironpdf.com for current pricing
API Style	XML/stream processing	Simple render methods
Learning Curve	High — XSL-FO is complex	Low for HTML-first workflows
HTML Rendering	Not applicable — XSL-FO input only	Chromium, full CSS3/JS
Page Indexing	N/A	0-based
Thread Safety	Single-threaded by design	`ChromePdfRenderer` reusable
Namespace	`Fonet`, `Fonet.Render.Pdf`	`IronPdf`

Migration Complexity Assessment

Effort by Feature

Feature	Complexity	Notes
XML data to PDF	Medium-High	Pipeline changes; XSL-FO to HTML template conversion
XSL-FO layout to HTML/CSS	High	Significant design work; not a code swap
Tables with complex spans	High	XSL-FO table model maps to HTML table: similar concept, different syntax
Running headers/footers	Medium	XSL-FO `<fo:static-content>` to IronPDF HTML headers
Multi-column layout	High	XSL-FO has explicit multi-column; CSS Multi-column spec differs
Page numbering	Medium	XSL-FO `<fo:page-number>` to IronPDF `{page}` placeholder
Merge output	Low	IronPDF adds first-class merge; FO.NET had no native merge
Password/security	Low	IronPDF adds AES-256, granular permissions; FO.NET only had legacy RC4
Watermark	Medium	IronPDF stamp API; FO.NET required overlay tricks in XSL-FO
Conditional page masters	High	XSL-FO page master sequences to HTML CSS @page

Decision Matrix

Scenario	Recommendation
FO.NET no longer runs on your .NET version	Must migrate
XSL-FO templates are working; team understands them	Lower urgency; validate long-term maintenance plan
New requirements can't be met by XSL-FO	Migrate those requirements to IronPDF
Need Linux container support	Legacy FO.NET will not work; migrate

Troubleshooting Common FO.NET Problems (and Migration Path)

Problem 1: FO.NET Won't Load on .NET 6+

Symptom: System.BadImageFormatException or System.IO.FileNotFoundException when loading the FO.NET DLL.

Root cause: The legacy Fonet build targets .NET Framework 2.0. On .NET Core / .NET 6+, it may not load via Assembly.LoadFrom() or package references. The Fonet.Standard fork targets .NET Standard 2.0 but is itself unmaintained.

Diagnosis:

# Check FO.NET DLL target framework
# On Windows (PowerShell):
[System.Reflection.Assembly]::ReflectionOnlyLoadFrom("Fonet.dll").ImageRuntimeVersion

# Or use ildasm to check:
# ildasm Fonet.dll /text | grep ".ver"

# Check your project target framework:
grep -r "TargetFramework" *.csproj

Migration path: If the DLL won't load, you can't keep FO.NET. The migration is forced.

Problem 2: XSL-FO Rendering Produces Malformed PDF

Symptom: PDF opens but has missing sections, garbled text, or overlapping regions. No exception thrown.

FO.NET debugging approach:

using Fonet;
using Fonet.Render.Pdf;
using System.IO;
using System.Text;
using System.Xml;
using System.Xml.Xsl;

// Typical FO.NET pipeline

// Step 1: Load XML data
var xmlDoc = new XmlDocument();
xmlDoc.Load("data.xml");

// Step 2: Apply XSLT to get XSL-FO
var transform = new XslCompiledTransform();
transform.Load("stylesheet.xsl");
var foString = new StringBuilder();
transform.Transform(xmlDoc, null, new StringWriter(foString));

// Step 3: Pass XSL-FO to FonetDriver
FonetDriver driver = FonetDriver.Make();
using (var outputStream = new FileStream("output.pdf", FileMode.Create))
{
    driver.Render(new StringReader(foString.ToString()), outputStream);
}

Debugging the XSL-FO output directly:

# Validate XSL-FO before FO.NET processes it
# Save the xsl-fo string to file and inspect:
# - Check for unclosed elements
# - Validate against XSL-FO schema if available
# - Look for missing namespace declarations (fo: prefix)

# A common issue: incorrect namespace declaration
# Should be: xmlns:fo="http://www.w3.org/1999/XSL/Format"
grep "xmlns:fo" your_xslfo_output.xml

Migration path: If the XSL-FO renders correctly but FO.NET produces bad PDF, the data and transformation logic is salvageable. The pipeline becomes:

[OLD]: XML -> XSLT -> XSL-FO -> FO.NET -> PDF
[NEW]: XML -> XSLT -> HTML -> IronPDF -> PDF

The key insight: the XML data and the transformation are often good. The output target changes from XSL-FO to HTML.

Problem 3: Missing Fonts in PDF Output

Symptom: FO.NET outputs PDF with fonts substituted or missing.

FO.NET root cause: Font configuration in FO.NET is non-trivial and may involve configuration files pointing to system font directories.

IronPDF approach: Chromium handles font rendering. For custom fonts:

using IronPdf;

// Embed custom fonts via HTML @font-face
string htmlWithFont = @"
<html>
<head>
<style>
@font-face {
    font-family: 'CustomFont';
    src: url('https://your-domain.com/fonts/custom.woff2') format('woff2');
}
body { font-family: 'CustomFont', sans-serif; }
</style>
</head>
<body><p>Custom font text</p></body>
</html>";

var renderer = new ChromePdfRenderer();
using var pdf = renderer.RenderHtmlAsPdf(htmlWithFont);
pdf.SaveAs("output_with_fonts.pdf");

// For local font files, use BaseUrl to serve from local file system:
// renderer.RenderingOptions.BaseUrl = new Uri("file:///path/to/fonts/dir/");

Problem 4: Multi-Page Documents with Page Numbering

Symptom: XSL-FO's <fo:page-number> worked; now need equivalent in IronPDF.

XSL-FO pattern (for context):

<!-- XSL-FO page numbering — becomes HTML headers/footers in IronPDF -->
<fo:static-content flow-name="xsl-region-after">
  <fo:block text-align="center">
    Page <fo:page-number/> of <fo:page-number-citation ref-id="last-page"/>
  </fo:block>
</fo:static-content>

IronPDF HTML header/footer approach:

using IronPdf;

var renderer = new ChromePdfRenderer();

// HTML footer with page number placeholder
renderer.RenderingOptions.HtmlFooter = new HtmlHeaderFooter
{
    HtmlFragment = "<div style='text-align:center; font-size:10px;'>Page {page} of {total-pages}</div>",
    DrawDividerLine = false
};

string html = "<html><body><h1>Multi-page Document</h1></body></html>";
using var pdf = renderer.RenderHtmlAsPdf(html);
pdf.SaveAs("numbered.pdf");
// Docs: https://ironpdf.com/how-to/rendering-options/

Problem 5: Complex Table Layout Differences

Symptom: XSL-FO tables with table-header, table-footer, repeated across pages work in FO.NET but the HTML equivalent doesn't repeat table headers.

Solution in HTML/CSS:

<!-- HTML table headers repeat on page breaks via print CSS -->
<html>
<head>
<style>
  thead { display: table-header-group; }  /* repeat on each page */
  tfoot { display: table-footer-group; }  /* repeat at bottom */
  @media print {
    table { page-break-inside: auto; }
    tr    { page-break-inside: avoid; page-break-after: auto; }
  }
</style>
</head>
<body>
  <table>
    <thead>
      <tr><th>Column A</th><th>Column B</th></tr>
    </thead>
    <tbody>
      <!-- data rows -->
    </tbody>
  </table>
</body>
</html>

IronPDF uses Chromium's print rendering — display: table-header-group is respected.

Before You Start

Find FO.NET References

# Find Fonet / FO.NET references
rg "FonetDriver|Fonet|using Fonet" --type cs -l

# Find XSL-FO pipeline stages
rg "XslCompiledTransform" --type cs                       # XSLT stage
rg "xmlns:fo|fo:root" -g "*.xsl" -g "*.xslt" -g "*.fo"   # XSL-FO templates
rg "xslfo|foDocument|foStream" --type cs                  # FO processing

# Find FO.NET package references in project files
rg "Fonet" -g "*.csproj" -g "*.fsproj" -l

Inventory XSL-FO Stylesheets

# List all XSLT stylesheets that produce XSL-FO output
# (look for xmlns:fo in XSLT outputs)
grep -rl "xmlns:fo=\"http://www.w3.org/1999/XSL/Format\"" . --include="*.xsl"
grep -rl "xmlns:fo=" . --include="*.xslt"

Important: These XSL-FO stylesheets represent significant layout work. If you're migrating to HTML output, you'll be writing equivalent HTML/CSS templates. Factor this effort into your migration plan — it's not a code swap, it's a template rewrite.

Uninstall / Install

# Remove FO.NET reference (either the legacy package or the Standard fork)
dotnet remove package Fonet
dotnet remove package Fonet.Standard

# Install IronPDF
dotnet add package IronPdf

dotnet list package

Quick Start Migration (3 Steps)

Step 1: License

// FO.NET: no license setup (Apache 2.0)
// IronPDF: license before first render
IronPdf.License.LicenseKey = "YOUR-LICENSE-KEY";
// Docs: https://ironpdf.com/how-to/license-keys/

Step 2: Namespace Imports

// Before (FO.NET)
// using Fonet;
// using Fonet.Render.Pdf;

// After
using IronPdf;
// Keep: using System.Xml; using System.Xml.Xsl; — for your data transformation

Step 3: Pipeline Restructure

The core change is the XSLT output target: instead of XSL-FO, your XSLT now produces HTML.

// Before: XSLT -> XSL-FO -> FO.NET -> PDF
// var xslfo = ApplyXslt(xmlData, "to_fo.xsl");   // XSLT to XSL-FO
// FonetDriver.Make().Render(new StringReader(xslfo), outputStream);  // FO.NET renders

// After: XSLT -> HTML -> IronPDF -> PDF
using System.Xml;
using System.Xml.Xsl;
using IronPdf;

IronPdf.License.LicenseKey = "YOUR-LICENSE-KEY";

// Step 1: Transform XML data to HTML (change your XSLT output to HTML)
var transform = new XslCompiledTransform();
transform.Load("to_html.xsl"); // new XSLT targeting HTML output

var xmlDoc = new XmlDocument();
xmlDoc.Load("data.xml");

var htmlWriter = new System.Text.StringBuilder();
transform.Transform(xmlDoc, null, new System.IO.StringWriter(htmlWriter));
string html = htmlWriter.ToString();

// Step 2: IronPDF renders HTML
var renderer = new ChromePdfRenderer();
using var pdf = renderer.RenderHtmlAsPdf(html);
pdf.SaveAs("output.pdf");
// Docs: https://ironpdf.com/how-to/html-string-to-pdf/

API Mapping Tables

Namespace Mapping

FO.NET	IronPDF	Notes
`Fonet`	`IronPdf`	Core namespace
`Fonet.Render.Pdf`	`IronPdf`	PDF rendering options
XSL-FO markup	HTML + CSS	Input format changes
XSLT output method="xml" (FO)	XSLT output method="html"	Stylesheet retarget

Core Class Mapping

FO.NET Class	IronPDF Class	Description
`FonetDriver`	`ChromePdfRenderer`	Main rendering class
`FonetDriver.Make()`	`new ChromePdfRenderer()`	Factory / constructor
`driver.Render(reader, stream)`	`renderer.RenderHtmlAsPdf(html)`	Render trigger
`PdfRendererOptions`	`RenderingOptions` and `SecuritySettings`	Configuration
XSL-FO document (stream)	HTML string	Input type changes
Output stream	`PdfDocument.SaveAs()` / `BinaryData`	Output

Document Loading

Operation	FO.NET	IronPDF
Render XSL-FO stream	`driver.Render(StringReader, FileStream)`	N/A — input changes to HTML
Render HTML string	N/A	`renderer.RenderHtmlAsPdf(html)`
Render URL	Not supported	`renderer.RenderUrlAsPdf(url)`
Load existing PDF	Not supported	`PdfDocument.FromFile(path)`
Load from bytes	Not supported	`PdfDocument.FromBinaryData(bytes)`

Page Operations

Operation	FO.NET	IronPDF
Running headers	`fo:static-content flow-name="xsl-region-before"`	`RenderingOptions.HtmlHeader`
Running footers	`fo:static-content flow-name="xsl-region-after"`	`RenderingOptions.HtmlFooter`
Page size	`fo:simple-page-master` attributes	`RenderingOptions.PaperSize`
Margins	`fo:simple-page-master` attributes	`RenderingOptions.Margin*`

Merge / Split

Operation	FO.NET	IronPDF
Merge multiple docs	Not supported natively	`PdfDocument.Merge(a, b)`
Split	Not supported natively	`pdf.CopyPages(start, end)`

Four Complete Before/After Migrations

1. XML Data to PDF (Core Pipeline)

Before (XSL-FO pipeline with FonetDriver):

using System.IO;
using System.Text;
using System.Xml;
using System.Xml.Xsl;
using Fonet;
using Fonet.Render.Pdf;

class Program
{
    static void Main()
    {
        // Step 1: Load XML data
        var xmlDoc = new XmlDocument();
        xmlDoc.Load("invoice_data.xml");

        // Step 2: XSLT transforms XML -> XSL-FO
        var transform = new XslCompiledTransform();
        transform.Load("invoice_to_fo.xsl"); // XSL-FO stylesheet

        var foOutput = new StringBuilder();
        transform.Transform(xmlDoc, null, new StringWriter(foOutput));
        string xslfo = foOutput.ToString();

        // Step 3: FonetDriver renders XSL-FO to PDF
        FonetDriver driver = FonetDriver.Make();
        driver.Options = new PdfRendererOptions
        {
            Title  = "Invoice",
            Author = "Company",
        };
        using (var outputStream = new FileStream("invoice.pdf", FileMode.Create))
        {
            driver.Render(new StringReader(xslfo), outputStream);
        }
    }
}

After (HTML pipeline with IronPDF):

using System.Xml;
using System.Xml.Xsl;
using IronPdf;

class Program
{
    static void Main()
    {
        IronPdf.License.LicenseKey = "YOUR-LICENSE-KEY";
        // Docs: https://ironpdf.com/how-to/license-keys/

        // Step 1: Load XML data (unchanged)
        var xmlDoc = new XmlDocument();
        xmlDoc.Load("invoice_data.xml");

        // Step 2: XSLT now produces HTML instead of XSL-FO
        // (requires rewriting invoice_to_fo.xsl -> invoice_to_html.xsl)
        var transform = new XslCompiledTransform();
        transform.Load("invoice_to_html.xsl");

        var htmlOutput = new System.Text.StringBuilder();
        transform.Transform(xmlDoc, null, new System.IO.StringWriter(htmlOutput));
        string html = htmlOutput.ToString();

        // Step 3: IronPDF renders HTML to PDF
        var renderer = new ChromePdfRenderer();
        renderer.RenderingOptions.PaperSize = IronPdf.Rendering.PdfPaperSize.A4;
        // Docs: https://ironpdf.com/how-to/rendering-options/

        using var pdf = renderer.RenderHtmlAsPdf(html);
        pdf.MetaData.Title = "Invoice";
        pdf.MetaData.Author = "Company";
        pdf.SaveAs("invoice.pdf");
    }
}

2. Merge PDFs

Before (FO.NET — no native merge):

// FonetDriver has no built-in merge. The typical workaround is to
// render each XSL-FO source to its own PDF, then merge with a separate
// PDF library. There is no Fonet.Merge or equivalent API in either the
// legacy Fonet package or the Fonet.Standard fork.
//
// var driver = FonetDriver.Make();
// using (var s1 = new FileStream("a.pdf", FileMode.Create))
//     driver.Render(new StringReader(xslfoA), s1);
// using (var s2 = new FileStream("b.pdf", FileMode.Create))
//     driver.Render(new StringReader(xslfoB), s2);
// // Then merge a.pdf + b.pdf with a different library

After (IronPDF):

using IronPdf;

class MergeSample
{
    static void Main()
    {
        IronPdf.License.LicenseKey = "YOUR-LICENSE-KEY";

        using var docA = PdfDocument.FromFile("doc_a.pdf");
        using var docB = PdfDocument.FromFile("doc_b.pdf");

        using var merged = PdfDocument.Merge(docA, docB);
        merged.SaveAs("merged.pdf");
        // Docs: https://ironpdf.com/how-to/merge-or-split-pdfs/
    }
}

3. Watermark

Before (FO.NET — watermark via XSL-FO overlay markup):

<!-- XSL-FO watermark via fo:block-container with absolute positioning -->
<!-- FO.NET implements a subset of XSL-FO inherited from a pre-1.0 Apache
     FOP build. Z-index, opacity, and absolute positioning may behave
     inconsistently or be ignored depending on the construct. -->
<fo:block-container position="fixed" top="0" left="0"
    width="21cm" height="29.7cm" z-index="-1">
  <fo:block text-align="center" padding-top="10cm" opacity="0.3"
      font-size="60pt" color="gray">DRAFT</fo:block>
</fo:block-container>

After (IronPDF):

using IronPdf;
using IronPdf.Editing;

class WatermarkSample
{
    static void Main()
    {
        IronPdf.License.LicenseKey = "YOUR-LICENSE-KEY";

        using var pdf = PdfDocument.FromFile("input.pdf");

        var stamper = new TextStamper
        {
            Text = "DRAFT",
            FontSize = 50,
            Opacity = 30,
            Rotation = 45,
            VerticalAlignment = VerticalAlignment.Middle,
            HorizontalAlignment = HorizontalAlignment.Center
        };

        pdf.ApplyStamp(stamper);
        pdf.SaveAs("watermarked.pdf");
        // Docs: https://ironpdf.com/how-to/stamp-text-image/
    }
}

4. Password Protection

Before (FO.NET — basic password encryption via PdfRendererOptions):

// FonetDriver supports PDF encryption through PdfRendererOptions:
// setting UserPassword or OwnerPassword triggers encryption. The
// encryption scheme is the legacy 40/128-bit RC4 inherited from
// early Apache FOP — no AES-256, no digital signatures, no granular
// permission flags (print / copy / annotate).
using Fonet;
using Fonet.Render.Pdf;
using System.IO;

FonetDriver driver = FonetDriver.Make();
driver.Options = new PdfRendererOptions
{
    Title         = "Confidential Report",
    Author        = "Company Name",
    UserPassword  = "user123",
    OwnerPassword = "owner456",
};
driver.Render(new StringReader(xslFo),
    new FileStream("secured.pdf", FileMode.Create));

After (IronPDF):

using IronPdf;
using IronPdf.Security;

class SecuritySample
{
    static void Main()
    {
        IronPdf.License.LicenseKey = "YOUR-LICENSE-KEY";

        using var pdf = PdfDocument.FromFile("input.pdf");

        // Docs: https://ironpdf.com/how-to/pdf-permissions-passwords/
        pdf.SecuritySettings.UserPassword = "user123";
        pdf.SecuritySettings.OwnerPassword = "owner456";
        pdf.SecuritySettings.AllowUserPrinting = IronPdf.Security.PdfPrintSecurity.FullPrintRights;

        pdf.SaveAs("secured.pdf");
    }
}

Critical Migration Notes

XSL-FO Is a Different Input Model

This is not a drop-in library swap. FO.NET takes XSL Formatting Objects as input. IronPDF takes HTML. If your pipeline generates XSL-FO via XSLT, you have two options:

Option A: Retarget XSLT to HTML output

Change your XSLT xsl:output method="xml" to method="html"
Rewrite layout rules from XSL-FO vocabulary (fo:block, fo:table, fo:simple-page-master) to HTML + CSS equivalents
Higher up-front effort but results in maintainable HTML templates

Option B: Add an XSL-FO to HTML transformation step

Use a separate XSLT stylesheet that translates XSL-FO into HTML
Less upfront work but adds complexity and a second layer to debug

Neither option is a configuration change. Budget engineering time for template work.

FO.NET Feature Parity

FO.NET implements a subset of the XSL-FO specification (it forks an early pre-1.0 Apache FOP). Some XSL-FO features may be silently unsupported and you may not know it (the rendering just drops those features). Compare your migrated HTML output against the original PDF output visually — don't assume 1:1 fidelity in either direction.

Running Headers and Footers

XSL-FO's fo:static-content with flow-name="xsl-region-before" / "xsl-region-after" is a first-class feature. IronPDF uses RenderingOptions.HtmlHeader and HtmlFooter with {page} and {total-pages} placeholders. For complex headers (images, company logos, variable data), embed them in the HTML header fragment.

Page Master Sequences

XSL-FO's fo:page-sequence-master with different masters for first page, odd/even pages has no direct equivalent in IronPDF's HTML model. Use CSS @page :first, @page :left, @page :right selectors — Chromium supports the standard CSS Paged Media selectors that map to these patterns.

Performance Considerations

FO.NET is a synchronous, single-threaded processor. IronPDF is Chromium-based with async support. For high-volume document generation:

// Async render — preferred for server contexts
public async Task<byte[]> GenerateAsync(string html)
{
    using var pdf = await _renderer.RenderHtmlAsPdfAsync(html);
    return pdf.BinaryData;
    // Docs: https://ironpdf.com/how-to/async/
}

For batch document generation (parallel):

using IronPdf;

// Singleton renderer — initialize once
private static readonly ChromePdfRenderer _renderer = new ChromePdfRenderer();

// Parallel render
// Docs: https://ironpdf.com/examples/parallel/
var tasks = documents.Select(async doc =>
{
    string html = TransformToHtml(doc.XmlData, doc.XsltPath);
    using var pdf = await _renderer.RenderHtmlAsPdfAsync(html);
    return (doc.Id, pdf.BinaryData);
});

var results = await Task.WhenAll(tasks);

Cold start note: IronPDF initializes Chromium on first render. FO.NET's cold start was lighter. Plan a warm-up render in your application startup.

Migration Checklist

Pre-Migration

[ ] Confirm FO.NET is truly broken / unsupported on your target runtime
[ ] Inventory all XSL-FO stylesheets (grep -rl "xmlns:fo" . --include="*.xsl")
[ ] Inventory all XSLT transformations that feed FO.NET
[ ] Evaluate Option A (retarget XSLT to HTML) vs. Option B (XSL-FO to HTML XSLT)
[ ] Estimate template rewrite effort — this is likely the bulk of the migration
[ ] Confirm IronPDF .NET target compatibility
[ ] Set up IronPDF license in all environments
[ ] Test IronPDF on your Linux container base image
[ ] Review rendering options for paper size, margin, header/footer

Code Migration

[ ] Rewrite XSL-FO stylesheet(s) as HTML/CSS (or retarget XSLT)
[ ] Replace Fonet / Fonet.Standard package reference with IronPdf
[ ] Replace FonetDriver.Render() with renderer.RenderHtmlAsPdf()
[ ] Add IronPdf.License.LicenseKey configuration
[ ] Register ChromePdfRenderer as singleton in DI
[ ] Port fo:static-content headers/footers to RenderingOptions.HtmlHeader/Footer
[ ] Port page size / margin configuration to RenderingOptions
[ ] Add using disposal to all PdfDocument instances
[ ] Replace merge step (if any) with PdfDocument.Merge()
[ ] Add watermark/security where needed

Testing

[ ] Visual comparison: FO.NET output vs. IronPDF output for each document type
[ ] Test repeated table headers on multi-page tables
[ ] Test running headers and footers with page numbers
[ ] Test complex tables with merged cells
[ ] Test documents with images (embedded + URL-referenced)
[ ] Test custom fonts
[ ] Test under concurrent load
[ ] Memory stability test — 30 min sustained render

Post-Migration

[ ] Remove Fonet / Fonet.Standard package references
[ ] Archive XSL-FO stylesheets (don't delete — they document layout intent)
[ ] Update Dockerfile/deployment for IronPDF Linux deps
[ ] Warm up renderer at application startup
[ ] Document the pipeline change for future maintainers

That's the Migration

FO.NET migrations are the most conceptually complex in this series because the input model changes — not just the library. The combination of an abandoned tool, .NET Core incompatibility, and an input format that most modern .NET developers don't know makes this feel more daunting than it is. The XSL-FO to HTML/CSS translation is well-understood territory; most layout concepts map directly, and the CSS Print specification covers the print-specific features you need.

The best thing to do with your old XSL-FO stylesheets: keep them as reference documentation. They describe the layout intent precisely. Use them to guide your HTML/CSS equivalents, page by page.

Technical question for comments: Has anyone automated XSL-FO to HTML/CSS conversion, even partially? An XSLT that translates common XSL-FO constructs to HTML equivalents would save migration time for large stylesheets. Has anyone built or found something like this?

PDFmyURL vs IronPDF: an unbiased look for .NET teams

IronSoftware — Fri, 15 May 2026 16:14:00 +0000

Picture a familiar architectural fork: a .NET service that generates compliance PDFs containing customer account data, transaction histories, and PII. A hosted HTML-to-PDF API like PDFmyURL is tempting — no install, one HTTP call, a PDF back. But the same call ships the document body across the public internet to a third-party processor, which immediately raises questions a security review will ask: where does the data land, who can audit it, and is there a DPA/BAA in place that the regulators will accept?

That fork shows up across industries with data residency or compliance constraints — healthcare (HIPAA), finance (SOX, PCI-DSS), government (FedRAMP), and EU GDPR scope generally. The question this article tries to answer is narrow: when does a cloud HTML-to-PDF API like PDFmyURL fit the use case, and when do you want a local-rendering library like IronPDF running inside your own process? Both are legitimate tools; the choice is about where the bytes are allowed to go.

Understanding IronPDF

IronPDF processes all PDF generation locally within your application's process space. HTML content, data, and generated PDFs never leave your infrastructure. The library embeds a Chromium rendering engine that executes entirely on your servers—whether on-premises Windows/Linux boxes, private cloud VMs, or containerized deployments. Network calls occur only when rendering URLs that your application explicitly requests, not as part of the library's operation.

This on-premises architecture addresses compliance requirements by default: data never transits to third parties, processing happens within your security boundary, and service availability depends only on your infrastructure. For applications with data governance requirements, this architectural difference often determines eligibility before any feature comparison begins. See the HTML to PDF tutorial for implementation patterns.

Key Limitations of PDFmyURL

Product Status

PDFmyURL has operated as a cloud conversion service since 2008, providing a stable REST API for HTML-to-PDF conversion. The service offers tiered subscription plans based on monthly conversion volume. API stability is good; breaking changes are rare.

Missing Capabilities

Data Sovereignty Compliance: Every HTML document you convert is transmitted to PDFmyURL's servers for processing. This creates compliance issues for:

GDPR (data transfer outside EU)
HIPAA (PHI transmission to third parties)
PCI-DSS (cardholder data handling)
SOX (financial data controls)
FedRAMP (government data restrictions)

Offline Operation: The service requires internet connectivity for every conversion. Air-gapped environments, private networks without external access, and scenarios requiring offline functionality cannot use cloud APIs.

Direct PDF Manipulation: PDFmyURL converts URLs/HTML to PDFs. It doesn't provide APIs for merging existing PDFs, extracting text, adding watermarks to pre-generated documents, or modifying PDFs programmatically. Each operation requires a separate tool.

Technical Issues

Network Dependency: Every conversion is an HTTP request to external servers. This introduces:

Network latency (roundtrip times)
Potential network failures (timeouts, connectivity issues)
Rate limiting (API quotas)
Service availability dependency (uptime outside your control)

Subscription Cost Model: Cloud services charge per conversion or monthly volume tiers. High-volume applications may encounter usage costs that scale with business success, creating unpredictable operational expenses.

Data Transfer Overhead: Large HTML documents with embedded images or complex layouts require uploading all content to remote servers. This consumes bandwidth and adds latency proportional to payload size.

Support Status

PDFmyURL provides email support and an API reference at https://pdfmyurl.com/html-to-pdf-api. Response time and SLA tiers vary by plan; check the current pricing/SLA page on the vendor site for specifics.

Architecture Problems

The cloud API model creates an architectural coupling where your application's PDF generation capability depends on:

External service availability
Network connectivity
API quota limits
Third-party infrastructure performance
Data transmission latency

For applications where PDF generation is a critical path operation (invoicing, reporting, document delivery), these dependencies introduce failure modes beyond your infrastructure control.

Feature Comparison Overview

Aspect	PDFmyURL	IronPDF
Current Status	Active (cloud SaaS)	Active (on-premises library)
HTML/CSS Support	Server-side rendering engine	Chromium-based engine
Rendering Output	Server-rendered HTML to PDF	Matches Chrome print preview
Installation	HTTP calls against pdfmyurl.com/api	NuGet package + first-run Chromium download (~150 MB)
Support	Email support, tier-dependent	Commercial support per IronPDF license
Operational Control	Depends on service availability	Runs inside your process

Code Comparison - Checklist Style

✅ Task: Convert HTML String to PDF

PDFmyURL Implementation:

using System;
using System.Collections.Generic;
using System.Net.Http;
using System.Threading.Tasks;

public class PdfMyUrlConverter
{
    private readonly HttpClient _httpClient;
    private readonly string _license;

    public PdfMyUrlConverter(string license)
    {
        _license = license;
        _httpClient = new HttpClient
        {
            Timeout = TimeSpan.FromMinutes(2)
        };
    }

    public async Task<byte[]> ConvertHtmlStringAsync(string htmlContent)
    {
        // Form-encoded POST against the single REST endpoint;
        // response body is the PDF binary.
        var form = new FormUrlEncodedContent(new[]
        {
            new KeyValuePair<string, string>("license", _license),
            new KeyValuePair<string, string>("html", htmlContent),
            new KeyValuePair<string, string>("page_size", "A4"),
            new KeyValuePair<string, string>("orientation", "portrait")
        });

        try
        {
            var response = await _httpClient.PostAsync("https://pdfmyurl.com/api", form);
            response.EnsureSuccessStatusCode();
            return await response.Content.ReadAsByteArrayAsync();
        }
        catch (HttpRequestException ex)
        {
            // HTTP-level failure: invalid license, rate limit, service unavailable, network error
            throw new InvalidOperationException(
                "PDFmyURL conversion failed - inspect status code / network", ex);
        }
        catch (TaskCanceledException)
        {
            throw new TimeoutException("PDF conversion exceeded HttpClient timeout");
        }
    }
}

Checklist - Trade-offs:

HTML payload is sent to PDFmyURL's servers for rendering — confirm acceptable under your data handling policy
Requires outbound HTTPS to pdfmyurl.com on every conversion
Per-call latency includes network round-trip plus server-side render time
Per-plan rate limits and monthly quotas apply; verify against the current tier on the vendor pricing page
HTTP-level errors surface as status codes and exception messages rather than typed render exceptions
Default HttpClient timeouts may need tuning for large payloads

IronPDF Implementation:

using IronPdf;
using System.Threading.Tasks;

public class LocalPdfGenerator
{
    private readonly ChromePdfRenderer _renderer;

    public LocalPdfGenerator()
    {
        IronPdf.License.LicenseKey = "YOUR-LICENSE-KEY";
        _renderer = new ChromePdfRenderer();
    }

    public async Task<byte[]> ConvertHtmlStringAsync(string htmlContent)
    {
        var pdf = await _renderer.RenderHtmlAsPdfAsync(htmlContent);
        return pdf.BinaryData;
    }
}

Checklist - Advantages:

✅ Data Privacy: All processing local, data never leaves infrastructure
✅ No Network Dependency: Works offline, air-gapped, private networks
✅ Low Latency: No network roundtrip overhead
✅ No Rate Limiting: Limited only by hardware resources
✅ Rich Error Handling: Detailed exceptions with stack traces
✅ Predictable Performance: Depends only on server hardware

✅ Task: Convert URL to PDF

PDFmyURL Implementation:

public async Task<byte[]> ConvertUrlAsync(string url)
{
    // PDFmyURL margin parameters: top/bottom/left/right + unit (mm/in/cm/pt/px)
    var form = new FormUrlEncodedContent(new[]
    {
        new KeyValuePair<string, string>("license", _license),
        new KeyValuePair<string, string>("url", url),
        new KeyValuePair<string, string>("page_size", "Letter"),
        new KeyValuePair<string, string>("top", "10"),
        new KeyValuePair<string, string>("bottom", "10"),
        new KeyValuePair<string, string>("unit", "mm")
    });

    var response = await _httpClient.PostAsync("https://pdfmyurl.com/api", form);
    response.EnsureSuccessStatusCode();
    return await response.Content.ReadAsByteArrayAsync();
}

Checklist - Considerations:

The fetch goes your server → PDFmyURL → target URL, so the target URL must be reachable from PDFmyURL's network
Authenticated URLs typically need cookies or headers passed as API parameters — verify what the PDFmyURL parameter set supports for your tier
Intranet, localhost, and VPN-only URLs are not reachable from a public cloud renderer
JavaScript wait timing is controlled by the javascript_time parameter rather than by event hooks

IronPDF Implementation:

public async Task<byte[]> ConvertUrlAsync(string url)
{
    var pdf = await _renderer.RenderUrlAsPdfAsync(url);
    return pdf.BinaryData;
}

public async Task<byte[]> ConvertAuthenticatedUrlAsync(string url, string cookieHeader)
{
    _renderer.RenderingOptions.CustomCssUrl = "https://yourcdn.com/print.css";
    _renderer.RenderingOptions.CustomHttpHeaders.Add("Cookie", cookieHeader);

    var pdf = await _renderer.RenderUrlAsPdfAsync(url);
    return pdf.BinaryData;
}

Checklist - Advantages:

✅ Single Network Hop: Direct fetch from your server to target URL
✅ Full Authentication Control: Pass cookies, headers, certificates programmatically
✅ Private URLs: Can convert localhost, intranet, VPN-protected URLs
✅ JavaScript Control: Configurable JS execution, wait conditions

✅ Task: Batch Convert Multiple HTMLs

PDFmyURL Implementation:

public async Task<byte[][]> BatchConvertAsync(string[] htmlContents)
{
    var tasks = new List<Task<byte[]>>();

    foreach (var html in htmlContents)
    {
        // Each conversion is a separate API call
        tasks.Add(ConvertHtmlStringAsync(html));
    }

    // All requests go to external service
    return await Task.WhenAll(tasks);
}

Checklist - Batch Considerations:

Each call counts against the plan's monthly quota and per-tier concurrency limits
Multiple large HTML payloads consume outbound bandwidth on every batch
Cost scales linearly with batch size on metered tiers
A single slow render does not block siblings, but overall throughput is bounded by the service

IronPDF Implementation:

public async Task<byte[]> BatchConvertAndMergeAsync(string[] htmlContents)
{
    // Process all in parallel on local hardware
    var tasks = htmlContents.Select(html => 
        _renderer.RenderHtmlAsPdfAsync(html));

    var pdfs = await Task.WhenAll(tasks);

    // Merge into single PDF
    var merged = PdfDocument.Merge(pdfs);
    return merged.BinaryData;
}

Checklist - Advantages:

✅ No Rate Limits: Parallelism limited only by CPU/memory
✅ No Network Overhead: All processing local
✅ No Cost Scaling: Process millions without per-unit charges
✅ Built-in Merge: Combine results without additional tools

✅ Task: Add Watermarks to Generated PDFs

PDFmyURL Implementation:

public async Task<byte[]> ConvertWithWatermarkAsync(string htmlContent, string watermarkText)
{
    // Watermark behavior is controlled via API parameters on the same /api endpoint.
    // Check the live API reference at https://pdfmyurl.com/html-to-pdf-api for the
    // current parameter set and any tier-related availability.
    var form = new FormUrlEncodedContent(new[]
    {
        new KeyValuePair<string, string>("license", _license),
        new KeyValuePair<string, string>("html", htmlContent),
        new KeyValuePair<string, string>("watermark_text", watermarkText),
        new KeyValuePair<string, string>("watermark_style", "diagonal")
    });

    var response = await _httpClient.PostAsync("https://pdfmyurl.com/api", form);
    response.EnsureSuccessStatusCode();
    return await response.Content.ReadAsByteArrayAsync();
}

Checklist - Watermark Considerations:

Confirm watermark parameter support and tier availability against the current API reference
Text, position, and opacity are controlled via parameters; check the documented ranges
Image-watermark support depends on the parameter set exposed by the service
The /api endpoint converts source HTML/URL to PDF; modifying an existing PDF is not part of the conversion endpoint

IronPDF Implementation:

public async Task<byte[]> ConvertWithWatermarkAsync(string htmlContent, string watermarkText)
{
    var pdf = await _renderer.RenderHtmlAsPdfAsync(htmlContent);

    // Add text watermark to all pages
    pdf.ApplyWatermark("<h1>" + watermarkText + "</h1>", 
        opacity: 50, 
        rotation: 45, 
        verticalAlignment: IronPdf.Editing.VerticalAlignment.Middle);

    return pdf.BinaryData;
}

public async Task<byte[]> AddImageWatermarkAsync(byte[] existingPdfBytes, string imagePath)
{
    var pdf = PdfDocument.FromBinaryData(existingPdfBytes);

    // Image watermark
    pdf.ApplyImageWatermark(imagePath,
        opacity: 30,
        verticalOffset: -100);

    return pdf.BinaryData;
}

Checklist - Advantages:

✅ Full Customization: Text, images, HTML watermarks
✅ Post-Processing: Add watermarks to any existing PDF
✅ Precise Control: Position, opacity, rotation, per-page options
✅ No API Tiers: All features available in library

✅ Task: Handle Sensitive Financial Data

Cloud API model (PDFmyURL) — questions to answer with your compliance team:

Does the conversion involve PII / PHI / cardholder data leaving your security boundary?
What processing jurisdiction is documented in the vendor's DPA?
Are data residency guarantees offered at the tier you would purchase?
Is a BAA or equivalent contractual instrument available for your regulator?
Where is the audit trail stored, and how long is it retained?
What is the documented data deletion / retention SLA?

If any of those questions does not have an acceptable answer for your data class, the cloud-API path is likely off the table regardless of feature parity — that is an organizational call, not a technical one.

On-premises library model (IronPDF) — what changes:

Processing happens inside your application's process; HTML and generated PDFs stay on your infrastructure
Processing jurisdiction equals wherever you deploy the host
Data residency is whatever your hosting choice is
No third-party data sharing introduced by the PDF step itself
Audit trail and retention are under your control
Data deletion is governed by your own storage policy

For detailed HTML rendering and security options, see the HTML string to PDF guide.

API Mapping Reference

PDFmyURL Concept	IronPDF Equivalent	Notes
HTTP POST to /api	ChromePdfRenderer methods	REST API vs. library calls
license parameter	IronPdf.License.LicenseKey	One-time setup vs. per-request
html parameter	RenderHtmlAsPdf(string)	String content directly
url parameter	RenderUrlAsPdf(string)	Same concept
page_size parameter	RenderingOptions.PaperSize	Enum vs. string
orientation parameter	RenderingOptions.PaperOrientation	Typed property
top/bottom/left/right + unit	RenderingOptions.MarginTop etc. (mm)	Margins are typed numeric properties in IronPDF
HTTP response body	PdfDocument.BinaryData	Bytes returned directly
API quota limits	Hardware limitations	No artificial throttling
Subscription tiers	License types	Per-deployment vs. per-use
Network timeout	Local processing time	No network overhead
Service uptime	Application uptime	Same availability tier

Comprehensive Feature Comparison

Feature	PDFmyURL	IronPDF
Architecture
Processing location	Cloud (third-party servers)	On-premises (your infrastructure)
Data transmission	All content to external service	Local only
Network requirement	Required for every conversion	Optional (for URL fetching)
Offline operation	No	Yes
Compliance
Data sovereignty	Data leaves boundary	Data stays local
GDPR compliance	Complex (data transfer)	Straightforward (no transfer)
HIPAA compliance	Requires BAA (if available)	Native (on-premises)
Air-gapped deployment	Not supported	Fully supported
HTML Conversion
HTML string to PDF	Yes	Yes
URL to PDF	Yes	Yes
HTML file to PDF	Via upload	Yes (direct file access)
Modern CSS support	Server-side rendering (W3C compliant per vendor docs)	Chromium-based engine
JavaScript execution	Yes (`javascript_time` wait param)	Yes (configurable render delay)
PDF Operations
Merge PDFs	Not part of the conversion endpoint	Yes (`PdfDocument.Merge`)
Split PDFs	Not part of the conversion endpoint	Yes
Extract text	Not part of the conversion endpoint	Yes
Watermarks	Via API parameters; verify tier availability	Built-in (`ApplyWatermark`)
Digital signatures	Not part of the conversion endpoint	Yes (`PdfSignature`)
Performance
Latency	Network RT + processing	Processing only
Batch processing	API rate limits	Hardware limits
Concurrent operations	Depends on tier/quota	Depends on resources
Caching	Vendor-side caching not documented as a guarantee	Application-controlled
Development
.NET integration	HttpClient/WebClient against `/api`; optional `PDFmyURL.NET.dll`	Native NuGet package (`IronPdf`)
Async support	`HttpClient.PostAsync`	Sync and async (`RenderHtmlAsPdfAsync` etc.)
Error handling	HTTP status codes / `WebException` / `HttpRequestException`	Typed exceptions (`IronPdfRenderingException`, etc.)
Type safety	Stringly-typed form parameters	Strongly typed `RenderingOptions`
Operational
Cost model	Monthly subscription tiers	Per-license (perpetual option available)
Scaling	Bounded by plan tier and vendor capacity	Bounded by your own hardware
Service dependency	External SaaS on the critical path	Runs in your process
Support	Email, tier-dependent	Commercial support per IronPDF license

Installation Comparison

PDFmyURL Setup:

# Option 1: Use HttpClient directly
dotnet add package System.Net.Http

# Option 2: Use official wrapper (if available)
# Download PDFmyURL.NET.dll from vendor site

using System.Net.Http;

var client = new HttpClient();
// Make REST API calls with API key

IronPDF Setup:

dotnet add package IronPdf

using IronPdf;

IronPdf.License.LicenseKey = "YOUR-LICENSE-KEY";

var renderer = new ChromePdfRenderer();
var pdf = await renderer.RenderHtmlAsPdfAsync("<h1>Hello</h1>");

Deployment Checklist Comparison

PDFmyURL Deployment Checklist:

[ ] Verify API key is configured securely
[ ] Ensure outbound HTTPS connectivity to pdfmyurl.com
[ ] Configure HTTP client timeouts appropriately
[ ] Implement retry logic for network failures
[ ] Monitor API quota usage
[ ] Review data transmission policies with legal/compliance
[ ] Test network latency from production environment
[ ] Plan for service outages (fallback strategy?)
[ ] Evaluate costs at expected volume
[ ] Confirm acceptable use policy compliance

IronPDF Deployment Checklist:

[ ] Install NuGet package
[ ] Set license key in application startup
[ ] Ensure sufficient disk space (~200MB for library)
[ ] Verify .NET version compatibility
[ ] Configure memory limits for high-volume scenarios
[ ] Test on target OS (Windows/Linux/macOS)
Configure custom Chrome executable path
Set up load balancing if needed

When to Stay with PDFmyURL / When IronPDF is Better

Consider staying with PDFmyURL if:

You have zero infrastructure and want someone else to manage PDF generation
Your HTML content contains no sensitive or regulated data
Conversion volume is low and occasional (not business-critical)
Offline operation is never required
Data sovereignty is not a concern
Network latency is acceptable for your use case
You prefer operational costs over capital expenses

IronPDF becomes necessary when:

Data contains PII, PHI, financial data, or regulated information
Compliance requires on-premises processing (GDPR, HIPAA, SOX, FedRAMP)
Air-gapped or private network deployment
PDF generation is business-critical (cannot depend on external service)
High-volume conversion where per-use costs become prohibitive
Low-latency requirements (milliseconds matter)
Offline or occasionally-connected scenarios
Need full PDF manipulation (merge, split, extract, modify existing PDFs)
Want architectural control over PDF generation infrastructure

Conclusion

PDFmyURL is a straightforward cloud API for HTML-to-PDF conversion that removes infrastructure management for teams comfortable sending document content to an external processor. For public content, marketing materials, or non-sensitive document generation, the model is a real deployment shortcut: no libraries to install, no servers to maintain, just HTTP calls that return PDFs. It typically works well in low-volume scenarios where data sensitivity is low and outbound network dependency is acceptable.

The architectural fit changes when the application handles regulated data or needs to be operationally independent. A cloud API by definition transmits the source document to a third party, which can be incompatible with HIPAA, PCI-DSS, or GDPR scope unless the right DPA/BAA is in place. Even outside regulated workloads, the external dependency means your PDF step shares an availability budget with another company's service.

IronPDF takes the opposite trade-off: rendering happens inside your own process, so the source HTML and the generated PDF stay within your security boundary. The library bundles a Chromium engine, runs locally on Windows/Linux/macOS, and removes the network from the conversion path itself. For applications where PDF generation is on the critical path rather than an occasional feature, local rendering keeps that step under your own SLAs.

For teams evaluating cloud vs. on-premises: Have data privacy regulations or service dependency concerns already eliminated cloud API options from consideration, or does your architecture permit external processing with appropriate contractual safeguards?

Related resources:

HTML to PDF Tutorial - Complete guide to on-premises HTML rendering
ChromePdfRenderer API Documentation - Detailed method reference for local processing

Gnostice PDFOne .NET vs IronPDF: side by side for .NET

IronSoftware — Fri, 15 May 2026 13:13:00 +0000

The legacy PDFOne.NET NuGet package is now marked deprecated (last release 24.1.60, July 1, 2024), and Gnostice now directs new work to the Gnostice.DocumentStudio.* package family. For teams currently on PDFOne .NET, this is a natural inflection point — a Gnostice-to-Gnostice move to Document Studio is itself a migration, so it is worth re-evaluating the broader PDF library landscape at the same time. PDFOne .NET served as a coordinate-based PDF creation and manipulation library — teams built documents by specifying exact positions, drawing text blocks, and manually calculating layouts.

IronPDF takes a fundamentally different approach: HTML and CSS define document structure, with a Chrome rendering engine handling layout calculations automatically. This architectural distinction affects development velocity, maintenance overhead, and the types of documents each library handles efficiently. The comparison below focuses on measurable characteristics—API surface area, code volume, and workflow patterns—that impact project timelines and long-term maintainability.

Understanding IronPDF

IronPDF centers on HTML-to-PDF conversion using an integrated Chromium rendering engine. Development teams leverage existing HTML, CSS, and JavaScript skills rather than learning PDF coordinate systems. The library supports modern web standards: CSS Grid, Flexbox, custom fonts, responsive layouts, and JavaScript execution before rendering.

Beyond HTML rendering, IronPDF provides standard PDF operations through a streamlined API: merging documents, splitting files, extracting text/images, form handling, digital signatures, and encryption. The library targets .NET Framework 4.6.2+, .NET Core 3.1+, and .NET 6-10 with consistent cross-platform behavior. For comprehensive rendering options, see HTML to PDF Conversion Tutorial.

Architectural Constraints of Gnostice PDFOne .NET

Product Status

PDFOne .NET is now in legacy maintenance — the PDFOne.NET NuGet package's last release is 24.1.60 (July 1, 2024), and the vendor recommends Gnostice.DocumentStudio.* packages for new work. Existing PDFOne .NET licenses remain functional, but teams may want to verify what feature updates and .NET version coverage are planned against the vendor's current roadmap before starting new projects on it.

Missing Capabilities

PDFOne .NET does not ship native HTML-to-PDF conversion. Document generation requires manual coordinate calculations for every text block, image, and shape. Teams build custom layout helpers or accept rigid, code-heavy document structures. Dynamic content from databases or user input means recalculating positions programmatically.

Technical Trade-offs

Coordinate-based APIs make layout changes propagate. Adding a single line of text to a header typically means adjusting Y-coordinates for every subsequent element. Multi-column layouts, tables with dynamic row counts, and page breaks across long content are application-level concerns. Text wrapping, font metrics, and overflow handling sit with the developer.

Support Status

With PDFOne .NET in legacy maintenance, Gnostice support traffic increasingly points new customers toward Document Studio .NET. Teams maintaining PDFOne .NET applications should plan for an eventual Gnostice-to-Document-Studio or Gnostice-to-alternative move.

Architecture

The library's design reflects pre-HTML5 document generation patterns. PDF coordinates originate from bottom-left corners (PostScript convention), which can create cognitive overhead for developers more familiar with top-left origin systems. There is no CSS styling, no responsive breakpoint model, and no separation of content from presentation — every document change is a code change.

Feature Comparison Overview

Feature	Gnostice PDFOne .NET	IronPDF
Current Status	Legacy (PDFOne.NET deprecated; last release 24.1.60, Jul 2024)	Active with continuous updates
HTML Support	None natively	Chromium-based rendering engine
Layout Model	Manual coordinate drawing	CSS-driven layout
Installation	`PDFOne.NET` NuGet (deprecated)	`IronPdf` NuGet
Support	Vendor redirects new work to Document Studio .NET	Live chat, email, tickets
Successor Path	`Gnostice.DocumentStudio.*` packages	Continues as `IronPdf`

Code Comparison: Efficiency Metrics

The following sections compare document generation workflows, measuring code verbosity, maintenance overhead, and adaptability to requirement changes.

Gnostice PDFOne .NET — Creating a Simple Invoice

// NuGet: Install-Package PDFOne.NET (deprecated)
using Gnostice.PDFOne;
using Gnostice.PDFOne.Graphics;
using System;
using System.Drawing;

public class PdfOneInvoiceGenerator
{
    public static void CreateInvoice()
    {
        try
        {
            // Initialize PDF document
            PDFDocument document = new PDFDocument();
            document.Open();
            PDFPage page = document.Pages.Add();

            // Font objects per text style
            PDFFont titleFont = new PDFFont(PDFStandardFont.Helvetica, 24);
            PDFFont bodyFont = new PDFFont(PDFStandardFont.Helvetica, 12);
            PDFFont boldFont = new PDFFont(PDFStandardFont.Helvetica, 14);

            // Manual coordinate calculations (origin: bottom-left)
            // Page height is ~792 points (11 inches at 72 DPI)
            double yPosition = 750; // Start near top

            // Helper: build and draw a text element at (x, y)
            void Draw(string text, PDFFont font, double x, double y)
            {
                var element = new PDFTextElement
                {
                    Text = text,
                    Font = font,
                    Color = Color.Black
                };
                element.Draw(page, x, y);
            }

            Draw("Invoice #12345", titleFont, 50, yPosition);
            yPosition -= 30;

            Draw($"Date: {DateTime.Now:yyyy-MM-dd}", bodyFont, 50, yPosition);
            yPosition -= 20;

            Draw("Customer: Acme Corporation", bodyFont, 50, yPosition);
            yPosition -= 20;
            Draw("Address: 123 Business St", bodyFont, 50, yPosition);
            yPosition -= 40;

            // Table header (manual column tracking)
            Draw("Item", bodyFont, 50, yPosition);
            Draw("Quantity", bodyFont, 250, yPosition);
            Draw("Price", bodyFont, 350, yPosition);
            Draw("Total", bodyFont, 450, yPosition);
            yPosition -= 20;

            // Line items — each requires manual positioning
            Draw("Professional Services", bodyFont, 50, yPosition);
            Draw("40", bodyFont, 250, yPosition);
            Draw("$150.00", bodyFont, 350, yPosition);
            Draw("$6,000.00", bodyFont, 450, yPosition);
            yPosition -= 20;

            Draw("Consulting", bodyFont, 50, yPosition);
            Draw("10", bodyFont, 250, yPosition);
            Draw("$200.00", bodyFont, 350, yPosition);
            Draw("$2,000.00", bodyFont, 450, yPosition);
            yPosition -= 30;

            // Total
            Draw("Total: $8,000.00", boldFont, 350, yPosition);

            // Save document
            document.Save("invoice_pdfone.pdf");
            document.Close();
            Console.WriteLine("Invoice created: invoice_pdfone.pdf");
        }
        catch (Exception ex)
        {
            Console.WriteLine($"Error: {ex.Message}");
        }
    }
}

Performance & Maintainability Metrics:

Lines of code: 64 lines for basic invoice
Manual Y-coordinate calculations: 12 explicit position updates
Font objects created: 4 instances requiring disposal
Table column alignment: Manual calculation for each column
Adding one new line item: Adjust 8+ subsequent Y-coordinates
Responsive layout support: None (fixed positions)
Change request impact: High (coordinate cascade effect)

Technical limitations:

No text wrapping—long strings overflow page boundaries
No automatic page breaks for multi-page documents
Font size changes require recalculating all subsequent positions
Dynamic table row counts need complex loop logic with position tracking
RTL languages (Arabic, Hebrew) require custom text rendering
No CSS styling or separation of content from presentation

IronPDF — Creating a Simple Invoice

using IronPdf;
using System;

public class IronPdfInvoiceGenerator
{
    public static void CreateInvoice()
    {
        IronPdf.License.LicenseKey = "YOUR-LICENSE-KEY";

        var renderer = new ChromePdfRenderer();

        var htmlContent = $@"
        <!DOCTYPE html>
        <html>
        <head>
            <style>
                body {{ font-family: Arial; padding: 40px; }}
                h1 {{ font-size: 24px; margin-bottom: 20px; }}
                .info {{ margin: 10px 0; font-size: 12px; }}
                table {{ width: 100%; border-collapse: collapse; margin-top: 30px; }}
                th {{ background: #f0f0f0; padding: 10px; border-bottom: 2px solid #000; text-align: left; }}
                td {{ padding: 10px; border-bottom: 1px solid #ddd; }}
                .total {{ font-size: 14px; font-weight: bold; margin-top: 20px; text-align: right; }}
            </style>
        </head>
        <body>
            <h1>Invoice #12345</h1>
            <div class='info'>Date: {DateTime.Now:yyyy-MM-dd}</div>
            <div class='info'>Customer: Acme Corporation</div>
            <div class='info'>Address: 123 Business St</div>

            <table>
                <thead>
                    <tr>
                        <th>Item</th>
                        <th>Quantity</th>
                        <th>Price</th>
                        <th>Total</th>
                    </tr>
                </thead>
                <tbody>
                    <tr>
                        <td>Professional Services</td>
                        <td>40</td>
                        <td>$150.00</td>
                        <td>$6,000.00</td>
                    </tr>
                    <tr>
                        <td>Consulting</td>
                        <td>10</td>
                        <td>$200.00</td>
                        <td>$2,000.00</td>
                    </tr>
                </tbody>
            </table>

            <div class='total'>Total: $8,000.00</div>
        </body>
        </html>";

        var pdf = renderer.RenderHtmlAsPdf(htmlContent);
        pdf.SaveAs("invoice_ironpdf.pdf");

        Console.WriteLine("Invoice created: invoice_ironpdf.pdf");
    }
}

Performance & Maintainability Metrics:

Lines of code: 42 lines for same invoice (34% less code)
Manual coordinate calculations: 0 (CSS handles layout)
Font management: Automatic via CSS
Table rendering: Native HTML <table> with automatic alignment
Adding one new line item: Insert single <tr> element (no position recalculation)
Responsive layout: Built-in CSS media queries and flexible layouts
Change request impact: Low (modify HTML/CSS independently of logic)

For production templates with Razor views or external CSS files, see CSHTML to PDF Tutorial.

Gnostice PDFOne .NET — Merging PDFs with Form Preservation

// NuGet: Install-Package PDFOne.NET (deprecated)
using Gnostice.PDFOne;
using Gnostice.PDFOne.Document;
using System;

public class PdfOneMerger
{
    public static void MergePdfsWithForms()
    {
        try
        {
            // Load source documents
            PDFDocument doc1 = new PDFDocument();
            doc1.Load("form_part1.pdf");

            PDFDocument doc2 = new PDFDocument();
            doc2.Load("form_part2.pdf");

            // Create destination and append each source
            PDFDocument mergedDoc = new PDFDocument();
            mergedDoc.Open();
            mergedDoc.Append(doc1);
            mergedDoc.Append(doc2);

            mergedDoc.Save("merged_forms.pdf");

            // Explicit cleanup of each document
            doc1.Close();
            doc2.Close();
            mergedDoc.Close();

            Console.WriteLine("Merge completed");
        }
        catch (Exception ex)
        {
            Console.WriteLine($"Merge error: {ex.Message}");
        }
    }
}

Workflow notes:

Each source document is opened, appended, and closed explicitly
Form-field name collisions across the appended documents are the developer's responsibility to detect and rename — confirm against your AcroForm field set
Three PDFDocument instances need explicit Close() to release resources

IronPDF — Merging PDFs with Form Preservation

using IronPdf;
using System;
using System.Collections.Generic;

public class IronPdfMerger
{
    public static void MergePdfsWithForms()
    {
        IronPdf.License.LicenseKey = "YOUR-LICENSE-KEY";

        var docs = new List<PdfDocument>
        {
            PdfDocument.FromFile("form_part1.pdf"),
            PdfDocument.FromFile("form_part2.pdf")
        };

        var merged = PdfDocument.Merge(docs);
        merged.SaveAs("merged_forms.pdf");

        Console.WriteLine("Merge completed");
    }
}

Performance & Maintainability Metrics:

Automatic form field conflict resolution
Single method call handles all merge logic
Automatic resource management
Preserves bookmarks, annotations, and metadata

Gnostice PDFOne .NET — Extracting Text from Multi-Page Document

// NuGet: Install-Package PDFOne.NET (deprecated)
using Gnostice.PDFOne;
using Gnostice.PDFOne.Document;
using System;
using System.Text;

public class PdfOneTextExtractor
{
    public static void ExtractAllText()
    {
        try
        {
            PDFDocument document = new PDFDocument();
            document.Load("report.pdf");

            var extractedText = new StringBuilder();
            int pageCount = document.Pages.Count;

            // PDFOne page indices are typically 1-based
            for (int pageIndex = 1; pageIndex <= pageCount; pageIndex++)
            {
                string pageText = document.GetPageText(pageIndex);

                extractedText.AppendLine($"--- Page {pageIndex} ---");
                extractedText.AppendLine(pageText);
                extractedText.AppendLine();
            }

            System.IO.File.WriteAllText("extracted.txt", extractedText.ToString());

            document.Close();
            Console.WriteLine($"Extracted text from {pageCount} pages");
        }
        catch (Exception ex)
        {
            Console.WriteLine($"Extraction error: {ex.Message}");
        }
    }
}

Workflow notes:

Manual per-page iteration required to assemble the document text
Page indices are 1-based (vs. 0-based in IronPDF) — easy off-by-one when porting code
Column layouts and table structure are not preserved in the linear text output
Non-standard or embedded fonts can affect text decoding fidelity

IronPDF — Extracting Text from Multi-Page Document

using IronPdf;
using System;

public class IronPdfTextExtractor
{
    public static void ExtractAllText()
    {
        IronPdf.License.LicenseKey = "YOUR-LICENSE-KEY";

        var pdf = PdfDocument.FromFile("report.pdf");
        string allText = pdf.ExtractAllText();

        System.IO.File.WriteAllText("extracted.txt", allText);
        Console.WriteLine("Text extracted successfully");
    }
}

Performance Characteristics:

Single method handles all pages
Optimized memory usage for large documents
Maintains reading order across complex layouts
Built-in encoding normalization

For more details on PDF manipulation operations, see IronPDF PDF Creation Guide.

API Mapping Reference

Gnostice PDFOne Operation	IronPDF Equivalent
`new PDFDocument(); doc.Load(path)`	`PdfDocument.FromFile(path)`
`document.Pages.Add()`	HTML rendering creates pages automatically
`PDFTextElement.Draw(page, x, y)`	HTML elements and CSS styling
Manual coordinate calculations	CSS layout engine
`doc.Append(other)`	`PdfDocument.Merge(pdf1, pdf2)`
`doc.GetPageText(i)` (1-based)	`pdf.ExtractAllText()` / `pdf.ExtractTextFromPage(i)` (0-based)
Manual form field creation	`CreatePdfFormsFromHtml` option
`doc.Save(path); doc.Close()`	`pdf.SaveAs(path)`
Not available	`ChromePdfRenderer.RenderHtmlAsPdf()`
Not available	`ChromePdfRenderer.RenderUrlAsPdf()`
Not available	JavaScript execution before PDF generation
Not available	Responsive CSS rendering
`doc.SetEncryption(...)`	`pdf.SecuritySettings.UserPassword = "..."`

Comprehensive Feature Comparison

Status & Support

Feature	Gnostice PDFOne .NET	IronPDF
Current Development Status	Legacy maintenance (last NuGet release Jul 2024)	Active
Successor Product	`Gnostice.DocumentStudio.*` packages	N/A
.NET 6+ Support	Verify against vendor matrix	Yes
.NET Core Support	Yes (legacy)	Yes (.NET Core 3.1+)
.NET Framework Support	4.6.2+	4.6.2+
Official Documentation	Available; PDFOne section in maintenance	Comprehensive
Support Channels	Vendor redirects new work to Document Studio	Live chat, email, tickets
Future Updates	Direction is Document Studio .NET	Continuous delivery

Content Creation

Feature	Gnostice PDFOne .NET	IronPDF
HTML to PDF	Not supported	Native Chrome engine
Coordinate-Based Drawing	Primary method	Alternative API available
URL to PDF	Not supported	`RenderUrlAsPdf()`
Template-Based Generation	Manual code	HTML templates
Dynamic Content Layouts	Requires custom logic	CSS Flexbox, Grid
Text Wrapping	Manual calculation	Automatic
Multi-Column Layouts	Custom implementation	CSS columns or Grid
Responsive Design	Not supported	CSS media queries

PDF Operations

Feature	Gnostice PDFOne .NET	IronPDF
Merge PDFs	Yes (manual iteration)	Yes (single method)
Split PDFs	Yes	Yes
Extract Text	Yes (page-by-page)	Yes (optimized)
Extract Images	Yes	Yes
Form Field Creation	Yes (manual)	From HTML forms
Form Data Filling	Yes	Yes
Annotations	Yes	Yes
Digital Signatures	Yes	Yes
Encryption	Yes	Yes
Page Manipulation	Yes	Yes

Code Complexity Metrics

Metric	Gnostice PDFOne .NET	IronPDF
Basic Invoice (LOC)	64 lines	42 lines (34% reduction)
Coordinate Calculations	Manual (frequent)	None (CSS-based)
Font Management	Explicit creation	CSS declarations
Table Generation	Manual drawing	HTML `<table>`
Dynamic Content	Complex (position tracking)	Simple (data binding)
Maintenance Overhead	High (coordinate dependencies)	Low (declarative layouts)

Known Trade-offs

Product-Specific Considerations

Gnostice PDFOne .NET:

PDFOne.NET package is in legacy maintenance; new work is directed to Gnostice.DocumentStudio.*
Moving forward on Gnostice means migrating to Document Studio (a different API surface)
Coordinate-based API; layout changes propagate through subsequent positions
No native HTML rendering — text wrapping, overflow, and page breaks are application-level concerns
Font-metric handling sits with the developer for precise layouts
AcroForm field-name collisions during multi-document merges are the developer's responsibility to resolve

IronPDF:

Initial Chromium engine startup adds a one-time warm-up cost (amortized in long-running processes)
Linux deployments may require libgdiplus for certain image operations
Docker containers should be sized to accommodate the bundled Chromium

Installation Comparison

Gnostice PDFOne .NET Installation (Legacy)

# PDFOne.NET is deprecated on NuGet (last release 24.1.60, Jul 2024)
Install-Package PDFOne.NET

# Current Gnostice direction for new work:
# dotnet add package Gnostice.DocumentStudio.WinForms

Configuration:

using Gnostice.PDFOne;

// License key for PDFOne (set via the static PDFOne class)
Gnostice.PDFOne.PDFOne.LicenseKey = "YOUR-GNOSTICE-LICENSE";

Migration Notice:
Teams on PDFOne .NET should evaluate Document Studio .NET (Gnostice's current product line) or alternative PDF libraries for future projects.

IronPDF Installation

# NuGet Package Manager
Install-Package IronPdf

# .NET CLI
dotnet add package IronPdf

Configuration:

using IronPdf;

// Optional license configuration
IronPdf.License.LicenseKey = "YOUR-LICENSE-KEY";

Performance Benchmark Summary

Based on common document generation scenarios:

Operation	PDFOne .NET (Coordinate-Based)	IronPDF (HTML-Based)
Simple invoice (3 items)	~64 LOC	~42 LOC
Complex report (50 items, tables)	~400+ LOC	~150 LOC
Development time (initial)	~8 hours	~3 hours
Change request (add field)	Adjust 10-20 coordinates	Modify HTML template
Multi-page document handling	Custom pagination logic	Automatic page breaks
Maintenance burden	High (coordinate cascade)	Low (CSS separation)

Note: Metrics based on typical development workflows. Actual performance varies by team experience and document complexity.

Conclusion

Gnostice PDFOne .NET served as a traditional PDF generation library, emphasizing precise control over document structure through coordinate-based APIs. For teams with specific requirements around low-level PDF manipulation or applications already on PDFOne, the library has provided reliable functionality. The PDFOne.NET package is now in legacy maintenance on NuGet, and Gnostice directs new development to the Gnostice.DocumentStudio.* product line.

The coordinate-based approach, while offering fine-grained control, comes with maintenance overhead. Layout changes typically require recalculating positions for subsequent elements. Complex tables, multi-column layouts, and responsive content demand custom logic that HTML/CSS engines handle automatically. Development time often goes into font metrics, text wrapping, and page-break logic — infrastructure concerns that modern rendering engines abstract away.

IronPDF's HTML-based approach can reduce code volume substantially for typical document generation tasks (the invoice example above is about a third shorter). Maintenance overhead drops further because HTML templates separate content from presentation. Adding a header, resizing a table, or changing fonts is a CSS change, not coordinate recalculations across the codebase. For teams building .NET applications where PDF generation is a feature rather than the core business, that architectural difference often translates to faster iteration and lower long-term maintenance costs.

With PDFOne .NET in legacy maintenance and Document Studio .NET representing a different API surface, teams already face a migration decision. IronPDF's HTML-first design aligns with the web skills most .NET teams already have, which can shorten the learning curve when evaluating alternatives.

What percentage of your PDF generation code involves manual positioning versus content definition? Share your experience with coordinate-based vs. template-based document workflows.

Related Resources:

PdfiumViewer vs IronPDF: a technical breakdown for 2026

IronSoftware — Fri, 15 May 2026 12:12:00 +0000

Viewer control or headless generation? It is one of the first architectural forks a .NET team hits when PDF requirements start expanding. PdfiumViewer is built for the first answer — a WinForms/WPF control that wraps Google's PDFium and renders pages to the screen, no browser dependency, native binaries shipped via separate NuGet packages. The moment the roadmap adds "generate invoices from data" or "produce reports server-side," that architecture stops carrying the workload, and a second library has to join the project — or replace it.

PdfiumViewer is a WinForms and WPF control for displaying PDF documents in desktop applications, built on Google's PDFium library (the same engine Chrome uses for PDFs). The original pvginkel/PdfiumViewer repository was archived on 2019-08-02 and the last NuGet release (2.13.0) shipped on 2017-11-06, so the library still works for the cases it was designed for but is not receiving updates from the original maintainer. Community forks such as bezzad/PdfiumViewer and PdfiumViewer.Updated continue some development for newer .NET targets — APIs and features can vary between forks. The library exposes a PdfRenderer control for low-level page rendering, a PdfViewer control with built-in toolbar, zoom, and navigation, plus page-level text extraction via PdfDocument.GetPdfText(int page). It does not generate PDFs from HTML, URLs, or templates — that is outside its scope.

Understanding IronPDF

IronPDF is a PDF generation and manipulation library, not a viewer control. The core workflow is creating PDFs from HTML using a Chromium rendering engine, so the output tracks what Chrome would print. IronPDF covers the document lifecycle: generate from HTML, URLs, or files; manipulate (merge, split, forms, signatures, encryption); extract content (text, images, metadata); and print to physical printers. It does not ship a WinForms/WPF viewer UI control — that is intentionally outside its scope. IronPDF runs on .NET Framework 4.6.2+, .NET Core 3.1+, and modern .NET releases, with cross-platform support for Windows, Linux, macOS, Docker, and common cloud environments. Installation is a single NuGet package with embedded native dependencies.

Key Limitations of PdfiumViewer

Product Status

Upstream archived: pvginkel/PdfiumViewer was marked read-only on 2019-08-02; last NuGet release (2.13.0) is from 2017-11-06
Community forks: multiple versions exist (bezzad/PdfiumViewer, PdfiumViewer.Updated, others) with different features and APIs
Windows-focused: original docs reference Windows XP through 8; modern OS coverage varies by fork

Missing Capabilities

No PDF generation from HTML, URLs, or templates
No server-side or headless document creation as a primary use case (the library is designed around UI controls)
No PDF manipulation beyond viewing (no merge, split, edit, watermarks)
No programmatic form filling or extraction
No digital signatures or encryption APIs
Text extraction is page-level only: PdfDocument.GetPdfText(int page) returns raw page text with no per-word coordinates, no layout reconstruction, and no OCR for image-only pages

Technical Considerations

Synchronous load and render: PdfDocument.Load and Render run on the calling thread, which can freeze WinForms/WPF UI for large documents unless dispatched off the UI thread
Native DLL dependency: requires platform-specific pdfium.dll deployment via PdfiumViewer.Native.* packages
Memory profile: documents are loaded for viewer display rather than streamed for backend processing
Limited async surface: most operations are synchronous
Fork compatibility: code written for the original may need adjustment on community forks

Architecture

Desktop-oriented: tightly coupled to WinForms/WPF and System.Drawing, which is Windows-only on .NET 6+
Viewer-first design: no headless generation pipeline
Native binary management: cross-platform deployment requires platform-specific PDFium binaries

Feature Comparison Overview

Aspect	PdfiumViewer	IronPDF
Upstream status	Archived (community forks exist)	Active, commercial product
HTML support	None (viewer/renderer only)	HTML5/CSS3/JS via Chromium
Primary focus	Page display and rasterization	PDF generation and manipulation
Installation	Multi-package with native DLLs	Single NuGet, embedded native
Support model	Community-driven via fork repos	Commercial vendor support
Target runtimes	.NET Framework / fork-dependent	.NET Framework 4.6.2+ through modern .NET, cross-platform

Code Comparison

PdfiumViewer — Load and Display PDF in WinForms

using PdfiumViewer;
using System;
using System.Windows.Forms;

namespace DesktopPdfViewer
{
    public partial class MainForm : Form
    {
        private PdfRenderer pdfRenderer;

        public MainForm()
        {
            InitializeComponent();

            // Step 1: Add PdfRenderer control to form
            // Typically done in designer, shown here programmatically
            pdfRenderer = new PdfRenderer
            {
                Dock = DockStyle.Fill
            };
            this.Controls.Add(pdfRenderer);
        }

        private void LoadPdfButton_Click(object sender, EventArgs e)
        {
            try
            {
                // Step 2: Load PDF from file (synchronous call on the caller thread)
                using (var pdfDocument = PdfDocument.Load(@"C:\Documents\report.pdf"))
                {
                    // Step 3: Assign the document to the renderer control for display
                    pdfRenderer.Load(pdfDocument);

                    Console.WriteLine($"Loaded {pdfDocument.PageCount} pages.");
                }
            }
            catch (Exception ex)
            {
                MessageBox.Show($"Failed to load PDF: {ex.Message}", "Error");
            }
        }

        protected override void OnFormClosing(FormClosingEventArgs e)
        {
            // Step 4: Cleanup
            pdfRenderer?.Dispose();
            base.OnFormClosing(e);
        }
    }
}

Technical notes:

Synchronous load: PdfDocument.Load() runs on the calling thread; large files can block the UI unless dispatched off the UI thread
Document loaded for display: not optimized for streamed backend processing
Desktop-oriented: built around WinForms/WPF controls and System.Drawing, not designed for ASP.NET Core or headless services
No generation capability: cannot create PDFs from data, templates, or HTML — that is outside the library's scope
Fork API differences: method signatures may differ between community forks; check the docs for the fork you choose
Native DLL required: pdfium.dll must be deployed via the PdfiumViewer.Native.* packages

IronPDF — Generate PDF from HTML String

using IronPdf;

IronPdf.License.LicenseKey = "YOUR-LICENSE-KEY";

var htmlContent = @"
<html>
<body style='font-family: Arial; margin: 40px;'>
    <h1>Quarterly Report</h1>
    <p>Revenue: $500,000</p>
    <p>Generated: {DateTime.Now:yyyy-MM-dd}</p>
</body>
</html>";

var renderer = new ChromePdfRenderer();
var pdf = renderer.RenderHtmlAsPdf(htmlContent);
pdf.SaveAs("quarterly-report.pdf");

Performance notes:
Chromium engine renders HTML in ~200-500ms for typical single-page documents. For batch scenarios (100+ PDFs), IronPDF supports async/await and parallel rendering. The HTML string to PDF guide covers optimization techniques like caching, image embedding, and resource management.

PdfiumViewer — Extract Page as Bitmap

using PdfiumViewer;
using System.Drawing;
using System.Drawing.Imaging;
using System.IO;

namespace PdfThumbnailGenerator
{
    class Program
    {
        static void Main(string[] args)
        {
            try
            {
                using (var pdfDocument = PdfDocument.Load("contract.pdf"))
                {
                    // Render the first page to a bitmap at 96 DPI.
                    // Signature: Render(pageIndex, dpiX, dpiY, forPrinting)
                    // Some community forks expose alternative overloads; check
                    // the documentation for the fork you depend on.
                    using (var bitmap = pdfDocument.Render(0, 96, 96, false))
                    {
                        bitmap.Save("thumbnail.png", ImageFormat.Png);
                    }

                    Console.WriteLine("Thumbnail created.");
                }
            }
            catch (Exception ex)
            {
                Console.WriteLine($"Error: {ex.Message}");
            }
        }
    }
}

Technical notes:

Synchronous rendering: each Render call runs on the calling thread
Per-page calls: rendering N pages typically means N individual Render calls
Bitmap memory: high-DPI renders consume significant memory (Letter size at 300 DPI is roughly a 25 MB uncompressed bitmap)
Output format: bitmap only — no vector output or re-embedding into a PDF
System.Drawing.Common dependency: Windows-only on .NET 6+, which constrains where the same code can run

IronPDF — Generate and Manipulate Multi-Page PDF

using IronPdf;
using System.Linq;

IronPdf.License.LicenseKey = "YOUR-LICENSE-KEY";

var pageHtmlTemplates = Enumerable.Range(1, 10).Select(i =>
    $"<h1>Page {i}</h1><p>Content for page {i}</p>");

var renderer = new ChromePdfRenderer();
var pdf = renderer.RenderHtmlAsPdf(string.Join("<div style='page-break-after: always;'></div>", pageHtmlTemplates));

// Add watermark to all pages
pdf.ApplyWatermark("<div style='opacity: 0.3;'>DRAFT</div>");

// Extract specific pages
var subset = pdf.CopyPages(0, 4);  // First 5 pages
subset.SaveAs("contract-summary.pdf");

Performance notes:
Bulk HTML rendering is faster than per-page approaches—IronPDF's Chromium engine processes page-break directives efficiently. Typical 10-page document with simple content renders in ~1 second. HTML to PDF tutorial demonstrates advanced layout techniques (CSS Grid, Flexbox, print media queries).

PdfiumViewer — Search Text via Page-Level Extraction

using PdfiumViewer;
using System;
using System.Text;

class Program
{
    static void Main(string[] args)
    {
        using (var pdfDocument = PdfDocument.Load("legal-document.pdf"))
        {
            string searchTerm = "indemnification";
            int totalMatches = 0;

            var sb = new StringBuilder();
            for (int i = 0; i < pdfDocument.PageCount; i++)
            {
                // GetPdfText returns the raw text of a single page —
                // no per-word coordinates, no layout reconstruction,
                // and no OCR for image-only pages.
                string pageText = pdfDocument.GetPdfText(i);
                sb.AppendLine($"--- Page {i + 1} ---");
                sb.AppendLine(pageText);

                int idx = 0;
                while ((idx = pageText.IndexOf(searchTerm, idx, StringComparison.OrdinalIgnoreCase)) >= 0)
                {
                    totalMatches++;
                    idx += searchTerm.Length;
                }
            }

            Console.WriteLine($"Found {totalMatches} match(es) for '{searchTerm}'.");
        }
    }
}

Technical notes:

GetPdfText(int page) returns raw page text — no per-word coordinates, no layout reconstruction, and no OCR
Image-only / scanned pages return empty text and need an external OCR engine (Tesseract, etc.) to be searchable
The library is Windows-oriented and depends on WinForms / System.Drawing assemblies, which limits where the same code runs headlessly on .NET 6+

IronPDF — Extract and Search Text

using IronPdf;
using System;

IronPdf.License.LicenseKey = "YOUR-LICENSE-KEY";

var pdf = PdfDocument.FromFile("legal-document.pdf");

// Extract all text from every page
string fullText = pdf.ExtractAllText();

// Search for term
int occurrences = fullText.Split(new[] { "indemnification" }, StringSplitOptions.None).Length - 1;
Console.WriteLine($"Found '{occurrences}' occurrences of 'indemnification'.");

// Extract from a specific page (0-indexed)
string page3Text = pdf.ExtractTextFromPage(2);

Performance notes:
Text extraction uses the underlying PDF text layer, not OCR, so it is fast on text-based PDFs but returns nothing for purely scanned image pages. Scanned-PDF workflows pair IronPDF with an OCR step (Tesseract or similar) as a separate package. The extraction API runs the same way in a console app, ASP.NET Core, or Docker — no UI dependency.

PdfiumViewer — Performance Benchmark Scenario: Load 500-Page PDF

using PdfiumViewer;
using System;
using System.Diagnostics;
using System.Windows.Forms;

namespace ViewerPerformanceTest
{
    public partial class BenchmarkForm : Form
    {
        private PdfRenderer pdfRenderer;

        public BenchmarkForm()
        {
            InitializeComponent();
            pdfRenderer = new PdfRenderer { Dock = DockStyle.Fill };
            this.Controls.Add(pdfRenderer);
        }

        private void LoadLargePdf_Click(object sender, EventArgs e)
        {
            var stopwatch = Stopwatch.StartNew();

            try
            {
                // PdfDocument.Load is synchronous; dispatch off the UI thread
                // (Task.Run, BackgroundWorker) if you want to keep the form
                // responsive while a large file loads.
                using (var pdfDocument = PdfDocument.Load("large-manual-500-pages.pdf"))
                {
                    stopwatch.Stop();
                    Console.WriteLine($"Load time: {stopwatch.ElapsedMilliseconds} ms");

                    pdfRenderer.Load(pdfDocument);
                }
            }
            catch (Exception ex)
            {
                Console.WriteLine($"Load failed after {stopwatch.ElapsedMilliseconds} ms: {ex.Message}");
            }
        }
    }
}

Observations:

Load is synchronous: large files block the calling thread; benchmark on your own hardware
Document is loaded for display: large documents can have a noticeable memory footprint
No built-in cancellation token for Load
Very large documents (1,000+ pages) can be slow to load and view in the renderer control

IronPDF — Performance Benchmark: Generate 500-Page PDF

using IronPdf;
using System;
using System.Diagnostics;
using System.Linq;

IronPdf.License.LicenseKey = "YOUR-LICENSE-KEY";

var stopwatch = Stopwatch.StartNew();

var htmlPages = Enumerable.Range(1, 500).Select(i =>
    $"<h1>Chapter {i}</h1><p>Content for chapter {i}...</p>");

var renderer = new ChromePdfRenderer();
var pdf = renderer.RenderHtmlAsPdf(
    string.Join("<div style='page-break-after: always;'></div>", htmlPages));

stopwatch.Stop();
Console.WriteLine($"Generation time: {stopwatch.ElapsedMilliseconds} ms");

pdf.SaveAs("generated-500-pages.pdf");

Observations:

Generation cost scales with HTML complexity (CSS, images, tables) more than raw page count
IronPDF exposes async APIs so generation can run off the UI thread in desktop apps
Optimization patterns: cache external assets, pre-compile templates, parallelize batches with care for engine memory

Architectural comparison:

Scenario	PdfiumViewer	IronPDF
Load and view an existing PDF	Built-in viewer/renderer controls	Not the target use case
Generate a PDF from HTML	Not supported	Core feature
Render a page to bitmap	Yes (via `Render`)	Available via `ToBitmap`
Extract text (programmatic)	Page-level via `GetPdfText`	`ExtractAllText` / `ExtractTextFromPage`
Headless / server execution	Designed around UI controls	Designed for headless use
Async APIs	Limited	Available across the generation pipeline

API Mapping Reference

PdfiumViewer Concept	IronPDF Equivalent	Notes
`PdfDocument.Load(path)`	`PdfDocument.FromFile(path)`	Both load existing PDFs
`pdfRenderer.Load(doc)`	N/A (no viewer control)	IronPDF is backend-focused
`doc.Render(page, dpiX, dpiY, forPrinting)`	`pdf.RasterizeToImageFiles(path, dpi)` / `pdf.ToBitmap()`	Both rasterize, different shapes
`doc.PageCount`	`pdf.PageCount`	Same property
`doc.GetPdfText(page)`	`pdf.ExtractTextFromPage(page)` / `pdf.ExtractAllText()`	Page-level vs. whole-document
`doc.Dispose()`	`pdf.Dispose()`	Both implement `IDisposable`
(not available)	`RenderHtmlAsPdf()`	IronPDF core feature
(not available)	`PdfDocument.Merge()`	Combine PDFs
(not available)	`pdf.Form`	Form read / write / flatten
(not available)	`pdf.SecuritySettings`	Password protection and permissions
`PdfViewer` control	(not available)	IronPDF has no WinForms/WPF UI control

Comprehensive Feature Comparison

Feature	PdfiumViewer	IronPDF
Status
Upstream project	Archived 2019-08-02	Actively developed
Community forks	Yes (bezzad, PdfiumViewer.Updated, others)	N/A (single product)
API stability across forks	May vary	Documented per release
Support model
Documentation	Fork-dependent	Vendor docs and API reference
Issue channels	GitHub issues per fork	Commercial vendor channels
Commercial support	Not available	Available
Content creation
HTML to PDF	No	Yes (core feature)
URL to PDF	No	Yes
Generate from scratch	No	Yes
Merge PDFs	No	Yes
Split PDFs	No	Yes
PDF operations
Display in WinForms/WPF	Yes (core feature)	No UI control
Render page to bitmap	Yes (`Render`)	Yes (`ToBitmap`, `RasterizeToImageFiles`)
Extract text	Page-level via `GetPdfText` (no per-word coords, no OCR)	`ExtractAllText` / `ExtractTextFromPage`
Form handling	View only	Read, write, flatten
Digital signatures	No API	Yes
Encryption	No API	Yes
Watermarks	No API	Yes
Security
Password-protected PDFs	Can open with password	Open and manipulate, can set passwords
Certificate signatures	No	Yes
Redaction	No	Yes
Runtime characteristics
Thread model	Synchronous; UI thread must dispatch large work	Async APIs available
Native binaries	Separate `PdfiumViewer.Native.*` packages	Embedded with the IronPdf package
Cross-platform	Windows-oriented; `System.Drawing` is Windows-only on .NET 6+	Windows, Linux, macOS, Docker
Server / cloud usage	Not the target use case	Designed for it
Development
Async/await	Limited	Available
Headless operation	Built around UI controls	Yes
Deployment	Desktop apps	NuGet, Docker, cloud

Installation Comparison

PdfiumViewer (community fork example):

Install-Package PdfiumViewer.Updated  # .NET 6+
Install-Package PdfiumViewer.Native.x86_64.v8-xfa  # Native binaries

using PdfiumViewer;
// Requires WinForms or WPF application
// Add PdfRenderer control to form

IronPDF:

Install-Package IronPdf  # Single package, all platforms

using IronPdf;
// Works in console, ASP.NET, Azure Functions, etc.

Conclusion

PdfiumViewer is good at the job it was designed for: embedding a PDF viewer control in WinForms/WPF desktop applications, with page-level rendering and GetPdfText for raw text extraction. For teams whose product is a Windows desktop UI that already has PDFs to display, community forks like PdfiumViewer.Updated or bezzad/PdfiumViewer can still serve that role. The upstream archive in 2019, multi-fork ecosystem, and tight coupling to WinForms/System.Drawing are the points to weigh against that.

Migration starts to make sense when:

Server-side or headless PDF generation is on the requirements list (web apps, APIs, background workers)
Document creation from templates, HTML, or data is needed
Cross-platform deployment is on the roadmap (Linux, Docker, cloud)
PDF manipulation beyond viewing is required (merge, split, forms, signatures, watermarks)
Architecture is shifting from desktop to web or microservices

IronPDF replaces the generation side of that equation with PDF rendering from HTML strings, URLs, and files via a Chromium engine. It does not ship a WinForms/WPF viewer control, but it does handle the document lifecycle: create from modern HTML/CSS/JS, manipulate (merge, split, forms, encryption, signatures), extract (text, images, metadata), and print to physical printers. Installation is a single NuGet package with embedded native dependencies, and IronPDF runs in console apps, ASP.NET Core, Azure Functions, AWS Lambda, and Docker containers across Windows, Linux, and macOS on .NET Framework 4.6.2+ through modern .NET.

The two libraries optimize for different things — PdfiumViewer for immediate on-screen display, IronPDF for headless document creation — so the right answer often depends on which side of that line the product roadmap is sitting on.

What's your experience with desktop PDF viewer controls versus headless generation libraries? Share your performance benchmarks in the comments.

Related resources:

NReco PDF Generator vs IronPDF: what the docs do not tell you

IronSoftware — Thu, 14 May 2026 11:10:00 +0000

NReco.PdfGenerator is a .NET wrapper around the wkhtmltopdf native binary, which means every PDF conversion spawns an external process. That architectural choice shapes everything downstream: temp directory permissions, Windows security policies, diagnostic depth when something fails. The wrapper surfaces what the executable returns — often just an exit code.

That worked well enough when Qt WebKit was a reasonable rendering target. The wkhtmltopdf project's last stable release (0.12.6) shipped in June 2020, and the upstream repository was archived on January 2, 2023. The underlying WebKit fork dates to roughly 2012. The ecosystem moved on; teams running NReco often have not, because migration feels expensive up front.

This guide walks through what that calculation looks like today: what still works on NReco.PdfGenerator, where the friction surfaces, and when the math tips toward a modern alternative. For a step-by-step API map, see the IronPDF migration guide for NReco.PdfGenerator.

Understanding IronPDF

IronPDF renders HTML to PDF using an embedded Chromium engine—the same Blink renderer that powers Chrome, Edge, and Electron apps. This means HTML5, CSS Grid, Flexbox, ES6 JavaScript, and WOFF2 fonts work exactly as they do in a modern browser. No "this CSS property isn't supported" surprises. No external executables to spawn or monitor.

The library provides both HTML-to-PDF rendering and comprehensive PDF manipulation in one package: merge documents, extract text, add watermarks, apply digital signatures, fill forms programmatically. For teams managing document workflows beyond simple generation, this consolidates tooling instead of forcing integration across multiple libraries.

Key characteristics of NReco.PdfGenerator

Product status

NReco.PdfGenerator 1.2.1 was published on NuGet in January 2023 and there have been no further releases on nuget.org. It bundles wkhtmltopdf 0.12.6 (June 2020). The upstream wkhtmltopdf repository was archived on January 2, 2023. The underlying Qt WebKit fork is from roughly 2012 and does not include CSS Grid, Flexbox, ES6 modules, or other web standards introduced in the years since.

Scope

HTML-to-PDF rendering is the documented scope. PDF manipulation operations (merge, split, watermark, digital signature, form fill, text extraction) are not part of the package — those require pairing with another library such as iTextSharp.

Architecture notes

The library shells out to an external wkhtmltopdf binary for every conversion. Temp directory permissions, IIS app pool identity, and binary extraction paths all become operational concerns. JavaScript runs inside the Qt WebKit context, which broadly tracks the ECMAScript 5 era. Modern CSS features such as flex, grid, and @supports are not supported by the bundled engine. WOFF2 web fonts are not supported by the bundled engine.

Support and maintenance

NReco offers community support through the project's issue tracker; there is no commercial SLA tier listed for the free edition. With no upstream updates to the underlying renderer since 2020 and the wkhtmltopdf project archived, the rendering engine itself is no longer receiving fixes.

Deployment notes

Docker and Linux deployments require manual wkhtmltopdf binary management or the paid NReco.PdfGenerator.LT package together with a separately installed wkhtmltopdf. The free edition's license terms restrict production use to non-SaaS single-server scenarios; SaaS, multi-server, and redistribution use require the $199 enterprise pack per the NReco site. Process spawning introduces per-conversion overhead, and when a conversion fails the wrapper typically surfaces an exit code rather than a stack trace.

Feature Comparison Overview

Feature	NReco.PdfGenerator	IronPDF
Current status	Last NuGet release Jan 2023; bundles wkhtmltopdf 0.12.6 (Jun 2020)	Active development, regular releases
HTML support	Qt WebKit fork (~2012); CSS Grid and Flexbox not supported by the engine	Chromium Blink; HTML5, modern CSS, ES6+
Rendering engine	wkhtmltopdf native binary	Embedded Chromium
Installation	NuGet package + extracts wkhtmltopdf binary at runtime; VC++ runtime on Windows	NuGet package; Chromium binaries included
Support	Community issue tracker	Commercial support with SLA tiers
Upstream status	wkhtmltopdf repository archived Jan 2023	Active vendor roadmap

HTML String Rendering with Headers and Footers

NReco — HTML String to PDF with Custom Headers

using NReco.PdfGenerator;
using System;
using System.IO;

namespace PdfGenerationExample
{
    class Program
    {
        static void Main(string[] args)
        {
            var pdfConverter = new HtmlToPdfConverter();

            // Page dimensions in millimetres
            pdfConverter.PageWidth = 210;  // A4 width
            pdfConverter.PageHeight = 297; // A4 height
            pdfConverter.Margins = new PageMargins
            {
                Top = 20,
                Bottom = 20,
                Left = 15,
                Right = 15
            };

            // PageHeaderHtml is a string passed through to wkhtmltopdf
            pdfConverter.PageHeaderHtml = "Report Generated: " + DateTime.Now.ToShortDateString();

            // HTML content
            string htmlContent = @"
                <html>
                <head>
                    <style>
                        body { font-family: Arial; }
                        .invoice { border: 1px solid #ccc; padding: 20px; }
                    </style>
                </head>
                <body>
                    <div class='invoice'>
                        <h1>Monthly Report</h1>
                        <p>Generated on " + DateTime.Now + @"</p>
                    </div>
                </body>
                </html>";

            // GeneratePdf invokes the bundled wkhtmltopdf binary
            byte[] pdfBytes = pdfConverter.GeneratePdf(htmlContent);

            File.WriteAllBytes("nreco_output.pdf", pdfBytes);
        }
    }
}

Behavioural notes for this code path:

PageHeaderHtml is forwarded to wkhtmltopdf as a plain string; rich HTML/CSS in the header is constrained by what the bundled engine supports
Each call spawns the wkhtmltopdf executable, which adds per-conversion process startup overhead
The wkhtmltopdf process needs write permissions on the configured temp directory
When a conversion fails, the wrapper typically returns an exit code rather than a structured stack trace
CSS Grid, Flexbox, and WOFF2 fonts are not supported by the engine
JavaScript runs inside the Qt WebKit context (broadly ECMAScript 5 era)

IronPDF — HTML String to PDF with HTML Headers

For complete API reference, see the ChromePdfRenderer class documentation.

using IronPdf;

IronPdf.License.LicenseKey = "YOUR-LICENSE-KEY";

var renderer = new ChromePdfRenderer();

// HTML headers support full HTML/CSS markup
renderer.RenderingOptions.HtmlHeader = new HtmlHeaderFooter
{
    MaxHeight = 20,
    HtmlFragment = "<div style='text-align:center; font-size:10px;'>Report Generated: {date}</div>",
    DrawDividerLine = true
};

// HTML content with modern CSS
string htmlContent = @"
    <style>
        .invoice {
            display: grid;
            grid-template-columns: 1fr 1fr;
            gap: 20px;
        }
    </style>
    <div class='invoice'>
        <h1>Monthly Report</h1>
        <p>Generated on {date}</p>
    </div>";

// Render with Chromium engine
var pdf = renderer.RenderHtmlAsPdf(htmlContent);
pdf.SaveAs("ironpdf_output.pdf");

IronPDF headers support full HTML/CSS styling and dynamic placeholders like {page}, {total-pages}, {date}. The Chromium renderer handles CSS Grid and modern layouts without workarounds. Learn more about HTML string rendering techniques.

URL to PDF Conversion with JavaScript Execution

NReco — Rendering URLs with JavaScript Wait

using NReco.PdfGenerator;
using System;
using System.IO;

namespace UrlToPdfExample
{
    class Program
    {
        static void Main(string[] args)
        {
            var converter = new HtmlToPdfConverter();

            // JavaScript is executed inside the Qt WebKit context
            converter.EnableJavaScript = true;

            // Fixed delay in milliseconds before snapshotting the page
            converter.JavaScriptDelay = 1000;

            converter.Orientation = PageOrientation.Portrait;
            converter.Size = PageSize.A4;

            converter.Margins.Top = 10;
            converter.Margins.Bottom = 10;
            converter.Margins.Left = 10;
            converter.Margins.Right = 10;

            // Forward wkhtmltopdf stdout/stderr to the host process
            converter.Quiet = false;

            try
            {
                // Synchronous call; returns when the wkhtmltopdf process exits
                var pdfBytes = converter.GeneratePdfFromFile(
                    "https://example.com/dashboard",
                    null
                );

                File.WriteAllBytes("url_output.pdf", pdfBytes);
            }
            catch (PdfGenerationException ex)
            {
                Console.WriteLine($"Generation failed: {ex.Message}");
            }
        }
    }
}

Behavioural notes for this code path:

The Qt WebKit engine broadly tracks ECMAScript 5; modern syntax such as const/let, arrow functions, and async/await may not be available depending on the build
GeneratePdfFromFile is a synchronous call; there is no first-class async API
Page readiness is gated by a fixed JavaScriptDelay, not by a load/condition wait
Network and rendering errors typically surface as wkhtmltopdf exit codes
CORS and TLS behaviour depend on what was compiled into the bundled wkhtmltopdf build (last release June 2020) — verify against your version

IronPDF — Async URL Rendering with Wait-for-Load

For comprehensive rendering options, review the ChromePdfRenderOptions documentation.

using IronPdf;
using System.Threading.Tasks;

async Task GenerateFromUrl()
{
    IronPdf.License.LicenseKey = "YOUR-LICENSE-KEY";

    var renderer = new ChromePdfRenderer();

    renderer.RenderingOptions.EnableJavaScript = true;
    renderer.RenderingOptions.WaitFor.RenderDelay(1000); // ms after page load

    var pdf = await renderer.RenderUrlAsPdfAsync(new Uri("https://example.com/dashboard"));
    await pdf.SaveAsAsync("url_output.pdf");
}

IronPDF's Chromium engine understands modern JavaScript (ES2020+) and handles dynamic SPAs that rely on fetch, promises, and async rendering. The async methods don't block threads. Detailed walkthrough: Pixel-perfect HTML to PDF rendering.

Local HTML File with External Assets

NReco — File Conversion with Asset References

using NReco.PdfGenerator;
using System;
using System.IO;

namespace FileToPdfExample
{
    class Program
    {
        static void Main(string[] args)
        {
            var converter = new HtmlToPdfConverter();

            converter.Size = PageSize.Letter;
            converter.Orientation = PageOrientation.Portrait;
            converter.Margins = new PageMargins(15, 15, 15, 15);

            converter.Zoom = 1.0f;

            converter.GenerateGrayscale = false;
            converter.LowQuality = false;

            // Footer placeholders: [page] / [topage] in wkhtmltopdf syntax
            converter.PageFooterHtml = "Page [page] of [topage]";

            try
            {
                // File path should be absolute
                string absolutePath = Path.GetFullPath("template.html");

                // Asset references in the HTML resolve relative to the file
                byte[] pdfContent = converter.GeneratePdfFromFile(
                    absolutePath,
                    null
                );

                File.WriteAllBytes("file_output.pdf", pdfContent);
            }
            catch (Exception ex)
            {
                Console.WriteLine($"Conversion error: {ex.Message}");
                // wkhtmltopdf binaries are extracted under App_Data/wkhtmltopdf/ by default
            }
        }
    }
}

Behavioural notes for this code path:

Asset paths must be absolute or relative to the HTML file location
The bundled Qt WebKit engine supports TTF/WOFF fonts; WOFF2 is not supported
@import and other file:// resource loads depend on wkhtmltopdf's local-file access flags — verify against your configuration
Modern image formats such as WebP and AVIF may not render in the bundled engine
The wkhtmltopdf process needs read access to any referenced files
wkhtmltopdf uses [page] and [topage] placeholders in header/footer markup

IronPDF — File Rendering with Auto Asset Resolution

Complete file conversion guide: HTML File to PDF Tutorial.

using IronPdf;

IronPdf.License.LicenseKey = "YOUR-LICENSE-KEY";

var renderer = new ChromePdfRenderer();

// IronPDF placeholders: {page}, {total-pages}, {date}, {time}, {html-title}, {url}
renderer.RenderingOptions.HtmlFooter = new HtmlHeaderFooter
{
    MaxHeight = 15,
    HtmlFragment = "<center><i>Page {page} of {total-pages}</i></center>"
};

// Relative paths resolve from the HTML file's directory
var pdf = renderer.RenderHtmlFileAsPdf("template.html");
pdf.SaveAs("file_output.pdf");

IronPDF automatically sets the base URL to the HTML file's directory, so relative paths to CSS, images, and fonts work without manual configuration. Supports all modern image formats (WebP, AVIF) and font formats (WOFF2, variable fonts).

Batch Processing Multiple HTML Files

NReco — Sequential File Batch Processing

using NReco.PdfGenerator;
using System;
using System.Collections.Generic;
using System.IO;
using System.Linq;

namespace BatchProcessingExample
{
    class Program
    {
        static void Main(string[] args)
        {
            var converter = new HtmlToPdfConverter();

            converter.Size = PageSize.A4;
            converter.Margins = new PageMargins(20, 20, 20, 20);

            // Per-conversion timeout in milliseconds
            converter.ExecutionTimeout = 60000;

            string[] htmlFiles = Directory.GetFiles("invoices/", "*.html");

            var results = new List<(string filename, bool success, string error)>();

            // Sequential loop: each iteration spawns wkhtmltopdf
            foreach (var htmlFile in htmlFiles)
            {
                try
                {
                    byte[] pdfBytes = converter.GeneratePdfFromFile(htmlFile, null);

                    string outputPath = Path.ChangeExtension(htmlFile, ".pdf");
                    File.WriteAllBytes(outputPath, pdfBytes);

                    results.Add((htmlFile, true, null));
                }
                catch (PdfGenerationException ex)
                {
                    // Exception message is typically the wkhtmltopdf exit code / stderr
                    results.Add((htmlFile, false, ex.Message));
                }
                catch (Exception ex)
                {
                    results.Add((htmlFile, false, ex.Message));
                }
            }

            // Report results
            int succeeded = results.Count(r => r.success);
            int failed = results.Count(r => !r.success);

            Console.WriteLine($"Completed: {succeeded} succeeded, {failed} failed");

            foreach (var result in results.Where(r => !r.success))
            {
                Console.WriteLine($"Failed: {result.filename} - {result.error}");
            }
        }
    }
}

Behavioural notes for this code path:

Each conversion spawns the wkhtmltopdf process; parallelising the loop multiplies that overhead
Timeout is per-conversion; there is no batch-level control surface
Error context is limited to whatever the wkhtmltopdf process surfaces (typically exit codes and stderr lines)
No first-class progress or cancellation callbacks
Long-running batches benefit from defensive temp-directory cleanup — verify against your version

IronPDF — Parallel Batch with Thread Safety

using IronPdf;
using System.IO;
using System.Linq;
using System.Threading.Tasks;

IronPdf.License.LicenseKey = "YOUR-LICENSE-KEY";

var renderer = new ChromePdfRenderer();
var htmlFiles = Directory.GetFiles("invoices/", "*.html");

Parallel.ForEach(htmlFiles, htmlFile =>
{
    var pdf = renderer.RenderHtmlFileAsPdf(htmlFile);
    pdf.SaveAs(Path.ChangeExtension(htmlFile, ".pdf"));
});

IronPDF's Chromium engine is designed for in-process parallel rendering, so the loop above runs each file through the same renderer without spawning external executables. Resource pooling is handled inside the library.

API Mapping Reference

NReco.PdfGenerator	IronPDF Equivalent
`HtmlToPdfConverter` class	`ChromePdfRenderer` class
`GeneratePdf(string htmlContent)`	`RenderHtmlAsPdf(string html)`
`GeneratePdfFromFile(string path, string output)`	`RenderHtmlFileAsPdf(string path)`
`EnableJavaScript` property	`RenderingOptions.EnableJavaScript`
`JavaScriptDelay` property	`RenderingOptions.WaitFor.RenderDelay(ms)`
`PageHeaderHtml` property (text only)	`RenderingOptions.HtmlHeader.HtmlFragment` (full HTML)
`PageFooterHtml` property (text only)	`RenderingOptions.HtmlFooter.HtmlFragment` (full HTML)
`Margins` property	`RenderingOptions.MarginTop/Bottom/Left/Right`
`Size` property (PageSize enum)	`RenderingOptions.PaperSize`
`Orientation` property	`RenderingOptions.PaperOrientation`
`Zoom` property	`RenderingOptions.Zoom`
`GenerateGrayscale` property	`RenderingOptions.GrayScale`
`CustomCssUrl` property	`RenderingOptions.CustomCssUrl`
`ExecutionTimeout`	Operation-level timeout via CancellationToken

Comprehensive Feature Comparison

Category	Feature	NReco.PdfGenerator	IronPDF
Status	Last NuGet release	January 2023 (1.2.1)	Active, regular releases
	Upstream engine	wkhtmltopdf, repository archived Jan 2023	Chromium, actively maintained
	Public roadmap	Not published for the free package	Available
Support	Documentation	Project docs and issue tracker	Vendor docs and tutorials
	Technical support	Community issue tracker	Commercial support tiers
	SLA available	No (free edition)	Yes (Enterprise)
Content creation	HTML to PDF	Yes (Qt WebKit)	Yes (Chromium)
	URL to PDF	Yes (sync)	Yes (sync and async)
	Modern CSS (Grid, Flexbox)	Not supported by the engine	Supported
	JavaScript	Qt WebKit (ES5 era)	Chromium (modern ES)
	Custom fonts	TTF/WOFF	TTF/WOFF/WOFF2 and others
	Headers/Footers	wkhtmltopdf header/footer HTML	HtmlHeaderFooter with full HTML/CSS
	Watermarks	Not in package	Built-in
	Page-number placeholders	`[page]`, `[topage]`	`{page}`, `{total-pages}`, `{date}`, `{html-title}`
PDF operations	Merge PDFs	Not in package	Yes
	Split PDFs	Not in package	Yes
	Extract text	Not in package	Yes
	Extract images	Not in package	Yes
	Fill forms	Not in package	Yes
	Create forms from HTML	Not in package	Yes
	Digital signatures	Not in package	Yes
	Encryption / passwords	Not in package	Yes
Security	TLS support	Depends on the bundled wkhtmltopdf build	Tracks Chromium
	Known CVEs in engine	CVE-2020-21365, CVE-2022-35583 (unpatched upstream)	Patched as Chromium updates
Development	Async/await	Synchronous API	Full async support
	Thread safety	Not documented for the wrapper	Designed for concurrent use
	Parallel processing	Multiplies process-spawn overhead	In-process parallelism
	Docker support	Manual wkhtmltopdf binary management	Chromium included with the package
	Cross-platform	Requires `NReco.PdfGenerator.LT` + wkhtmltopdf install	Cross-platform from the same package
	.NET support	.NET Framework and .NET Core/.NET 5+	.NET Framework and .NET 6+

Patterns to watch for in production

These behaviour patterns show up across community discussion threads for wkhtmltopdf-based wrappers; verify against your own version and configuration before changing anything:

Permission errors from the IIS app pool identity when the Windows temp folder or wkhtmltopdf extraction path is not writable
Process-timeout exit codes when rendering very large or complex HTML
Missing images or CSS when relative asset paths do not resolve under the wkhtmltopdf process
IIS deployments where the App_Data extraction directory is locked or recycled between requests
Unicode and font-fallback behaviour that depends on which fonts are available to the Qt WebKit engine

Installation Comparison

NReco.PdfGenerator Installation

# Windows-only version (includes wkhtmltopdf binaries)
dotnet add package NReco.PdfGenerator

# Cross-platform version (requires manual wkhtmltopdf installation)
dotnet add package NReco.PdfGenerator.LT

using NReco.PdfGenerator;

// Windows: works immediately after NuGet restore
// Linux/macOS: requires wkhtmltopdf installation and path configuration
var converter = new HtmlToPdfConverter();

// For LT version on Linux
converter.WkHtmlToPdfExeName = "wkhtmltopdf";
converter.PdfToolPath = "/usr/local/bin/"; // where wkhtmltopdf is installed

NReco.PdfGenerator requires the Visual C++ 2015 Runtime on Windows. Docker and Linux deployments need manual wkhtmltopdf binary management or the paid NReco.PdfGenerator.LT package alongside a separately installed wkhtmltopdf. The free edition is licensed for non-SaaS single-server production environments; SaaS, multi-server, or redistribution scenarios require the $199 enterprise pack per the NReco site.

IronPDF Installation

Complete installation steps: Chrome PDF Rendering Engine Guide.

dotnet add package IronPdf

using IronPdf;

IronPdf.License.LicenseKey = "YOUR-LICENSE-KEY";

// Same package works on Windows, Linux, macOS, and Docker
var renderer = new ChromePdfRenderer();

IronPDF is fully managed .NET code with embedded Chromium engine. No native dependencies to install. Cross-platform support included without separate packages.

When to stay on NReco, when to migrate

NReco.PdfGenerator can be a reasonable fit when HTML templates use older layout patterns (no CSS Grid or Flexbox), templates change rarely, and the deployment target is a stable Windows host where the wkhtmltopdf process has been reliable. The free edition's licence covers non-SaaS single-server production use, which is sometimes enough on its own.

The math shifts when CSS Grid or Flexbox layouts are required, modern JavaScript needs to run, process timeouts or permission errors appear in production logs, or PDF operations beyond rendering (merge, split, watermark, digital signature, form fill, text extraction) enter scope. Docker and cross-platform requirements also push toward alternatives because the wkhtmltopdf binary management has to be solved separately.

The practical question is how much engineering time goes into working around the wkhtmltopdf wrapper versus investing once in a migration. With the wkhtmltopdf upstream archived since January 2023, that calculation only moves in one direction over time.

IronPDF consolidates HTML rendering and PDF manipulation in a single package built on an embedded Chromium engine. The API is async-friendly, the library runs the same way on Windows, Linux, macOS, and Docker, and there are no external executables to manage or to debug when a conversion fails. For a step-by-step API map and code-level diff, see the NReco.PdfGenerator to IronPDF migration guide.

Have you run into any of these wkhtmltopdf-wrapper patterns in production, and how did you work around them?

Related resources:

Understanding Aspose PDF Pricing: A Complete Cost Analysis and Alternatives

IronSoftware — Thu, 14 May 2026 10:07:00 +0000

Developers evaluating PDF libraries for .NET projects frequently encounter Aspose.PDF, only to discover that the licensing costs extend well beyond the initial purchase price. This article breaks down Aspose PDF pricing, explains the total cost of ownership including annual renewals and support, and presents an alternative for teams seeking similar capabilities at a lower price point.

The Aspose PDF Pricing Structure

Aspose.PDF uses a tiered licensing model based on the number of developers and deployment scope. Understanding these tiers requires examining both the license types and the ongoing costs that many teams overlook during initial evaluation.

License Types Explained

Aspose offers several license categories, each with different restrictions:

Developer Small Business License: Covers one developer creating applications for use at one physical location within your organization. This is the entry-level option, but the single-location restriction limits its usefulness for distributed teams or multi-site deployments.

Site Small Business License: Covers up to ten developers creating applications for use at ten physical locations. If more than ten developers access the product or you deploy to more than ten locations, additional licenses are required.

Developer OEM License: Allows one developer to create unlimited end-user software that can be deployed at unlimited physical locations, including distribution to third parties, SaaS applications, and public-facing websites.

Site OEM License: Covers up to ten developers creating unlimited end-user software for unlimited deployment locations, including SaaS and third-party distribution.

Current Pricing Tiers

Aspose PDF pricing starts from approximately $1,175 for a single Developer Small Business license. However, most production scenarios require higher-tier licenses:

License Type	Developers	Deployment Scope	Starting Price
Developer Small Business	1	1 location, internal only	~$1,175
Site Small Business	Up to 10	10 locations, internal only	Higher tier
Developer OEM	1	Unlimited, includes SaaS/distribution	~$1,799+
Site OEM	Up to 10	Unlimited, includes SaaS/distribution	Premium tier

For Aspose.Total (the complete suite including PDF, Words, Cells, and other components), pricing ranges from $1,999 to $55,986 depending on the license type and developer count. Individual products like Aspose.PDF are priced at approximately $999 per product.

The Hidden Costs: Annual Renewals and Support

The purchase price represents only part of the total cost. Aspose licenses include a subscription component that requires annual renewal to receive updates.

Subscription Mechanics

When you purchase an Aspose license, you receive:

A perpetual license to use the version available at purchase
One year of software updates (the "subscription")
Access to support forums

After the first year, the subscription expires. While you can continue using your licensed version, you lose access to:

New versions and updates
Bug fixes released after your subscription ends
New features and platform support

Renewal Costs

Subscription renewal is priced separately from the initial license. According to Aspose's renewal policy, renewing before your subscription expires qualifies for a 40% discount on the current retail price. If you allow the subscription to lapse, you pay full price to resume updates.

For teams that need to stay current with .NET versions, security patches, and bug fixes, subscription renewals become a recurring expense that can equal 40-60% of the original license cost each year.

Paid Support as Separate Product

Aspose's paid support is not included in the product license. Support subscriptions start from approximately $11,980 per year for comprehensive coverage.

Standard support options include:

Developer Support: Up to 3 incidents per year
Business Support: Up to 6 incidents per year

Community feedback suggests that free support can be limited for urgent issues. One reviewer noted: "They had us buy paid support (expensive) to get action on a bug because the free support went nowhere."

Paid consulting services are available at $5,999 per developer, per month for organizations needing dedicated assistance.

Total Cost of Ownership Calculation

For a typical team scenario, consider the three-year cost:

Example: 5-Developer Team with OEM Requirements

Cost Component	Year 1	Year 2	Year 3	Total
Initial License (Site OEM)	$5,000+	-	-	$5,000+
Subscription Renewal	-	$2,000+	$2,000+	$4,000+
Business Support (optional)	$11,980	$11,980	$11,980	$35,940

Without paid support, the three-year cost reaches approximately $9,000+. With support, it exceeds $40,000.

For organizations using multiple Aspose products (PDF, Words, Cells), the Aspose.Total bundle at $2,999+ offers better value, but the renewal and support costs scale accordingly.

Community Feedback on Aspose Pricing

Developers and teams evaluating Aspose consistently comment on the pricing:

"It is really expensive to buy but I hope that over time, I can realize the value. It is a big risk to pay out so much to start."
— User review, Capterra

"The API does get expensive when you have a high number of calls. $2,000 per month minimum."
— Developer feedback on API usage

"It's expensive, but worth the price. After evaluating many open source solutions, we found Aspose is the most powerful tool for our company."
— Enterprise user review

The sentiment varies based on use case. Teams processing high volumes or requiring extensive support find costs accumulating quickly. Organizations with simpler requirements often seek alternatives.

Comparing IronPDF Pricing

IronPDF offers a simpler pricing structure with lower entry points and included support.

IronPDF License Tiers

License Type	Developers	Locations	Projects	Price
Lite	1	1	1	$749
Plus	3	3	3	$1,499
Professional	10	10	10	$2,999
Unlimited	Unlimited	Unlimited	Unlimited	$2,999

Key Pricing Differences

One-Time License: IronPDF licenses are perpetual one-time purchases. There is no mandatory annual subscription to continue using the software.

Included Support: Unlike Aspose's separate support subscription, IronPDF includes support with the license purchase. Teams do not need to budget an additional $11,980+ annually for support coverage.

Optional Updates: Software updates are available through an optional maintenance subscription. Teams can choose to purchase updates when needed rather than maintaining a continuous subscription.

Lower Entry Point: The Lite license at $749 provides a significantly lower barrier to entry compared to Aspose's starting prices exceeding $1,000.

Three-Year Cost Comparison

5-Developer Team Scenario:

Component	Aspose PDF (Site OEM)	IronPDF (Professional)
Initial License	~$5,000+	$2,999
Year 2 Renewal	~$2,000+	Optional
Year 3 Renewal	~$2,000+	Optional
Support (3 years)	$35,940 (Business)	Included
Minimum 3-Year Total	~$9,000+	$2,999
With Support	~$44,940+	$2,999

The cost savings become more pronounced for teams that need ongoing support or operate on multi-year budgets.

Feature Comparison for Migration Planning

Before considering a switch based on pricing, teams should verify that IronPDF supports their required functionality.

HTML to PDF Conversion

Both libraries support HTML-to-PDF conversion, but with different rendering engines:

Aspose.PDF: Uses internal rendering that may struggle with modern CSS features. Some users report issues with flexbox, CSS3 animations, and complex layouts.

IronPDF: Uses an embedded Chromium engine, rendering HTML/CSS/JavaScript identically to Chrome browser output.

using IronPdf;

// IronPDF HTML to PDF conversion
var renderer = new ChromePdfRenderer();

// Configure rendering options
renderer.RenderingOptions.MarginTop = 20;
renderer.RenderingOptions.MarginBottom = 20;

// Render HTML string
var pdf = renderer.RenderHtmlAsPdf(@"
    <html>
    <head>
        <style>
            .container { display: flex; gap: 20px; }
            .card { border: 1px solid #ccc; padding: 15px; }
        </style>
    </head>
    <body>
        <div class='container'>
            <div class='card'>Card 1</div>
            <div class='card'>Card 2</div>
        </div>
    </body>
    </html>");

pdf.SaveAs("output.pdf");

PDF Manipulation

Both libraries support common PDF operations:

Operation	Aspose.PDF	IronPDF
Merge PDFs	Yes	Yes
Split PDFs	Yes	Yes
Add Watermarks	Yes	Yes
Form Filling	Yes	Yes
Digital Signatures	Yes	Yes
Extract Text	Yes	Yes
PDF/A Compliance	Yes	Yes

Platform Support

Aspose.PDF: Supports Windows, Linux, and macOS. However, Linux support relies on System.Drawing.Common and libgdiplus, which can cause memory leaks on non-Windows platforms.

IronPDF: Native support for Windows, Linux, macOS, and Docker without external dependencies. Uses embedded Chromium rather than System.Drawing.Common.

using IronPdf;

// Linux/Docker configuration
Installation.LinuxAndDockerDependenciesAutoConfig = true;

var renderer = new ChromePdfRenderer();
var pdf = renderer.RenderHtmlAsPdf("<h1>Cross-Platform PDF</h1>");
pdf.SaveAs("linux-output.pdf");

Migration Code Example

For teams moving from Aspose.PDF to IronPDF, the API differences are straightforward:

Aspose.PDF (Before)

using Aspose.Pdf;

// Aspose HTML to PDF
var document = new Document();
var page = document.Pages.Add();
var htmlFragment = new HtmlFragment("<h1>Hello World</h1>");
page.Paragraphs.Add(htmlFragment);
document.Save("output.pdf");

IronPDF (After)

using IronPdf;

// IronPDF HTML to PDF
var renderer = new ChromePdfRenderer();
var pdf = renderer.RenderHtmlAsPdf("<h1>Hello World</h1>");
pdf.SaveAs("output.pdf");

PDF Merging Comparison

Aspose.PDF:

using Aspose.Pdf;
using Aspose.Pdf.Facades;

var merger = new PdfFileEditor();
merger.Concatenate("file1.pdf", "file2.pdf", "merged.pdf");

IronPDF:

using IronPdf;

var pdf1 = PdfDocument.FromFile("file1.pdf");
var pdf2 = PdfDocument.FromFile("file2.pdf");
var merged = PdfDocument.Merge(pdf1, pdf2);
merged.SaveAs("merged.pdf");

When Aspose Makes Sense

Aspose PDF remains appropriate for certain scenarios:

Aspose.Total Users: If you already use multiple Aspose products, the bundled pricing provides value
Specific Features: Aspose offers some specialized features like advanced PDF/A validation tools
Existing Codebase: Large codebases with extensive Aspose integration may not justify migration effort
Enterprise Contracts: Organizations with existing Aspose enterprise agreements

When IronPDF Makes More Sense

Consider IronPDF when:

Budget Constraints: Lower upfront cost and no mandatory annual renewals
Support Needs: Included support versus separate paid support subscriptions
Cross-Platform Deployment: Docker, Linux, or macOS without libgdiplus dependencies
HTML/CSS Rendering: Modern web content with flexbox, CSS3, and JavaScript
New Projects: Starting fresh without existing Aspose code investment

Evaluating Before Committing

Both libraries offer evaluation options:

Aspose.PDF: Free trial available with watermark on output

IronPDF: 30-day free trial with full features and no watermarks

For teams evaluating based on pricing, the trial period allows verification that the lower-cost option meets technical requirements before committing to a purchase.

API Reference

For IronPDF implementation details:

ChromePdfRenderer - HTML rendering class
PdfDocument - PDF manipulation class
Licensing Information - Current pricing and license terms
Docker and Linux Guide - Cross-platform deployment

Conclusion

Aspose PDF pricing extends beyond the initial license purchase to include annual subscription renewals and separate support costs that can exceed the license price over time. For teams where the total cost of ownership is a concern, IronPDF offers comparable functionality at a lower price point with included support. Both libraries provide trial versions for technical evaluation before making a purchasing decision.

Jacob Mellor is the CTO at Iron Software and the original developer of IronPDF.

References

Aspose.PDF for .NET Pricing{:rel="nofollow"} - Official pricing page
Aspose Subscription Policy{:rel="nofollow"} - Renewal terms and conditions
Aspose License Types{:rel="nofollow"} - License category definitions
Aspose.Total Pricing on G2{:rel="nofollow"} - Third-party pricing reference
Aspose.Total Reviews on Capterra{:rel="nofollow"} - User feedback on pricing
IronPDF Licensing - Current IronPDF pricing and terms
IronPDF on Capterra - Third-party product listing

For IronPDF documentation and tutorials, visit ironpdf.com.

ExpertPdf vs IronPDF: the decision guide for .NET teams

IronSoftware — Thu, 14 May 2026 08:09:00 +0000

Throughput requirements scale faster than most invoice pipelines. A .NET team can integrate an HTML-to-PDF converter, ship it, and watch sequential processing stay comfortable at low volume — then watch the same workflow stretch from minutes to hours as customer counts grow. The cost is rarely a single error; it is linear scaling colliding with a roadmap that needs better.

The question for .NET teams is not "which library is fastest" but "what performance characteristics matter for my workload?" Throughput for batch jobs differs from latency for real-time API responses. Memory footprint matters differently in serverless functions than in long-running services. Understanding these characteristics drives practical tool selection.

Understanding IronPDF

IronPDF wraps a modern Chromium rendering engine optimized for server-side PDF generation at scale. The library handles concurrent rendering requests through an internal process pool that manages browser lifecycle. For batch operations, the same ChromePdfRenderer instance can process multiple documents sequentially, amortizing initialization overhead.

Memory management uses stream-based operations where possible, allowing PDFs to be generated directly to response streams without intermediate file system storage. The HTML to PDF tutorial covers async/await patterns for high-concurrency scenarios and resource pooling strategies for sustained throughput.

Key Limitations of ExpertPdf

Product Status

ExpertPdf is published by Outside Software Inc. and shipped from html-to-pdf.net. The suite is actively maintained — the latest release on nuget.org is v20.1.0 (April 2025) — though release notes typically describe "bug fixes and performance improvements" rather than headline features.

The .NetCore packages target .NET Standard 2.0 / .NET Framework 4.6.1, which means they run on .NET 5 through .NET 9, but without native multi-target builds or trimming-friendly assemblies. Platform support is Windows-only.

Missing Capabilities

Cross-platform deployment: ExpertPdf requires Windows for operation. This limits deployment options for teams using Linux containers, Azure App Service Linux plans, or AWS Lambda on non-Windows runtimes.

Component fragmentation: ExpertPdf sells separate NuGet packages for different operations (HtmlToPdf, PdfCreator, MergePdf, SplitPdf, PdfSecurity, PdfToImage). Teams needing multiple operations must license each component separately and coordinate versioning across packages.

Technical Considerations

Rendering engine: ExpertPdf historically uses a Trident (IE) engine with a "WebKit2" engine added in v12.2; modern Chromium is not the default. CSS3 features such as Flexbox, Grid, and CSS variables render best on the WebKit2 engine — verify your target HTML before migrating large estates.

Memory characteristics: With HTML-to-PDF architectures, complex pages with many images or JavaScript can show higher memory consumption. Memory profiling is recommended for workloads with large pages or high concurrency.

Thread safety: Verify documentation for thread safety guarantees. Some .NET PDF libraries require locking or separate instances per thread, which can impact throughput in multi-threaded scenarios.

Support Status

Commercial library with vendor support. Response times and support tier details vary by licensing arrangement — verify directly with the vendor.

Architecture Considerations

Modular licensing: Organizations track licenses for each component separately. If a workflow requires HTML conversion, merging, splitting, and security operations, that means multiple license keys and package versions to coordinate.

Windows dependency: As a Windows-only library, ExpertPdf requires Windows Server or Windows containers in cloud deployments, adding infrastructure cost beyond the library license itself.

Feature Comparison Overview

Category	ExpertPdf	IronPDF
Current Status	v20.1.0 (Apr 2025)	Continuously updated
Rendering Engine	Trident (IE) + WebKit2	Chromium
CSS Support	Best on WebKit2; older engines partial	Full CSS3 (Flexbox, Grid)
Installation	Multiple packages	Single NuGet
Platform	Windows-only	Cross-platform
Async Support	Limited	Full async/await

Code Comparison: Performance-Critical Operations

ExpertPdf — Simple HTML to PDF (Baseline)

using ExpertPdf.HtmlToPdf;
using System;
using System.Diagnostics;

namespace PerformanceBaseline
{
    class Program
    {
        static void Main(string[] args)
        {
            var stopwatch = Stopwatch.StartNew();

            try
            {
                // Initialize converter
                PdfConverter pdfConverter = new PdfConverter();

                // Configure basic options
                pdfConverter.PdfDocumentOptions.PdfPageSize = PdfPageSize.A4;
                pdfConverter.PdfDocumentOptions.PdfPageOrientation = PdfPageOrientation.Portrait;

                // Simple HTML content
                string html = @"
                    <html>
                    <body>
                        <h1>Performance Test Document</h1>
                        <p>This is a simple test paragraph.</p>
                    </body>
                    </html>";

                // Convert to PDF
                byte[] pdfBytes = pdfConverter.GetPdfBytesFromHtmlString(html);
                System.IO.File.WriteAllBytes("simple.pdf", pdfBytes);

                stopwatch.Stop();
                Console.WriteLine($"Conversion time: {stopwatch.ElapsedMilliseconds}ms");
                Console.WriteLine($"PDF size: {pdfBytes.Length / 1024}KB");
            }
            catch (Exception ex)
            {
                Console.WriteLine($"Error: {ex.Message}");
            }
        }
    }
}

Performance baseline characteristics:

Cold start: First conversion includes renderer initialization overhead
Memory footprint: Monitor working set for simple documents as baseline
Throughput: Single-threaded sequential processing as reference point

Typical measurements to capture:

Initial conversion time (includes startup)
Subsequent conversion time (warm cache)
Memory delta per conversion
CPU utilization during conversion
Process count and handle usage

IronPDF — Simple HTML to PDF (Baseline)

using IronPdf;
using System;
using System.Diagnostics;
using System.IO;

IronPdf.License.LicenseKey = "YOUR-LICENSE-KEY";

var stopwatch = Stopwatch.StartNew();

var renderer = new ChromePdfRenderer();
var pdf = renderer.RenderHtmlAsPdf(@"
    <html>
    <body>
        <h1>Performance Test Document</h1>
        <p>This is a simple test paragraph.</p>
    </body>
    </html>");
pdf.SaveAs("simple.pdf");

stopwatch.Stop();
Console.WriteLine($"Conversion time: {stopwatch.ElapsedMilliseconds}ms");
Console.WriteLine($"PDF size: {new FileInfo("simple.pdf").Length / 1024}KB");

For async operations with better concurrency characteristics, see the HTML String to PDF guide which covers RenderHtmlAsPdfAsync patterns.

ExpertPdf — Batch Processing Pattern

using ExpertPdf.HtmlToPdf;
using System;
using System.Collections.Generic;
using System.Diagnostics;

namespace BatchProcessing
{
    class Program
    {
        static void Main(string[] args)
        {
            int documentCount = 100;
            var stopwatch = Stopwatch.StartNew();
            long totalBytes = 0;

            try
            {
                // Single converter instance for batch
                PdfConverter pdfConverter = new PdfConverter();
                pdfConverter.PdfDocumentOptions.PdfPageSize = PdfPageSize.Letter;

                List<string> htmlTemplates = GenerateHtmlBatch(documentCount);

                for (int i = 0; i < htmlTemplates.Count; i++)
                {
                    byte[] pdfBytes = pdfConverter.GetPdfBytesFromHtmlString(htmlTemplates[i]);
                    System.IO.File.WriteAllBytes($"batch_{i}.pdf", pdfBytes);
                    totalBytes += pdfBytes.Length;
                }

                stopwatch.Stop();

                Console.WriteLine($"Total documents: {documentCount}");
                Console.WriteLine($"Total time: {stopwatch.ElapsedMilliseconds}ms");
                Console.WriteLine($"Average time per doc: {stopwatch.ElapsedMilliseconds / documentCount}ms");
                Console.WriteLine($"Throughput: {documentCount / (stopwatch.ElapsedMilliseconds / 1000.0):F2} docs/sec");
                Console.WriteLine($"Total output: {totalBytes / 1024 / 1024}MB");
            }
            catch (Exception ex)
            {
                Console.WriteLine($"Batch processing failed: {ex.Message}");
            }
        }

        static List<string> GenerateHtmlBatch(int count)
        {
            var templates = new List<string>();
            for (int i = 0; i < count; i++)
            {
                templates.Add($@"
                    <html>
                    <head>
                        <style>
                            body {{ font-family: Arial; margin: 40px; }}
                            .invoice {{ border: 1px solid #ddd; padding: 20px; }}
                        </style>
                    </head>
                    <body>
                        <div class='invoice'>
                            <h1>Invoice #{i + 1}</h1>
                            <p>Date: {DateTime.Now.ToString("yyyy-MM-dd")}</p>
                            <p>Customer: Customer {i + 1}</p>
                            <p>Amount: ${(i + 1) * 100:N2}</p>
                        </div>
                    </body>
                    </html>");
            }
            return templates;
        }
    }
}

Batch performance considerations:

Renderer reuse: Confirm in vendor docs whether a single converter instance is safe for sequential reuse
Memory accumulation: Monitor whether working set grows linearly or stabilizes
GC pressure: Check GC collection frequency during long-running batches
File I/O overhead: Disk writes can become a bottleneck for high-throughput scenarios

IronPDF — Batch Processing Pattern

using IronPdf;
using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.IO;
using System.Linq;

IronPdf.License.LicenseKey = "YOUR-LICENSE-KEY";

var documentCount = 100;
var stopwatch = Stopwatch.StartNew();

var renderer = new ChromePdfRenderer();
var htmlTemplates = Enumerable.Range(1, documentCount)
    .Select(i => $@"
        <html>
        <head>
            <style>
                body {{ font-family: Arial; margin: 40px; }}
                .invoice {{ border: 1px solid #ddd; padding: 20px; }}
            </style>
        </head>
        <body>
            <div class='invoice'>
                <h1>Invoice #{i}</h1>
                <p>Date: {DateTime.Now:yyyy-MM-dd}</p>
                <p>Customer: Customer {i}</p>
                <p>Amount: ${i * 100:N2}</p>
            </div>
        </body>
        </html>")
    .ToList();

for (int i = 0; i < htmlTemplates.Count; i++)
{
    var pdf = renderer.RenderHtmlAsPdf(htmlTemplates[i]);
    pdf.SaveAs($"batch_{i}.pdf");
}

stopwatch.Stop();
Console.WriteLine($"Total time: {stopwatch.ElapsedMilliseconds}ms");
Console.WriteLine($"Throughput: {documentCount / (stopwatch.ElapsedMilliseconds / 1000.0):F2} docs/sec");

The HTML to PDF tutorial includes optimization guidance for batch processing, including render caching and memory management strategies.

ExpertPdf — Complex HTML with Images

using ExpertPdf.HtmlToPdf;
using System;
using System.Diagnostics;

namespace ComplexHtmlTest
{
    class Program
    {
        static void Main(string[] args)
        {
            var stopwatch = Stopwatch.StartNew();
            long peakMemory = 0;

            try
            {
                PdfConverter pdfConverter = new PdfConverter();

                // Fit width to page
                pdfConverter.PdfDocumentOptions.FitWidth = true;

                // Complex HTML with external images
                string complexHtml = @"
                    <html>
                    <head>
                        <style>
                            body { font-family: 'Segoe UI', Arial; margin: 0; }
                            .header { background: #2c3e50; color: white; padding: 30px; }
                            .product-grid {
                                display: grid;
                                grid-template-columns: repeat(3, 1fr);
                                gap: 20px;
                                padding: 20px;
                            }
                            .product-card {
                                border: 1px solid #ddd;
                                border-radius: 8px;
                                padding: 15px;
                                box-shadow: 0 2px 4px rgba(0,0,0,0.1);
                            }
                            .product-card img {
                                width: 100%;
                                height: 200px;
                                object-fit: cover;
                                border-radius: 4px;
                            }
                        </style>
                    </head>
                    <body>
                        <div class='header'>
                            <h1>Product Catalog</h1>
                        </div>
                        <div class='product-grid'>";

                // Add 12 product cards with images
                for (int i = 1; i <= 12; i++)
                {
                    complexHtml += $@"
                        <div class='product-card'>
                            <img src='https://picsum.photos/300/200?random={i}' alt='Product {i}'>
                            <h3>Product {i}</h3>
                            <p>Price: ${(i * 50):N2}</p>
                        </div>";
                }

                complexHtml += @"
                        </div>
                    </body>
                    </html>";

                // Set navigation timeout for image loading (seconds)
                pdfConverter.NavigationTimeout = 60;

                // Measure memory before conversion
                long memBefore = GC.GetTotalMemory(true);

                byte[] pdfBytes = pdfConverter.GetPdfBytesFromHtmlString(complexHtml);

                // Measure memory after conversion
                long memAfter = GC.GetTotalMemory(false);
                peakMemory = memAfter - memBefore;

                System.IO.File.WriteAllBytes("complex_catalog.pdf", pdfBytes);

                stopwatch.Stop();

                Console.WriteLine($"Conversion time: {stopwatch.ElapsedMilliseconds}ms");
                Console.WriteLine($"PDF size: {pdfBytes.Length / 1024 / 1024:F2}MB");
                Console.WriteLine($"Memory delta: {peakMemory / 1024 / 1024:F2}MB");
            }
            catch (Exception ex)
            {
                Console.WriteLine($"Complex conversion failed: {ex.Message}");
            }
        }
    }
}

Complex document performance factors:

Image loading latency: Network requests for external images add conversion time
Memory per image: Each embedded image increases working set
CSS complexity: Grid layouts, flexbox, and transforms impact rendering time. Grid and Flexbox support depends on which engine is in use (Trident vs WebKit2) — verify against your target HTML
Page count: Multi-page documents from complex HTML show linear time/memory scaling

IronPDF — Complex HTML with Images

using IronPdf;
using System;
using System.Diagnostics;
using System.IO;
using System.Linq;

IronPdf.License.LicenseKey = "YOUR-LICENSE-KEY";

var stopwatch = Stopwatch.StartNew();

var renderer = new ChromePdfRenderer();
renderer.RenderingOptions.Timeout = 60; // seconds

var products = Enumerable.Range(1, 12)
    .Select(i => $@"
        <div class='product-card'>
            <img src='https://picsum.photos/300/200?random={i}' alt='Product {i}'>
            <h3>Product {i}</h3>
            <p>Price: ${i * 50:N2}</p>
        </div>")
    .ToList();

string complexHtml = $@"
    <html>
    <head>
        <style>
            body {{ font-family: 'Segoe UI', Arial; margin: 0; }}
            .header {{ background: #2c3e50; color: white; padding: 30px; }}
            .product-grid {{
                display: grid;
                grid-template-columns: repeat(3, 1fr);
                gap: 20px;
                padding: 20px;
            }}
            .product-card {{
                border: 1px solid #ddd;
                border-radius: 8px;
                padding: 15px;
            }}
            .product-card img {{
                width: 100%;
                height: 200px;
                object-fit: cover;
            }}
        </style>
    </head>
    <body>
        <div class='header'><h1>Product Catalog</h1></div>
        <div class='product-grid'>{string.Join("", products)}</div>
    </body>
    </html>";

var pdf = renderer.RenderHtmlAsPdf(complexHtml);
pdf.SaveAs("complex_catalog.pdf");

stopwatch.Stop();
Console.WriteLine($"Conversion time: {stopwatch.ElapsedMilliseconds}ms");
Console.WriteLine($"PDF size: {new FileInfo("complex_catalog.pdf").Length / 1024 / 1024:F2}MB");

ExpertPdf — Concurrent Processing

using ExpertPdf.HtmlToPdf;
using System;
using System.Collections.Concurrent;
using System.Diagnostics;
using System.Linq;
using System.Threading.Tasks;

namespace ConcurrentProcessing
{
    class Program
    {
        static async Task Main(string[] args)
        {
            int concurrencyLevel = 4;
            int documentsPerThread = 10;
            var stopwatch = Stopwatch.StartNew();

            var results = new ConcurrentBag<TimeSpan>();

            try
            {
                var tasks = new Task[concurrencyLevel];

                for (int t = 0; t < concurrencyLevel; t++)
                {
                    int threadId = t;
                    tasks[t] = Task.Run(() => ProcessBatch(threadId, documentsPerThread, results));
                }

                await Task.WhenAll(tasks);

                stopwatch.Stop();

                int totalDocs = concurrencyLevel * documentsPerThread;
                double avgTime = results.Select(r => r.TotalMilliseconds).Average();

                Console.WriteLine($"Total documents: {totalDocs}");
                Console.WriteLine($"Concurrency level: {concurrencyLevel}");
                Console.WriteLine($"Total time: {stopwatch.ElapsedMilliseconds}ms");
                Console.WriteLine($"Average doc time: {avgTime:F2}ms");
                Console.WriteLine($"Throughput: {totalDocs / (stopwatch.ElapsedMilliseconds / 1000.0):F2} docs/sec");
            }
            catch (Exception ex)
            {
                Console.WriteLine($"Concurrent processing failed: {ex.Message}");
            }
        }

        static void ProcessBatch(int threadId, int count, ConcurrentBag<TimeSpan> results)
        {
            // Separate converter instance per thread — confirm thread safety guarantees in vendor docs
            PdfConverter converter = new PdfConverter();

            for (int i = 0; i < count; i++)
            {
                var docWatch = Stopwatch.StartNew();

                string html = $@"
                    <html>
                    <body>
                        <h1>Thread {threadId}, Doc {i}</h1>
                        <p>Timestamp: {DateTime.Now}</p>
                    </body>
                    </html>";

                byte[] pdf = converter.GetPdfBytesFromHtmlString(html);
                System.IO.File.WriteAllBytes($"thread{threadId}_doc{i}.pdf", pdf);

                docWatch.Stop();
                results.Add(docWatch.Elapsed);
            }
        }
    }
}

Concurrent processing considerations:

Thread safety: Confirm whether a single converter instance handles concurrent calls or requires separate instances per thread
Resource contention: Monitor CPU and memory as concurrency levels increase
Optimal thread count: Test different concurrency levels to find your throughput peak
Synchronization overhead: Locking mechanisms (if required) can limit scalability

IronPDF — Concurrent Processing

using IronPdf;
using System;
using System.Diagnostics;
using System.Linq;
using System.Threading.Tasks;

IronPdf.License.LicenseKey = "YOUR-LICENSE-KEY";

var concurrencyLevel = 4;
var documentsPerThread = 10;
var stopwatch = Stopwatch.StartNew();

var renderer = new ChromePdfRenderer(); // Thread-safe, can be shared

var tasks = Enumerable.Range(0, concurrencyLevel)
    .Select(threadId => Task.Run(async () =>
    {
        for (int i = 0; i < documentsPerThread; i++)
        {
            var html = $@"
                <html>
                <body>
                    <h1>Thread {threadId}, Doc {i}</h1>
                    <p>Timestamp: {DateTime.Now}</p>
                </body>
                </html>";

            var pdf = await renderer.RenderHtmlAsPdfAsync(html);
            pdf.SaveAs($"thread{threadId}_doc{i}.pdf");
        }
    }))
    .ToArray();

await Task.WhenAll(tasks);

stopwatch.Stop();
var totalDocs = concurrencyLevel * documentsPerThread;
Console.WriteLine($"Total time: {stopwatch.ElapsedMilliseconds}ms");
Console.WriteLine($"Throughput: {totalDocs / (stopwatch.ElapsedMilliseconds / 1000.0):F2} docs/sec");

IronPDF's ChromePdfRenderer is designed to be shared across concurrent calls without locking or separate instances.

API Mapping Reference

Operation	ExpertPdf	IronPDF
Initialize	`new PdfConverter()`	`new ChromePdfRenderer()`
HTML string to PDF	`GetPdfBytesFromHtmlString(html)`	`RenderHtmlAsPdf(html)`
HTML URL to PDF	`GetPdfBytesFromUrl(url)`	`RenderUrlAsPdf(url)`
HTML file to PDF	`GetPdfBytesFromHtmlFile(path)`	`RenderHtmlFileAsPdf(path)`
Async conversion	Limited	`RenderHtmlAsPdfAsync(html)`
Set timeout	`NavigationTimeout` (seconds)	`RenderingOptions.Timeout` (seconds)
Page size	`PdfPageSize.A4`	`PaperSize = PdfPaperSize.A4`
Page orientation	`PdfPageOrientation.Portrait`	`PaperOrientation = PdfPaperOrientation.Portrait`
Margins	`PdfDocumentOptions.MarginTop/...`	`MarginTop/Bottom/Left/Right`
Headers/footers	`PdfHeaderOptions` / `PdfFooterOptions`	`HtmlHeaderFooter` / `TextHeaderFooter`
Page number tokens	`&p;` / `&P;`	`{page}` / `{total-pages}`

Comprehensive Feature Comparison

Status

Feature	ExpertPdf	IronPDF
Active development	v20.1.0 (Apr 2025)	Continuously updated
.NET 8 support	Via .NET Standard 2.0 (Windows)	Native, cross-platform
.NET 9 support	Via .NET Standard 2.0 (Windows)	Native, cross-platform
.NET 10 support	Verify with vendor	Native, cross-platform
.NET Framework 4.6.1+	Yes	Yes
Linux support	Not supported	Yes
macOS support	Not supported	Yes

Support

Feature	ExpertPdf	IronPDF
Documentation	Reference docs on html-to-pdf.net	Comprehensive docs and tutorials
Code examples	Reference samples	100+ examples
Community forum	Verify availability	Active forum
Technical support	Commercial vendor support	Engineering support
Response time	Verify SLA with vendor	Published support tiers

Content Creation

Feature	ExpertPdf	IronPDF
HTML5 support	Best on WebKit2 engine	Chromium
CSS3 support	Best on WebKit2 engine	Full CSS3
JavaScript execution	Yes (engine-dependent)	Yes
Web fonts	Yes	Google Fonts, custom
SVG rendering	Yes	Native
Canvas rendering	Engine-dependent	Yes
Responsive layouts	Engine-dependent	Media queries
Print CSS	Yes	@media print

PDF Operations

Feature	ExpertPdf	IronPDF
Merge PDFs	Separate `ExpertPdf.MergePdf`	Built-in
Split PDFs	Separate `ExpertPdf.SplitPdf`	Built-in
Extract pages	Yes	Yes
Rotate pages	Yes	Yes
Extract text	Separate component	Built-in
Extract images	Separate component	Built-in
Form filling	Yes	AcroForm
Headers/footers	Yes (token-based)	HTML-based and text-based
Page numbers	Token-based	Dynamic

Security

Feature	ExpertPdf	IronPDF
Password encryption	Yes (separate `ExpertPdf.PdfSecurity`)	128/256-bit AES
User permissions	Yes	Granular
Digital signatures	Separate component	Built-in X.509
Redaction	Verify with vendor	Permanent
Metadata	Yes	Yes

Performance

Metric	ExpertPdf	IronPDF
Cold start time	Benchmark in your environment	Benchmark in your environment
Warm conversion	Benchmark in your environment	Benchmark in your environment
Memory footprint	Varies by document	Stream-based processing
Thread safety	Verify with vendor	Thread-safe renderer
Concurrent throughput	Test with your workload	Linear scaling to cores
Async support	Limited	Full async/await

Development

Feature	ExpertPdf	IronPDF
NuGet installation	Multiple packages	One package
External dependencies	Verify requirements	Bundled native binaries
Component licensing	Separate per component	All-inclusive
Error messages	Standard exceptions	Detailed diagnostics
Testing support	Unit testable	Unit testable

Installation Comparison

ExpertPdf Installation

# HTML to PDF (pick the variant for your target framework)
Install-Package ExpertPdf.HtmlToPdf.NetCore   # .NET Core / 5-9
Install-Package ExpertPdfHtmlToPdf            # .NET Framework

# Additional components require separate packages
Install-Package ExpertPdf.MergePdf
Install-Package ExpertPdf.SplitPdf
Install-Package ExpertPdf.PdfSecurity
Install-Package ExpertPdf.PdfToImage
Install-Package ExpertPdf.PdfCreator

using ExpertPdf.HtmlToPdf;
using ExpertPdf.PdfCreator; // If using creator features

IronPDF Installation

Install-Package IronPdf

using IronPdf;
using IronPdf.Rendering;

When Migration Becomes Mandatory

Performance and platform requirements drive migration more often than feature gaps. Teams encounter forcing functions around ExpertPdf when:

Throughput requirements exceed single-threaded capacity: If your batch jobs require processing thousands of PDFs per hour and single-threaded sequential processing cannot meet that target, you need concurrent execution. ExpertPdf's thread safety model may require architectural changes to scale horizontally — confirm the vendor's guidance.

Licensing surface compounds: When your workflow requires HTML conversion, merging, splitting, text extraction, and security operations, licensing each ExpertPdf component separately creates budget and version-coordination complexity.

Cross-platform deployment: Teams standardizing on Linux containers or Azure App Service Linux plans cannot use ExpertPdf. The infrastructure cost of maintaining Windows-specific environments for PDF generation often exceeds the licensing savings.

Real-time latency requirements: If you generate PDFs in API request paths where users wait for responses, cold start times and conversion latency directly affect user experience. Profiling your specific documents under load reveals whether optimization is possible or migration is necessary.

IronPDF's Technical Approach

IronPDF optimizes for server-side throughput through several architectural choices:

Thread-safe by design: The ChromePdfRenderer class handles concurrent calls from multiple threads without locking or separate instances, enabling scaling with available cores.

Stream-based operations: PDFs can be generated directly to MemoryStream or network streams without intermediate file system I/O:

var pdf = renderer.RenderHtmlAsPdf(html);
await pdf.SaveAsAsync(Response.Body); // ASP.NET Core

Async/await support: All rendering methods have async counterparts (RenderHtmlAsPdfAsync) for non-blocking operation in high-concurrency scenarios.

Resource pooling: The library manages internal process pools to amortize startup costs across multiple conversions.

For detailed performance optimization guidance, see the HTML to PDF tutorial which covers caching strategies, memory management, and load testing methodologies.

What performance metrics matter most for your PDF workflows — throughput, latency, memory footprint, or concurrent capacity? Share your benchmarking experiences in the comments.

Learn more:

Syncfusion WPF Viewer Memory Leak: Causes and Solutions

IronSoftware — Thu, 14 May 2026 07:07:00 +0000

Memory management in WPF applications is notoriously challenging, and the problem becomes more pronounced when working with document viewers that handle large files. Developers using Syncfusion's PdfViewerControl in WPF applications have encountered persistent memory leak issues that can cause applications to consume gigabytes of RAM and eventually crash. This article examines the documented issues, their root causes, and alternative approaches.

The Problem

Syncfusion's WPF PdfViewerControl exhibits memory leak behavior in several scenarios. The most commonly reported issue occurs when navigating away from a page containing the viewer control. Even after calling the Unload(true) method, the control fails to release memory properly, leading to continuous memory growth.

The issue manifests particularly during repetitive operations. In stress tests involving repeatedly opening and closing PDF documents, memory consumption increases with each cycle until the application crashes. One documented case showed the application accumulating memory over approximately forty minutes before failing.

The underlying problem relates to how the PdfViewerControl renders pages. Internally, it uses Pdfium to render PDF pages as images. These image resources, stored in unmanaged memory, are not properly cleaned up even when developers explicitly dispose of the control. Memory profiling has revealed hundreds of multi-megabyte bitmaps remaining on the unmanaged heap after the viewer is supposedly unloaded.

Error Messages and Symptoms

Developers typically observe several warning signs before a full crash:

System.OutOfMemoryException: Exception of type 'System.OutOfMemoryException' was thrown.
   at System.Drawing.Graphics.CheckErrorStatus(Int32 status)
   at System.Drawing.Graphics.DrawImage(Image image, Int32 x, Int32 y)

Memory profiling tools like ANTS Memory Profiler or dotMemory show:

Retained objects in Syncfusion.Pdf.Primitives.PdfStream
Unmanaged memory allocations that never decrease
Image bitmaps (often 2MB each) accumulating on the native heap
Memory growth that does not correlate with garbage collection cycles

Application behavior indicators include:

Gradual slowdown during extended use
Memory usage climbing steadily in Task Manager
Application becoming unresponsive during page navigation
Eventual crash after processing many documents

Who Is Affected

The memory leak affects several deployment scenarios:

Operating Systems: While the issue is present on Windows (the only platform WPF supports), it is more severe in 32-bit environments. Syncfusion has acknowledged that in 32-bit mode, memory cannot be cleared normally even when forcing garbage collection.

Framework Versions: The problem has been reported across multiple .NET Framework and .NET Core versions running WPF. The issue persists in .NET 5, .NET 6, and .NET 7 applications.

Use Cases:

Document management systems where users view multiple PDFs in sequence
Kiosk applications that display PDF content continuously
Business applications with tabbed interfaces showing multiple documents
Preview panes that load and unload documents as users browse

Scale Factors: The leak is more noticeable in:

Applications handling image-heavy PDFs
Systems that open many documents in a single session
Long-running applications that remain open for hours
Environments where PDFs are programmatically cycled

Evidence from the Developer Community

The memory leak issue has been documented across multiple years and Syncfusion versions, indicating a persistent architectural challenge rather than a simple bug.

Timeline

Date	Event	Source
June 2017	Memory leak reported with preview windows	Syncfusion Forums
December 2017	Severe leak reported in Xamarin.Forms PdfViewer on UWP	Syncfusion Forums
November 2020	CPU and memory leak after closing UWP viewer	Syncfusion Forums
December 2020	Heavy memory leak in ASP.NET Core PDF creation	Syncfusion Forums
May 2023	Navigation memory leak in WPF reported	Syncfusion Forums
August 2024	Flutter PDF viewer memory leak on iOS	GitHub Issues

Community Reports

"When I using the RedGate to track the memory leak, it looks like happened in the Syncfusion.Pdf.Primitives.PdfStream. Every time when I close the display window, the memory isn't released. After view several pdf files with lot of images, the memory keep increase."

Developer, Syncfusion Forums, June 2017

"We conducted a stress test by continuously opening and returning a PDF file. After approximately forty minutes, the program started crashing. Even after calling the Unload(true) method when exiting the page, images from pdfium were not properly cleaned up. There were 644 2MB bitmaps on the unmanaged heap that hadn't been released."

Developer, Syncfusion Forums, May 2023

"The PDF viewer control for Xamarin Forms has a serious memory leak issue on UWP. The memory usage builds up when the user opens multiple PDF files, and even when closing them the memory is not released."

Developer, Syncfusion Forums, December 2017

Additional reports describe:

Memory not released after printing operations
TabControlExt navigation causing memory accumulation
Page navigation method affecting memory consumption (toolbar next button causes more leak than scrollbar navigation)

Root Cause Analysis

The memory leak stems from architectural decisions in how the PdfViewerControl renders PDF content.

Pdfium Rendering Engine: Syncfusion's WPF PDF viewer uses Pdfium to convert PDF pages into bitmap images for display. These bitmaps are created in unmanaged memory, outside the reach of .NET's garbage collector. When pages are rendered, new bitmaps are created, but old bitmaps are not always released.

Image Memory Management: The WPF framework itself has limitations in clearing image memory. Syncfusion has acknowledged that even when forcing memory clear operations, image memory cannot be fully reclaimed. This is compounded by Pdfium's native memory allocations that require explicit cleanup.

Virtualization Limitations: While the PdfViewerControl implements virtualization (rendering only the current page, previous page, and next page), the rendered images are not always properly disposed when they leave the visible range. The issue is more pronounced when using the page navigation buttons compared to scrollbar navigation.

32-bit Memory Constraints: In 32-bit environments, the problem is exacerbated by address space limitations. The accumulating unmanaged memory quickly consumes the available 2-4GB address space, leading to earlier crashes.

Event Handler Retention: In some scenarios, event handlers attached to the viewer are not properly detached, preventing the control from being garbage collected and keeping references to rendered content alive.

Attempted Workarounds

The developer community and Syncfusion support have suggested several workarounds, each with limitations.

Workaround 1: Explicit Garbage Collection

Approach: Force garbage collection after unloading the viewer.

private void CloseDocument()
{
    pdfViewer.Unload(true);
    pdfViewer = null;

    GC.Collect();
    GC.WaitForPendingFinalizers();
    GC.Collect();
}

Limitations:

Does not reclaim unmanaged memory from Pdfium
Performance impact from forced GC cycles
May not help in 32-bit environments
Interferes with normal GC optimization

Workaround 2: Use PdfDocumentView Instead

Approach: If you do not need the toolbar, use PdfDocumentView instead of PdfViewerControl.

// Instead of:
// <syncfusion:PdfViewerControl Name="pdfViewer" />

// Use:
// <syncfusion:PdfDocumentView Name="pdfDocumentView" />

private void LoadDocument(string filePath)
{
    pdfDocumentView.Load(filePath);
}

Limitations:

Only applicable when toolbar is not needed
Still exhibits memory growth, just slower
Requires UI redesign to provide navigation controls

Workaround 3: Document Load State Management

Approach: Ensure the document is fully loaded before allowing navigation away.

private bool _isDocumentLoaded = false;

private void PdfViewer_DocumentLoaded(object sender, EventArgs e)
{
    _isDocumentLoaded = true;
    exitButton.IsEnabled = true;
}

private void NavigateAway()
{
    if (_isDocumentLoaded)
    {
        pdfViewer.Unload(true);
        _isDocumentLoaded = false;
    }
}

Limitations:

Only prevents crashes from unloading during load
Does not address the underlying memory accumulation
Adds complexity to navigation logic

Workaround 4: Recreate Viewer on Each Use

Approach: Destroy and recreate the entire viewer control for each document.

private void LoadNewDocument(string filePath)
{
    // Remove old viewer
    if (pdfViewer != null)
    {
        pdfViewer.Unload(true);
        container.Children.Remove(pdfViewer);
        pdfViewer = null;
    }

    GC.Collect();
    GC.WaitForPendingFinalizers();

    // Create new viewer
    pdfViewer = new PdfViewerControl();
    container.Children.Add(pdfViewer);
    pdfViewer.Load(filePath);
}

Limitations:

Significant performance overhead
User experience impact (UI flicker, state loss)
Still accumulates memory over many cycles
Does not solve the core issue

A Different Approach: IronPDF

For applications where memory management is critical, particularly those processing many documents or running for extended periods, IronPDF provides an alternative architecture that avoids these specific memory issues.

IronPDF does not use Pdfium for rendering. Instead, it embeds a Chromium-based rendering engine with controlled memory lifecycle. The rendering engine handles its own memory management, including proper cleanup of native resources when documents are closed.

Why IronPDF Handles Memory Differently

IronPDF's architecture differs in key ways:

Embedded Chromium Engine: Rather than rendering PDF pages as WPF-managed bitmaps, IronPDF uses Chromium for PDF operations. This engine has mature memory management developed over years of browser usage.

Explicit Resource Lifecycle: IronPDF's PDF document objects implement IDisposable with deterministic cleanup. When you dispose a document, associated resources are released, including native memory.

No System.Drawing Dependency: Unlike renderers that rely on System.Drawing (and its underlying GDI+ / libgdiplus), IronPDF does not accumulate image memory in the WPF layer.

Code Example

If your WPF application needs to generate or manipulate PDFs without the memory accumulation issues, IronPDF can handle the document processing:

using IronPdf;
using System;
using System.IO;
using System.Windows;

public class PdfDocumentProcessor
{
    public byte[] GeneratePdfFromHtml(string htmlContent)
    {
        // IronPDF's ChromePdfRenderer handles memory internally
        var renderer = new ChromePdfRenderer();

        // Configure rendering options
        renderer.RenderingOptions.MarginTop = 20;
        renderer.RenderingOptions.MarginBottom = 20;

        using (var pdf = renderer.RenderHtmlAsPdf(htmlContent))
        {
            // Document memory is managed within the using block
            return pdf.BinaryData;
        }
        // Resources released when exiting the using block
    }

    public void ProcessMultipleDocuments(string[] htmlContents, string outputDirectory)
    {
        var renderer = new ChromePdfRenderer();

        for (int i = 0; i < htmlContents.Length; i++)
        {
            // Each document is created and disposed in its own scope
            using (var pdf = renderer.RenderHtmlAsPdf(htmlContents[i]))
            {
                string outputPath = Path.Combine(outputDirectory, $"document_{i}.pdf");
                pdf.SaveAs(outputPath);
            }
            // Memory for this PDF is released before processing the next
        }
    }

    public byte[] MergePdfDocuments(byte[][] pdfDataArray)
    {
        using (var mergedPdf = new PdfDocument())
        {
            foreach (var pdfData in pdfDataArray)
            {
                using (var sourcePdf = new PdfDocument(pdfData))
                {
                    mergedPdf.AppendPdf(sourcePdf);
                }
                // Source PDF memory released after each append
            }

            return mergedPdf.BinaryData;
        }
    }
}

Key points about this code:

The using statement ensures proper disposal of PDF resources
Memory is released after each document operation, not accumulated
Multiple documents can be processed in sequence without memory growth
The ChromePdfRenderer instance can be reused across operations

API Reference

For more details on the methods used:

ChromePdfRenderer - HTML to PDF conversion with managed memory
PdfDocument - Document manipulation with proper disposal
Docker and Linux Deployment - Memory considerations for containerized environments

Migration Considerations

Moving from Syncfusion's WPF PdfViewerControl to IronPDF requires evaluating several factors.

Architecture Difference

Syncfusion's PdfViewerControl is a WPF UI component designed for displaying PDFs in a window. IronPDF is primarily a PDF generation and manipulation library. If you need an in-application PDF viewer, you would need to:

Use IronPDF to generate or process PDFs
Display them using a different approach (WebBrowser control, third-party viewer, or external application)

For scenarios where you are generating PDFs and then displaying them, IronPDF can handle the generation while a simpler viewer handles display.

Licensing

IronPDF is commercial software requiring a license for production use. A free trial is available for evaluation. Syncfusion also requires commercial licensing for most applications, so there may not be significant cost difference depending on your existing license.

API Differences

Syncfusion PdfViewerControl is primarily for display:

pdfViewer.Load("document.pdf");
pdfViewer.GotoPage(5);
pdfViewer.Print();

IronPDF is primarily for generation and manipulation:

var pdf = renderer.RenderHtmlAsPdf(html);
pdf.SaveAs("output.pdf");
pdf.GetPage(5);

What You Gain

Predictable memory behavior across long-running applications
Ability to process many documents in sequence
Modern HTML/CSS rendering via Chromium
Cross-platform support (Windows, Linux, macOS)

What to Consider

Need for a separate display solution if viewing is required
Learning curve for IronPDF's API
Different workflow for read-only document viewing scenarios

Conclusion

The memory leak issues in Syncfusion's WPF PdfViewerControl stem from architectural challenges in managing Pdfium's unmanaged memory within the WPF framework. For applications where reliable memory management is essential, particularly document processing systems handling multiple PDFs, IronPDF offers an alternative architecture with deterministic resource cleanup. Developers should evaluate their specific use case, weighing the need for an integrated viewer component against the memory stability benefits of a generation-focused library.

Jacob Mellor is CTO at Iron Software and leads the technical development of IronPDF.

References

Memory leak in WPF with PDF Viewer control when navigating away from the page{:rel="nofollow"} - Syncfusion Forums discussion of navigation-related memory issues (2023)
Memory leak while using pdfviewer control{:rel="nofollow"} - PdfStream memory retention report (2017)
PdfViewerControl crashes with Out Of Memory when trying to browse this big PDF{:rel="nofollow"} - Large document memory crash
Memory doesn't get freed after Print(){:rel="nofollow"} - Print operation memory retention
CPU utilization and memory leak from UWP SfPdfViewer even after closed it{:rel="nofollow"} - UWP viewer memory and CPU issues
Memory leak for syncfusion_flutter_pdfviewer{:rel="nofollow"} - GitHub issue documenting Flutter viewer memory leak
Severe memory leak in Xamarin.Forms PdfViewer{:rel="nofollow"} - Cross-platform memory issues

For the latest IronPDF documentation and tutorials, visit ironpdf.com.

Foxit PDF SDK vs IronPDF: the real-world comparison for 2026

IronSoftware — Fri, 08 May 2026 16:17:00 +0000

When enterprise .NET teams evaluate PDF libraries, performance characteristics often dominate requirements: how fast does HTML-to-PDF conversion execute under load? What memory footprint occurs with 500-page documents? Does the library scale horizontally in containerized environments? Foxit PDF SDK and IronPDF answer these questions differently—not because one is categorically faster, but because they optimize for distinct workflows and architectural patterns.

Foxit PDF SDK is a low-level PDF manipulation toolkit built for teams that need fine-grained control over PDF internals: accessing page content streams, modifying annotation appearances, or implementing custom rendering pipelines. IronPDF targets teams converting web content (HTML/CSS/JavaScript) into PDFs at scale, prioritizing developer velocity and rendering fidelity over granular PDF object manipulation.

Understanding IronPDF

IronPDF centers on a single core capability: rendering HTML to PDF using a Chromium engine. This architecture decision reflects modern .NET application patterns where content originates as HTML (Razor views, Angular components, React dashboards) rather than programmatically constructed PDF objects. The library handles CSS3 layout, JavaScript execution, and web font loading—features critical when converting SaaS dashboards or e-commerce receipts into distributable PDFs.

Beyond HTML rendering, IronPDF provides essential PDF operations: merging documents, extracting text, filling forms, applying digital signatures, and encrypting files. The API is deliberately high-level, abstracting PDF complexity so developers focus on business logic rather than PDF specification details.

Key Limitations of Foxit PDF SDK

Product Status

Active commercial product with regular updates. Requires licensing for production use. Trial version includes watermarks and 10-day limitation. Maintenance contract needed for continued support and redistribution rights after first year.

Missing Capabilities

No built-in HTML-to-PDF rendering engine in core SDK. HTML conversion available as add-on module (additional license). Limited out-of-the-box CSS support—teams must pre-render HTML or use conversion add-on. No integrated browser engine; cannot execute JavaScript during PDF generation without add-ons.

Technical Issues

Steeper learning curve: API exposes low-level PDF objects (Page, Annot, PDFDoc classes) requiring PDF specification knowledge. Native DLL dependencies complicate deployment—must match platform architecture (x86/x64/ARM). Resource management requires explicit disposal patterns; failure to properly dispose can cause memory leaks in long-running services.

Support Status

Commercial support available but requires active maintenance contract. Trial support limited. Response times depend on contract tier. Community resources less extensive than open-source alternatives.

Architecture Problems

Two-DLL architecture (native core + .NET wrapper) adds deployment complexity in containerized environments. HTML conversion requires separate add-on, fragmenting feature set. Font handling requires manual registration for non-system fonts. Threading model requires external synchronization for concurrent operations.

Feature Comparison Overview

Aspect	Foxit PDF SDK	IronPDF
Current Status	Active commercial product	Active commercial product
HTML Support	Add-on module (extra license)	Core feature (Chromium engine)
Rendering Quality	Native Foxit engine	Chromium-based rendering
Installation	Multi-DLL + native dependencies	Single NuGet + self-contained
Support	Commercial (contract-based)	Commercial with SLA options
Future Viability	Continuous updates	Continuous updates

Code Comparison: PDF Creation from Data

Foxit PDF SDK — Low-Level PDF Construction

// Conceptual example based on Foxit documentation
// Verify exact API in Foxit developer guides
using Foxit;
using Foxit.Common;
using Foxit.Common.Fxcrt;
using Foxit.Pdf;
using System;

namespace FoxitPdfExample
{
    class Program
    {
        static void Main(string[] args)
        {
            // Initialize library (license key required for production)
            ErrorCode error = Library.Initialize("SN", "KEY");
            if (error != ErrorCode.e_ErrSuccess)
            {
                Console.WriteLine("License initialization failed");
                return;
            }

            try
            {
                // Create new document
                using (PDFDoc doc = new PDFDoc())
                {
                    // Insert A4 page (595 x 842 points)
                    using (PDFPage page = doc.InsertPage(0, 595, 842))
                    {
                        // Get page content
                        // Note: Direct text/graphics manipulation requires
                        // understanding PDF content streams

                        // Example: Adding simple text (verify exact API)
                        // This is low-level and requires positioning calculations

                        // Foxit typically requires more setup for basic operations
                        // compared to HTML-based approaches

                        Console.WriteLine("Check Foxit docs for text/graphics API");
                    }

                    // Save document
                    doc.SaveAs("FoxitOutput.pdf");
                }
            }
            catch (Exception ex)
            {
                Console.WriteLine($"Error: {ex.Message}");
            }
            finally
            {
                Library.Release();
            }
        }
    }
}

Technical limitations:

Coordinate-based positioning: Text and graphics require manual X/Y coordinate calculation
No layout engine: No automatic text wrapping, table layout, or responsive design
PDF object knowledge required: Understanding page content streams, fonts, and resources necessary
Verbose API: Simple operations require multiple method calls and setup
Manual resource management: Explicit disposal patterns required to prevent memory leaks
No HTML input: Converting existing web content requires separate HTML-to-PDF add-on

IronPDF — HTML-Based PDF Creation

using IronPdf;
using System;
using System.Text;

namespace IronPdfDataExample
{
    class Program
    {
        static void Main(string[] args)
        {
            // Generate HTML from data (typical .NET pattern)
            var reportHtml = GenerateReportHtml();

            var renderer = new ChromePdfRenderer();
            renderer.RenderingOptions.PaperSize = IronPdf.Rendering.PdfPaperSize.A4;

            var pdf = renderer.RenderHtmlAsPdf(reportHtml);
            pdf.SaveAs("IronPdfOutput.pdf");

            Console.WriteLine("PDF created from HTML template");
            pdf.Dispose();
        }

        static string GenerateReportHtml()
        {
            var sb = new StringBuilder();
            sb.Append("<html><head><style>");
            sb.Append("body { font-family: Arial; margin: 40px; }");
            sb.Append("table { width: 100%; border-collapse: collapse; }");
            sb.Append("th, td { padding: 10px; border: 1px solid #ddd; text-align: left; }");
            sb.Append("th { background-color: #f0f0f0; }");
            sb.Append("</style></head><body>");
            sb.Append("<h1>Sales Report Q1 2026</h1>");
            sb.Append("<table><thead><tr><th>Month</th><th>Revenue</th><th>Growth</th></tr></thead>");
            sb.Append("<tbody>");
            sb.Append("<tr><td>January</td><td>$125,000</td><td>+12%</td></tr>");
            sb.Append("<tr><td>February</td><td>$138,000</td><td>+8%</td></tr>");
            sb.Append("<tr><td>March</td><td>$152,000</td><td>+15%</td></tr>");
            sb.Append("</tbody></table>");
            sb.Append("</body></html>");
            return sb.ToString();
        }
    }
}

IronPDF's HTML-first approach eliminates coordinate calculations and leverages standard CSS layout. For HTML to PDF workflows, review IronPDF's conversion guide.

Code Comparison: Form Field Manipulation

Foxit PDF SDK — Annotation and Form API

// Example based on Foxit documentation (verify API)
using Foxit.Pdf;
using Foxit.Pdf.Annots;
using System;

namespace FoxitFormExample
{
    class Program
    {
        static void Main(string[] args)
        {
            // Load existing PDF with form fields
            using (PDFDoc doc = new PDFDoc("FormTemplate.pdf"))
            {
                ErrorCode error = doc.Load(null);
                if (error != ErrorCode.e_ErrSuccess)
                {
                    Console.WriteLine("Failed to load PDF");
                    return;
                }

                using (PDFPage page = doc.GetPage(0))
                {
                    // Access form fields (verify exact API in Foxit docs)
                    // Form manipulation requires understanding
                    // AcroForm structure and field types

                    // Typical workflow:
                    // 1. Get form from document
                    // 2. Iterate through fields
                    // 3. Set field values by name/type
                    // 4. Save document

                    Console.WriteLine("Refer to Foxit Form API documentation");
                }

                doc.SaveAs("FilledForm.pdf");
            }
        }
    }
}

Technical limitations:

Complex form API: Requires understanding AcroForm vs XFA forms
Field type handling: Different APIs for text fields, checkboxes, radio buttons
No template-based filling: Must iterate fields manually and match by name
Validation logic: Field constraints must be implemented in application code
Error handling complexity: Many failure points require specific error checks

IronPDF — Form Filling from Data

using IronPdf;
using System;

namespace IronPdfFormExample
{
    class Program
    {
        static void Main(string[] args)
        {
            var pdf = PdfDocument.FromFile("FormTemplate.pdf");

            // Access form
            var form = pdf.Form;

            // Fill fields by name (auto-detects field types)
            form.SetFieldValue("CustomerName", "John Doe");
            form.SetFieldValue("Email", "john@example.com");
            form.SetFieldValue("AgreeToTerms", "true"); // Checkbox

            pdf.SaveAs("FilledForm.pdf");
            pdf.Dispose();

            Console.WriteLine("Form filled programmatically");
        }
    }
}

IronPDF abstracts form field complexity, auto-detecting types and handling conversions.

Code Comparison: Performance-Sensitive Batch Processing

Foxit PDF SDK — Batch Document Processing

using Foxit.Pdf;
using System;
using System.Diagnostics;
using System.IO;

namespace FoxitBatchExample
{
    class Program
    {
        static void Main(string[] args)
        {
            var inputFiles = Directory.GetFiles("input", "*.pdf");
            var stopwatch = Stopwatch.StartNew();

            foreach (var file in inputFiles)
            {
                using (PDFDoc doc = new PDFDoc(file))
                {
                    ErrorCode error = doc.Load(null);
                    if (error != ErrorCode.e_ErrSuccess) continue;

                    // Perform operations (watermark, extract text, etc.)
                    // Foxit excels at low-level manipulation of existing PDFs

                    var outputPath = Path.Combine("output", Path.GetFileName(file));
                    doc.SaveAs(outputPath);
                }
            }

            stopwatch.Stop();
            Console.WriteLine($"Processed {inputFiles.Length} files in {stopwatch.ElapsedMilliseconds}ms");
        }
    }
}

Performance characteristics (general patterns—verify through testing):

Native engine advantage: Foxit's C++ core may show benefits for pure PDF operations
Memory usage: Requires careful disposal to avoid accumulation
Startup overhead: Library initialization time may impact short-lived processes
Scaling pattern: Thread-safety requires external locks; scaling via multiple processes preferred

IronPDF — Batch HTML-to-PDF Conversion

using IronPdf;
using System;
using System.Diagnostics;
using System.IO;
using System.Linq;

namespace IronPdfBatchExample
{
    class Program
    {
        static void Main(string[] args)
        {
            var htmlFiles = Directory.GetFiles("templates", "*.html");
            var stopwatch = Stopwatch.StartNew();

            var renderer = new ChromePdfRenderer();
            renderer.RenderingOptions.EnableJavaScript = false; // Skip JS for speed if not needed

            foreach (var htmlFile in htmlFiles)
            {
                var html = File.ReadAllText(htmlFile);
                var pdf = renderer.RenderHtmlAsPdf(html);

                var outputPath = Path.Combine("output",
                    Path.GetFileNameWithoutExtension(htmlFile) + ".pdf");
                pdf.SaveAs(outputPath);
                pdf.Dispose();
            }

            stopwatch.Stop();
            Console.WriteLine($"Converted {htmlFiles.Length} files in {stopwatch.ElapsedMilliseconds}ms");
        }
    }
}

Performance characteristics (general patterns—verify through testing):

Chromium overhead: Browser engine initialization has fixed cost
Parallel processing: Can leverage multiple ChromePdfRenderer instances
Memory patterns: Chromium uses memory for rendering; batch size tuning recommended
Container efficiency: Runs well in Docker with adequate memory allocation

Note: Actual performance depends on document complexity, hardware, and .NET runtime version. Conduct benchmarks with representative workloads.

API Mapping Reference

Operation	Foxit PDF SDK	IronPDF	Notes
Initialize library	`Library.Initialize()`	None required	Foxit: explicit init; IronPDF: auto
Create document	`new PDFDoc()`	`ChromePdfRenderer.RenderHtmlAsPdf()`	Foxit: object model; IronPDF: render
Add page	`doc.InsertPage(index, width, height)`	HTML page breaks	Foxit: manual; IronPDF: CSS
Set page size	Page constructor parameters	`RenderingOptions.PaperSize`	Different approaches
Add text	Low-level content API	HTML `<p>`, `<div>`, etc.	Foxit: coordinates; IronPDF: markup
Add images	`PDFImage` API	HTML `<img>` tag	Foxit: object; IronPDF: tag
Create form fields	Annotation API	`CreatePdfFormsFromHtml`	Foxit: programmatic; IronPDF: HTML-based
Fill forms	Form field iteration	`Form.SetFieldValue()`	Both supported
Merge PDFs	Not in core	`PdfDocument.Merge()`	IronPDF: built-in
Extract text	Text page API	`PdfDocument.ExtractAllText()`	Both supported
Digital signatures	Signature API	`PdfDocument.Sign()`	Both supported
Encryption	Security handler	`PdfDocument.Encrypt()`	Both supported

Comprehensive Feature Comparison

Feature	Foxit PDF SDK	IronPDF
Status
Active Development	Yes	Yes
Licensing Model	Commercial + maintenance	Commercial
Support
Commercial Support	Contract-based	Included
Documentation	Extensive technical docs	Comprehensive with examples
Code Samples	Developer portal	Extensive library
Content Creation
HTML to PDF	Add-on module	Core feature
Programmatic Layout	Low-level API	N/A (HTML-based)
Modern CSS	Limited (via add-on)	Full CSS3
JavaScript	Via add-on	Yes
PDF Operations
View PDFs	Yes (UI components)	No viewer component
Edit PDFs	Comprehensive	Standard operations
Annotate	Full annotation API	Basic support
Merge/Split	Yes	Yes
Extract Text	Yes	Yes
Forms	Full AcroForm/XFA	AcroForm support
Digital Signatures	Yes	Yes
Security
Encryption	Full support	AES 128/256
Password Protection	Yes	Yes
Permissions	Granular control	Standard permissions
Development
.NET Framework	4.0+	4.6.2+
.NET Core	2.1+	3.1+
.NET 5+	Yes	Yes
Linux	Yes (x64, ARM)	Yes
macOS	Yes (x64, ARM64 in v11)	Yes
Docker	Yes	Yes

Deployment Considerations

Foxit PDF SDK

Native dependencies: Requires fsdk.dll and platform-specific managed wrapper
Platform targeting: Must match architecture (x86/x64/ARM/AnyCPU)
Docker images: Include native libraries in image layers
License files: Manage license key deployment separately
Size overhead: Native engine increases deployment package size

IronPDF

Self-contained: NuGet package includes Chromium binaries
Platform detection: Auto-selects correct binaries for runtime platform
Docker: Standard .NET Core Docker images work without modification
License: Managed via embedded key or configuration
Size overhead: Chromium engine adds ~100-150MB to deployment

Installation Comparison

Foxit PDF SDK

dotnet add package Foxit.SDK.Dotnet

using Foxit;
using Foxit.Common;
using Foxit.Pdf;

// Initialize library with license
Library.Initialize("SERIAL_NUMBER", "LICENSE_KEY");
// ... operations ...
Library.Release();

IronPDF

dotnet add package IronPdf

using IronPdf;

// Optional: Set license key
// IronPdf.License.LicenseKey = "YOUR-KEY";

// Use directly - no initialization required

Conclusion

Foxit PDF SDK and IronPDF target different points on the PDF capability spectrum. Foxit excels when applications require low-level PDF object manipulation—custom annotation rendering, fine-grained page content access, or viewer component integration. Teams with existing Foxit deployments benefit from comprehensive annotation APIs and mature PDF engine optimization.

IronPDF optimizes for the dominant modern use case: converting dynamic web content into PDFs at scale. The HTML-first architecture eliminates coordinate calculations and leverages CSS layout engines that most .NET developers already know. For greenfield projects or teams modernizing HTML-to-PDF workflows, IronPDF's Chromium engine delivers browser-quality rendering without add-on licensing.

Migration drivers: if your codebase manually calculates text positions or struggles with HTML conversion add-on complexity, IronPDF's unified approach reduces code. If you need advanced annotation workflows or PDF viewer components, Foxit's specialized APIs may remain the better fit.

What PDF operations consume most of your development time—content creation or manipulation of existing documents?

Understand IronPDF's HTML-to-PDF approach: Complete HTML to PDF guide
Explore IronPDF's comprehensive capabilities: C# PDF library tutorial

Rotativa vs IronPDF: what the docs do not tell you

IronSoftware — Fri, 08 May 2026 13:21:00 +0000

You're building an ASP.NET Core MVC application. Product owners want "Export to PDF" buttons on reports. You search ".NET MVC PDF" and Rotativa appears with clean examples showing return new ViewAsPdf(). It looks simple—until you deploy to Linux and discover wkhtmltopdf binary incompatibilities, or move to Azure App Service and hit file permission errors, or try to generate PDFs outside controller actions and find the API doesn't support it. Rotativa is a convenient wrapper for ASP.NET MVC controllers, but it's architecturally constrained to web request contexts and carries the operational complexity of managing the wkhtmltopdf binary.

This comparison exists because Rotativa and IronPDF both generate PDFs from HTML in .NET, but they make fundamentally different architectural choices. Rotativa wraps wkhtmltopdf (an external Qt WebKit-based command-line tool) for MVC controller convenience. IronPDF embeds a Chromium rendering engine as a library component. For teams evaluating "ASP.NET PDF generation," this comparison provides decision checklists covering deployment requirements, architectural constraints, and feature completeness to determine which tool fits your stack.

Canonical/source version: This article is also available at IronPDF's comparison guides.

Understanding IronPDF

IronPDF is a .NET library with an embedded Chromium rendering engine. It works in any .NET application context: MVC controllers, background services, console apps, Azure Functions, worker processes. You call ChromePdfRenderer.RenderHtmlAsPdf() from any code location, and IronPDF handles HTML parsing, CSS layout, JavaScript execution, and PDF generation in-process. No external binaries to manage, no command-line tool invocations, no temporary file handling. IronPDF runs on Windows, Linux, and macOS without platform-specific binary dependencies.

IronPDF supports .NET Core, .NET 5+, and .NET Framework 4.6.2+. Because it's a library, not a controller helper, it integrates with any architecture: microservices generating PDFs asynchronously, batch processors creating reports overnight, API endpoints streaming PDFs to clients, or background jobs rendering thousands of documents. See the HTML to PDF tutorial for implementation patterns.

Understanding Rotativa

Rotativa (and Rotativa.AspNetCore) is an ASP.NET MVC library that wraps wkhtmltopdf, a Qt WebKit-based command-line tool for HTML-to-PDF conversion. Rotativa provides convenience methods like ViewAsPdf, UrlAsPdf, and ActionAsPdf that return ActionResult objects from MVC controllers. The library handles invoking wkhtmltopdf as an external process, passing HTML content via temporary files, and streaming the resulting PDF back to the HTTP response.

Rotativa is designed specifically for MVC controllers responding to web requests. It simplifies the common pattern of "render Razor view → convert to PDF → return to browser." However, this convenience comes with constraints: tight coupling to MVC request contexts, dependency on wkhtmltopdf binaries in specific file system locations, and limited support for non-web scenarios (background jobs, API services, console apps).

Key Limitations of Rotativa

Product Status

Rotativa.AspNetCore is actively maintained (version 1.4.0 latest, updated 2024). The original Rotativa for .NET Framework is in maintenance mode with limited updates. The project has community adoption and works well for its designed use case (MVC controllers generating PDFs). However, it inherits wkhtmltopdf's limitations: wkhtmltopdf itself is in maintenance mode (last major release 2020) with minimal active development on its Qt WebKit rendering engine.

Missing Capabilities

MVC-only architecture: Rotativa's API is built around ActionResult types and MVC controller contexts. Generating PDFs outside controller actions (background jobs, console apps, Azure Functions) requires workarounds or alternative approaches. You cannot easily use Rotativa in non-web architectures.

No PDF manipulation features: Rotativa generates PDFs but does not merge them, split them, extract text, add watermarks programmatically, apply digital signatures, fill forms, or encrypt with passwords. For post-generation operations, you need additional libraries.

Limited rendering engine: Rotativa uses wkhtmltopdf's Qt WebKit engine, which is based on WebKit from ~2015. It does not support modern CSS features like Grid or Flexbox consistently, has limited JavaScript ES6+ support, and may render differently from current Chrome. For cutting-edge web standards, wkhtmltopdf lags behind Chromium.

Technical Issues

Binary management complexity: Rotativa requires wkhtmltopdf executables in a specific folder structure (typically wwwroot/Rotativa or configured path). These binaries are platform-specific (Windows .exe, Linux binaries with library dependencies). Managing binaries across development, staging, and production environments adds deployment friction.

File system dependencies: Rotativa writes temporary HTML files to disk, invokes wkhtmltopdf as an external process, and reads the resulting PDF from disk. In read-only file systems (some cloud environments, immutable containers), this causes failures. Azure App Service, AWS Lambda, and Kubernetes pods with restricted write permissions require careful configuration.

External process overhead: Every PDF generation spawns a wkhtmltopdf process. Process creation overhead (~50-100 ms on Linux, ~100-200 ms on Windows) adds latency. For high-throughput scenarios, this overhead compounds. Process cleanup must be reliable; leaked processes consume memory.

Support Status

Rotativa.AspNetCore has community support via GitHub issues. Maintainer (Giorgio Bozio) is responsive for major bugs. However, there is no commercial support offering, no SLA for bug fixes, and no 24/7 engineering assistance. For production issues, you're self-service via GitHub discussions and Stack Overflow. Additionally, wkhtmltopdf (the underlying renderer) is in maintenance mode with no active feature development, meaning rendering bugs or missing CSS features are unlikely to be fixed.

Architecture Problems

Tight coupling to MVC request pipeline: Rotativa's convenience methods (ViewAsPdf, ActionAsPdf) require ControllerContext and depend on MVC infrastructure. Background services, console apps, or microservices without MVC pipelines must manually construct contexts or find alternative approaches.

No async-first design: Rotativa's BuildFile method is synchronous. For async controllers or high-concurrency scenarios, this blocks threads during process invocation and file I/O, reducing scalability.

Configuration via static methods: Rotativa configuration (RotativaConfiguration.Setup()) uses static state, which is less testable and can cause issues in multi-tenant or per-request configuration scenarios.

Feature Comparison Overview

Category	Rotativa	IronPDF
Current Status	Actively maintained (1.4.0 latest for AspNetCore)	Actively maintained, commercial with 30-day trial
HTML Support	Qt WebKit (circa 2015 standards) via wkhtmltopdf	Modern Chrome HTML5/CSS3/JS (embedded Chromium)
Rendering Quality	Good for pre-2015 CSS; limited Grid/Flexbox	Pixel-perfect Chrome rendering (modern CSS, JS)
Installation	NuGet + wkhtmltopdf binary (platform-specific)	NuGet with embedded engine (self-contained)
Support	Community via GitHub issues	24/5 engineer support (24/7 premium), live chat
Future Viability	Tied to wkhtmltopdf (maintenance mode)	Commercial backing, enterprise SLAs

Architecture Decision Checklist

Use this checklist to determine which tool fits your application architecture:

✅ Consider Rotativa if you answer YES to ALL:

[ ] Your application is ASP.NET Core MVC or .NET Framework MVC
[ ] PDFs are only generated from HTTP controller actions
[ ] You have file system write access in all deployment environments
[ ] Your HTML/CSS uses pre-2015 web standards (no CSS Grid, minimal Flexbox)
[ ] You can manage platform-specific binaries (wkhtmltopdf) in deployments
[ ] You only need basic PDF generation (no merging, watermarking, signing, etc.)
[ ] You're comfortable with community support and no commercial SLA

✅ Consider IronPDF if you answer YES to ANY:

[ ] You generate PDFs outside MVC controllers (background jobs, console apps, APIs)
[ ] You need modern CSS support (Grid, Flexbox, custom properties)
[ ] Your deployment is read-only file systems or restricted environments
[ ] You require PDF manipulation (merge, split, watermark, sign, encrypt)
[ ] You need cross-platform deployments without binary management
[ ] You want commercial support with SLAs
[ ] Your application uses Docker, Kubernetes, or serverless functions (Azure Functions, AWS Lambda)
[ ] You need async-first PDF generation with high concurrency

Code Comparison: Basic MVC PDF Generation

Rotativa — MVC Controller Action

Rotativa shines in its primary use case: returning PDFs from MVC controller actions. Here's a complete example:

using Microsoft.AspNetCore.Mvc;
using Rotativa.AspNetCore;
using Rotativa.AspNetCore.Options;
using System;
using System.Collections.Generic;

namespace MyApp.Controllers
{
    public class ReportController : Controller
    {
        public class ReportData
        {
            public string Title { get; set; }
            public DateTime GeneratedDate { get; set; }
            public List<ReportItem> Items { get; set; }
        }

        public class ReportItem
        {
            public string ProductName { get; set; }
            public int Quantity { get; set; }
            public decimal UnitPrice { get; set; }
            public decimal Total => Quantity * UnitPrice;
        }

        // Return PDF directly from controller action
        public IActionResult GeneratePdf()
        {
            var model = new ReportData
            {
                Title = "Q4 Sales Report",
                GeneratedDate = DateTime.Now,
                Items = new List<ReportItem>
                {
                    new ReportItem { ProductName = "Widget A", Quantity = 100, UnitPrice = 25.50m },
                    new ReportItem { ProductName = "Gadget B", Quantity = 50, UnitPrice = 47.99m }
                }
            };

            // Rotativa convenience: render Razor view as PDF
            return new ViewAsPdf("ReportTemplate", model)
            {
                FileName = $"report-{DateTime.Now:yyyyMMdd}.pdf",
                PageSize = Size.A4,
                PageOrientation = Orientation.Portrait,
                PageMargins = new Margins(10, 10, 10, 10),
                // Additional wkhtmltopdf options
                CustomSwitches = "--enable-local-file-access"
            };
        }

        // For saving to disk instead of returning to browser
        public IActionResult SavePdfToDisk()
        {
            var model = new ReportData
            {
                Title = "Q4 Sales Report",
                GeneratedDate = DateTime.Now,
                Items = new List<ReportItem>
                {
                    new ReportItem { ProductName = "Widget A", Quantity = 100, UnitPrice = 25.50m }
                }
            };

            var pdf = new ViewAsPdf("ReportTemplate", model)
            {
                PageSize = Size.A4
            };

            // BuildFile is synchronous, blocks thread during generation
            byte[] pdfBytes = pdf.BuildFile(ControllerContext);
            System.IO.File.WriteAllBytes("output.pdf", pdfBytes);

            return Ok("PDF saved to disk");
        }
    }
}

Corresponding Razor view (Views/Report/ReportTemplate.cshtml):

@model MyApp.Controllers.ReportController.ReportData

<!DOCTYPE html>
<html>
<head>
    <style>
        body { font-family: Arial, sans-serif; margin: 40px; }
        h1 { color: #333; }
        table { width: 100%; border-collapse: collapse; margin-top: 20px; }
        th, td { padding: 10px; border: 1px solid #ddd; text-align: left; }
        .total { text-align: right; font-weight: bold; }
    </style>
</head>
<body>
    <h1>@Model.Title</h1>
    <p>Generated: @Model.GeneratedDate.ToString("yyyy-MM-dd")</p>
    <table>
        <thead>
            <tr><th>Product</th><th>Qty</th><th>Price</th><th>Total</th></tr>
        </thead>
        <tbody>
            @foreach (var item in Model.Items)
            {
                <tr>
                    <td>@item.ProductName</td>
                    <td>@item.Quantity</td>
                    <td>$@item.UnitPrice.ToString("F2")</td>
                    <td class="total">$@item.Total.ToString("F2")</td>
                </tr>
            }
        </tbody>
    </table>
</body>
</html>

Setup required (Program.cs for .NET 6+):

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddControllersWithViews();

var app = builder.Build();
app.UseRouting();

// Configure Rotativa (points to wkhtmltopdf binary location)
IWebHostEnvironment env = app.Environment;
Rotativa.AspNetCore.RotativaConfiguration.Setup(env.WebRootPath, "Rotativa");

app.MapControllerRoute(
    name: "default",
    pattern: "{controller=Home}/{action=Index}/{id?}");

app.Run();

Deployment checklist for Rotativa:

[ ] wkhtmltopdf binaries in wwwroot/Rotativa folder (Windows: wkhtmltopdf.exe, Linux: wkhtmltopdf)
[ ] Linux: Install dependencies (libgdiplus, libfontconfig1, X11 libraries)
[ ] File system write permissions for temp file creation
[ ] Process execution permissions (wkhtmltopdf must be executable)
[ ] Network access if HTML references external resources

Technical limitations:

MVC dependency: Cannot easily use outside controller actions.
Synchronous BuildFile: Blocks threads during generation (50-500 ms depending on complexity).
Binary management: Must ship correct wkhtmltopdf binary for deployment platform.
Read-only file system issues: Fails in Azure App Service (Windows), AWS Lambda, Kubernetes pods without temp directory configuration.
No PDF manipulation: Generated PDF cannot be merged, watermarked, or signed within Rotativa—requires external libraries.

IronPDF — Any Context (MVC, Background, Console)

IronPDF works in any .NET context. Here's the same report in an MVC controller:

using IronPdf;
using Microsoft.AspNetCore.Mvc;
using System;
using System.Collections.Generic;

namespace MyApp.Controllers
{
    public class ReportController : Controller
    {
        public class ReportData
        {
            public string Title { get; set; }
            public DateTime GeneratedDate { get; set; }
            public List<ReportItem> Items { get; set; }
        }

        public class ReportItem
        {
            public string ProductName { get; set; }
            public int Quantity { get; set; }
            public decimal UnitPrice { get; set; }
            public decimal Total => Quantity * UnitPrice;
        }

        // Generate PDF and return to browser
        public IActionResult GeneratePdf()
        {
            var model = new ReportData
            {
                Title = "Q4 Sales Report",
                GeneratedDate = DateTime.Now,
                Items = new List<ReportItem>
                {
                    new ReportItem { ProductName = "Widget A", Quantity = 100, UnitPrice = 25.50m },
                    new ReportItem { ProductName = "Gadget B", Quantity = 50, UnitPrice = 47.99m }
                }
            };

            // Build HTML (could also render Razor view to string)
            var html = $@"
                <!DOCTYPE html>
                <html>
                <head>
                    <style>
                        body {{ font-family: Arial, sans-serif; margin: 40px; }}
                        h1 {{ color: #333; }}
                        table {{ width: 100%; border-collapse: collapse; margin-top: 20px; }}
                        th, td {{ padding: 10px; border: 1px solid #ddd; text-align: left; }}
                        .total {{ text-align: right; font-weight: bold; }}
                    </style>
                </head>
                <body>
                    <h1>{model.Title}</h1>
                    <p>Generated: {model.GeneratedDate:yyyy-MM-dd}</p>
                    <table>
                        <thead>
                            <tr><th>Product</th><th>Qty</th><th>Price</th><th>Total</th></tr>
                        </thead>
                        <tbody>
                            {string.Join("", model.Items.Select(item => $@"
                            <tr>
                                <td>{item.ProductName}</td>
                                <td>{item.Quantity}</td>
                                <td>${item.UnitPrice:F2}</td>
                                <td class='total'>${item.Total:F2}</td>
                            </tr>"))}
                        </tbody>
                    </table>
                </body>
                </html>
            ";

            // Generate PDF (no external process, no temp files)
            var renderer = new ChromePdfRenderer();
            using var pdf = renderer.RenderHtmlAsPdf(html);

            // Return as file to browser
            return File(pdf.BinaryData, "application/pdf", $"report-{DateTime.Now:yyyyMMdd}.pdf");
        }

        // Async version for high-concurrency scenarios
        public async Task<IActionResult> GeneratePdfAsync()
        {
            var model = new ReportData
            {
                Title = "Q4 Sales Report",
                GeneratedDate = DateTime.Now,
                Items = new List<ReportItem>
                {
                    new ReportItem { ProductName = "Widget A", Quantity = 100, UnitPrice = 25.50m }
                }
            };

            var html = $@"<!DOCTYPE html><html><body><h1>{model.Title}</h1></body></html>";

            var renderer = new ChromePdfRenderer();
            using var pdf = await renderer.RenderHtmlAsPdfAsync(html);

            return File(pdf.BinaryData, "application/pdf", "report.pdf");
        }
    }
}

Deployment checklist for IronPDF:

[ ] None—just add NuGet package

Technical advantages:

No MVC dependency: Same code works in console apps, background services, Azure Functions.
Async support: RenderHtmlAsPdfAsync() for non-blocking generation.
No binary management: Embedded Chromium engine, no external files required.
Works in read-only file systems: No temp file writes.
PDF manipulation: Can merge, watermark, sign, encrypt in the same library—see merge/split guide.

IronPDF also works outside MVC contexts. Example background service:

public class ReportGenerationService : BackgroundService
{
    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        while (!stoppingToken.IsCancellationRequested)
        {
            // Generate nightly reports
            var renderer = new ChromePdfRenderer();
            using var pdf = await renderer.RenderHtmlAsPdfAsync("<h1>Nightly Report</h1>");
            pdf.SaveAs($"reports/nightly-{DateTime.Now:yyyyMMdd}.pdf");

            await Task.Delay(TimeSpan.FromHours(24), stoppingToken);
        }
    }
}

Rotativa cannot easily support this pattern without controller contexts.

Code Comparison: Applying Watermarks

Rotativa — No Built-in Watermark API

Rotativa does not provide watermark functionality. Watermarks must be added to the HTML itself or applied post-generation with external libraries:

using Microsoft.AspNetCore.Mvc;
using Rotativa.AspNetCore;
using Rotativa.AspNetCore.Options;

public class ReportController : Controller
{
    public IActionResult GeneratePdfWithWatermark()
    {
        // Watermark must be in HTML/CSS (not a true PDF watermark)
        var html = @"
            <!DOCTYPE html>
            <html>
            <head>
                <style>
                    body { font-family: Arial; margin: 40px; position: relative; }
                    .watermark {
                        position: fixed;
                        top: 50%;
                        left: 50%;
                        transform: translate(-50%, -50%) rotate(-45deg);
                        font-size: 72px;
                        color: rgba(200, 200, 200, 0.3);
                        z-index: -1;
                        white-space: nowrap;
                    }
                </style>
            </head>
            <body>
                <div class='watermark'>CONFIDENTIAL</div>
                <h1>Quarterly Financial Report</h1>
                <p>This document contains sensitive information.</p>
            </body>
            </html>
        ";

        // Generate PDF with HTML watermark (not a true PDF watermark layer)
        return new ViewAsPdf
        {
            ViewName = "WatermarkTemplate", // Or use SetContentAsync if passing HTML string
            PageSize = Size.A4
        };
    }
}

Technical limitations:

Not a true PDF watermark: This is HTML styled to look like a watermark. It's part of page content, not a PDF annotation layer.
No post-generation watermark: Cannot apply watermarks to already-generated PDFs without external libraries.
No opacity/rotation control: Limited to CSS capabilities, which may not render consistently across wkhtmltopdf versions.
No per-page variation: All pages get the same watermark; no dynamic per-page watermarks.

To apply true PDF watermarks to Rotativa-generated PDFs, you must use external libraries like iText, PdfSharp, or IronPDF post-generation.

IronPDF — Built-in Watermark API

IronPDF provides dedicated watermarking methods:

using IronPdf;

public class ReportController : Controller
{
    public IActionResult GeneratePdfWithWatermark()
    {
        // Generate or load PDF
        var renderer = new ChromePdfRenderer();
        using var pdf = renderer.RenderHtmlAsPdf(@"
            <h1>Quarterly Financial Report</h1>
            <p>This document contains sensitive information.</p>
        ");

        // Apply true PDF watermark (annotation layer, not page content)
        pdf.ApplyWatermark("<div style='font-size: 72px; color: #cccccc; font-weight: bold;'>CONFIDENTIAL</div>", 
            rotation: -45, 
            opacity: 30);

        return File(pdf.BinaryData, "application/pdf", "report-watermarked.pdf");
    }
}

IronPDF watermarks are true PDF annotation layers with configurable rotation, opacity, and positioning. See watermarking guide for advanced scenarios.

Deployment Checklist

Rotativa Deployment Requirements

File System Setup:

[ ] Create wwwroot/Rotativa folder (or configured path)
[ ] Copy platform-specific wkhtmltopdf binary:
- Windows: wkhtmltopdf.exe (~50 MB)
- Linux: wkhtmltopdf binary (~50 MB)
[ ] Ensure binaries are executable (Linux: chmod +x wkhtmltopdf)
[ ] Configure RotativaConfiguration.Setup(env, "Rotativa") in Program.cs

Linux Dependencies (typically required):

# Ubuntu/Debian
apt-get update
apt-get install -y \
    libgdiplus \
    libfontconfig1 \
    libxrender1 \
    libxext6 \
    libx11-6 \
    libssl1.1

# Alpine (lighter, but more dependencies)
apk add --no-cache \
    libgdiplus \
    libstdc++ \
    fontconfig \
    freetype

Azure App Service:

[ ] Add wkhtmltopdf binaries to D:\home\site\wwwroot\Rotativa
[ ] Verify write permissions for temp directory (D:\local\Temp)
[ ] May require custom deployment scripts to ensure binaries are deployed

Docker:

FROM mcr.microsoft.com/dotnet/aspnet:8.0

# Install wkhtmltopdf dependencies
RUN apt-get update && apt-get install -y \
    wkhtmltopdf \
    libgdiplus \
    libfontconfig1

WORKDIR /app
COPY . .
ENTRYPOINT ["dotnet", "MyApp.dll"]

Kubernetes:

[ ] Base image must include wkhtmltopdf and dependencies
[ ] Persistent volume or init container to copy binaries
[ ] Writable temp directory mounted

Failure Modes:

"wkhtmltopdf not found" → Binary missing or wrong path
"Permission denied" → Binary not executable (Linux)
"Cannot open display" → Missing X11 dependencies (Linux)
"Failed to load PDF" → Temp directory not writable

IronPDF Deployment Requirements

All Platforms:

[ ] Add IronPdf NuGet package

That's it. No binaries, no dependencies, no configuration.

Docker:

FROM mcr.microsoft.com/dotnet/aspnet:8.0

WORKDIR /app
COPY . .
ENTRYPOINT ["dotnet", "MyApp.dll"]

Kubernetes:

Standard .NET deployment—no special requirements

Azure App Service / AWS Lambda / Google Cloud Run:

Works out-of-box with no configuration

API Mapping Reference

Operation	Rotativa API	IronPDF API
Render Razor view to PDF	`new ViewAsPdf("ViewName", model)`	Render view to string, then `ChromePdfRenderer.RenderHtmlAsPdf()`
Render HTML string to PDF	`new HtmlAsPdf() { ViewData = html }`	`ChromePdfRenderer.RenderHtmlAsPdf(html)`
Render URL to PDF	`new UrlAsPdf("https://example.com")`	`ChromePdfRenderer.RenderUrlAsPdf("https://example.com")`
Set page size	`PageSize = Size.A4`	`RenderingOptions.PaperSize = PdfPaperSize.A4`
Set margins	`PageMargins = new Margins(10, 10, 10, 10)`	`RenderingOptions.MarginTop/Bottom/Left/Right`
Return PDF to browser	Return `ViewAsPdf` from controller	Return `File(pdf.BinaryData, "application/pdf")`
Save PDF to disk	`pdf.BuildFile(ControllerContext)`	`pdf.SaveAs("path/to/file.pdf")`
Async generation	Not supported (BuildFile is synchronous)	`await RenderHtmlAsPdfAsync()`
Apply watermark	Not supported (use HTML/CSS)	`pdf.ApplyWatermark()` or `pdf.ApplyStamp()`
Merge PDFs	Not supported	`PdfDocument.Merge()`
Extract text	Not supported	`PdfDocument.ExtractAllText()`
Digital signature	Not supported	`PdfDocument.Sign()`
Password protection	Not supported	`SecuritySettings.UserPassword/OwnerPassword`

Comprehensive Feature Comparison

Category	Feature	Rotativa	IronPDF
Status	Active development	Yes (1.4.0 latest for AspNetCore)	Yes
	Commercial support	Community support only	24/5 engineer support (24/7 premium)
	Underlying engine status	wkhtmltopdf (maintenance mode, 2020)	Chromium (actively updated)
Support	Documentation quality	Good (MVC-focused examples)	Extensive (tutorials, how-tos, API reference)
	Response time	Community-dependent (GitHub issues)	<1 min median chat response
Content Creation	HTML rendering	Qt WebKit via wkhtmltopdf (~2015 standards)	Modern Chromium (full HTML5, CSS3, ES6+)
	CSS Grid support	Limited/inconsistent	Full support
	Flexbox support	Partial	Full support
	JavaScript execution	Limited (older engine)	Full modern JavaScript (ES6+, async/await)
	External binary required	Yes (wkhtmltopdf, ~50 MB)	No (embedded engine)
Architecture	MVC controller support	Excellent (primary use case)	Supported (via File() return)
	Background service support	Difficult (requires ControllerContext workarounds)	Native support
	Console app support	Difficult	Native support
	Azure Functions / Lambda	Difficult (binary management, temp files)	Native support
	Async/await support	No (BuildFile is synchronous)	Yes (RenderHtmlAsPdfAsync)
PDF Operations	Merge PDFs	No	Yes
	Split PDFs	No	Yes (extract pages)
	Add watermarks	No (HTML only)	Yes (true PDF watermarks)
	Digital signatures	No	Yes
	Form filling	No	Yes
	Extract text	No	Yes
	Password protection	No	Yes
Deployment	Binary management	Required (wkhtmltopdf)	Not required
	Linux dependencies	Many (X11, fontconfig, etc.)	None
	Read-only file systems	Fails (needs temp directory)	Supported
	Docker complexity	Medium (base image + deps)	Low (standard .NET image)
	Azure App Service	Requires configuration	Works out-of-box
Known Issues	wkhtmltopdf maintenance mode	Yes (no feature development)	N/A
	Modern CSS support	Limited (pre-2015)	Full (current Chromium)
	File permission errors	Common in cloud/container environments	Rare
	Synchronous blocking	Yes (BuildFile)	No (async support)
Development	Learning curve	Low (if familiar with MVC)	Low (HTML-focused API)
	.NET Core 3.1, 5, 6, 7, 8	Yes	Yes
	.NET Framework 4.6.2+	Yes (via Rotativa)	Yes
	Linux support	Yes (with dependencies)	Yes (native)
	macOS support	Limited	Yes

Decision Matrix

Use this matrix to score your requirements:

Requirement	Rotativa Score	IronPDF Score
Only MVC controllers	✅✅✅ (Excellent fit)	✅✅ (Supported)
Background jobs / console apps	❌ (Difficult)	✅✅✅ (Native)
Modern CSS (Grid, Flexbox)	⚠️ (Limited)	✅✅✅ (Full support)
Read-only file systems	❌ (Fails)	✅✅✅ (Supported)
Cross-platform (Linux, macOS)	⚠️ (Requires dependencies)	✅✅✅ (Native)
PDF manipulation (merge, watermark)	❌ (Not supported)	✅✅✅ (Built-in)
Async/await for high concurrency	❌ (Synchronous only)	✅✅✅ (Full async)
Commercial support / SLA	❌ (Community only)	✅✅✅ (24/5 or 24/7)
No binary management	❌ (Requires wkhtmltopdf)	✅✅✅ (Embedded engine)
Simple MVC setup	✅✅✅ (Purpose-built)	✅✅ (Straightforward)

Scoring key: ✅✅✅ Excellent | ✅✅ Good | ✅ Acceptable | ⚠️ Requires workarounds | ❌ Not supported/difficult

Installation Comparison

Rotativa

# Install via NuGet
dotnet add package Rotativa.AspNetCore

# Or via Package Manager Console
Install-Package Rotativa.AspNetCore

Additional setup required:

Create wwwroot/Rotativa folder
Download wkhtmltopdf binary for your platform
Copy binary to wwwroot/Rotativa folder
Configure in Program.cs:

using Rotativa.AspNetCore;

var app = builder.Build();
IWebHostEnvironment env = app.Environment;
RotativaConfiguration.Setup(env.WebRootPath, "Rotativa");

On Linux, install dependencies (see deployment checklist above)

IronPDF

# Install via NuGet
dotnet add package IronPdf

# Or via Package Manager Console
Install-Package IronPdf

That's it. No additional setup, no binaries, no dependencies.

Conclusion

Rotativa is a specialized tool for ASP.NET MVC applications that need simple "Export to PDF" buttons on web pages. If your application is MVC-only, you have file system write access, and your HTML uses pre-2015 CSS standards, Rotativa's convenience methods (ViewAsPdf, ActionAsPdf) provide quick integration. The project is actively maintained for its core use case, and the community support is reasonable for straightforward scenarios.

However, Rotativa's architectural constraints become friction points when your requirements expand. Background services, console apps, Azure Functions, and serverless architectures require workarounds. Modern CSS features (Grid, Flexbox) render inconsistently. Read-only file systems in cloud environments cause deployment failures. Post-generation operations (merging, watermarking, signing) require external libraries. The dependency on wkhtmltopdf—a maintenance-mode project with a 2015-era rendering engine—limits future viability for cutting-edge web standards.

IronPDF's embedded Chromium architecture eliminates these constraints. It works in any .NET context (MVC, background services, console apps, functions), supports modern HTML5/CSS3/JavaScript standards, requires no binary management, and includes comprehensive PDF manipulation features in a single library. The async-first API scales for high-concurrency scenarios, and 24/5 commercial support (24/7 premium) provides production confidence. For teams building beyond simple MVC controller actions or deploying to modern cloud/container environments, IronPDF's library-based approach is the pragmatic choice.

Does your application architecture fit Rotativa's MVC-only constraints, or do you need the flexibility of a general-purpose PDF library?

Further reading:

Syncfusion .NET Core Linux Deployment: Fixing libgdiplus, Font, and Docker Issues

IronSoftware — Fri, 08 May 2026 10:39:00 +0000

When deploying Syncfusion document processing libraries to Linux environments, developers frequently encounter a cascade of initialization failures, missing dependencies, and rendering problems. These issues manifest as cryptic exceptions during runtime, font substitution problems in generated documents, and memory leaks in containerized deployments.

The Problem

Syncfusion's document processing libraries for .NET Core rely on native dependencies that behave differently across operating systems. On Windows, System.Drawing.Common provides graphics functionality through GDI+. On Linux, this same functionality requires libgdiplus, an open-source implementation maintained by the Mono project. Additionally, Syncfusion's PDF Viewer and HTML-to-PDF converter depend on PDFium and the Blink rendering engine respectively, each with their own platform-specific requirements.

The core issues stem from three areas: native library dependencies that must be manually installed on Linux, font availability differences between Windows and Linux environments, and permission constraints in containerized deployments.

Error Messages and Symptoms

Developers report several common exceptions when running Syncfusion document processing on Linux:

System.TypeInitializationException: The type initializer for 'Gdip' threw an exception.
---> System.DllNotFoundException: Unable to load shared library 'gdiplus' or one of its dependencies.

System.TypeInitializationException: The type initializer for 'Syncfusion.EJ2.PdfViewer.PdfiumNative' threw an exception.
---> System.DllNotFoundException: Unable to load shared library 'libpdfium.so' or one of its dependencies.

PdfException: Failed to convert webpage

Font-related issues typically appear as incorrect character rendering, missing glyphs, or complete text substitution in generated documents. These problems often go unnoticed until production deployment because development typically occurs on Windows where required fonts are available.

Who Is Affected

These issues affect developers deploying Syncfusion document processing in:

Docker containers running Linux-based images (Debian, Ubuntu, Alpine)
Azure App Service Linux and Azure Functions on Linux consumption plans
AWS Lambda with .NET Core runtime
Linux servers running CentOS, Ubuntu, or other distributions
.NET 6+ applications where Microsoft made System.Drawing.Common Windows-only

The problems are particularly acute for organizations migrating from Windows Server to Linux containers for cost reduction, or teams adopting cloud-native architectures that favor Linux-based deployments.

Evidence from the Developer Community

Developer reports span multiple years across Syncfusion forums, GitHub issues, and Stack Overflow questions.

Timeline

Date	Event	Source
2020-07-15	PDF Viewer unable to load libpdfium.so reported	Syncfusion Forums
2021-07-14	DOC to PDF conversion failures in Linux Docker	Syncfusion Forums
2022-01-20	.NET 6 upgrade breaks PDF Viewer service	Syncfusion Forums
2023-03-15	Alpine Linux musl compatibility issues documented	Syncfusion Forums
2024-11-20	Type initializer for PdfiumNative exceptions continue	Syncfusion Forums
2025-01-15	Memory not released after disposal reported	Syncfusion Forums

Community Reports

"We are seeing the error 'Unable to load shared library libpdfium.so or one of its dependencies' when deploying to our Linux Docker container. Everything works fine on Windows."
— Developer, Syncfusion Forums, 2020

"The type initializer for 'Gdip' threw an exception in renderpdfpages API. We upgraded to .NET 6 and now the PDF Viewer service won't start."
— Developer, Syncfusion Forums, 2022

"Alpine Linux distribution is based on musl libc and differs from other Debian OS. We cannot find and install the exact dependencies of pdfium within Alpine Linux OS."
— Syncfusion Support, Syncfusion Forums, 2023

The Alpine Linux incompatibility is notable: Syncfusion has acknowledged they cannot support Alpine-based containers due to musl libc incompatibility with PDFium.

Root Cause Analysis

The fundamental issue is architectural: Syncfusion's document processing libraries were designed with Windows GDI+ as the primary graphics backend. When porting to .NET Core for cross-platform support, the libraries retained dependencies on System.Drawing.Common, which Microsoft deprecated for Linux in .NET 6.

Three specific architectural decisions create deployment friction:

1. PDFium Runtime Extraction: Syncfusion embeds PDFium binaries and extracts them at runtime to the application directory. If the directory lacks write permissions (common in containerized environments), initialization fails. This design pattern also conflicts with immutable container filesystems.

2. System.Drawing.Common Dependency: For graphics operations, Syncfusion relies on System.Drawing.Common which requires libgdiplus on Linux. The libgdiplus library is a Mono project dependency that is not installed by default on most Linux distributions and must be manually added to Dockerfiles or deployment scripts.

3. Font Discovery: Syncfusion expects fonts to be available at standard system paths. Linux containers typically ship with minimal font sets, causing text rendering failures when Windows-specific fonts (like Arial or Times New Roman) are referenced in documents.

Attempted Workarounds

The Syncfusion documentation and community forums describe several approaches to address these issues.

Workaround 1: Installing libgdiplus and Dependencies

Approach: Add Linux packages to Dockerfile before running the application.

FROM mcr.microsoft.com/dotnet/aspnet:8.0

# Create symbolic links for native library compatibility
RUN ln -s /lib/x86_64-linux-gnu/libdl.so.2 /lib/x86_64-linux-gnu/libdl.so

# Install System.Drawing native dependencies
RUN apt-get update && apt-get install -y --allow-unauthenticated \
    libgdiplus \
    libc6-dev \
    libx11-dev

# Create symbolic link for gdiplus
RUN ln -s libgdiplus.so gdiplus.dll

COPY . /app
WORKDIR /app
ENTRYPOINT ["dotnet", "MyApp.dll"]

Limitations:

Increases container image size by 50-100MB
libgdiplus is an unmaintained Mono project dependency
Does not work on Alpine Linux due to musl libc incompatibility
Must be repeated for every container image

Workaround 2: Platform-Specific NuGet Packages

Approach: Use conditional package references to load correct binaries per platform.

<PackageReference Include="Syncfusion.EJ2.PdfViewer.AspNet.Core.Linux"
    Version="24.1.41"
    Condition="$([MSBuild]::IsOsPlatform('Linux'))" />
<PackageReference Include="Syncfusion.EJ2.PdfViewer.AspNet.Core.Windows"
    Version="24.1.41"
    Condition="$([MSBuild]::IsOsPlatform('Windows'))" />

Limitations:

Complicates the project file with platform-specific logic
Both packages must be kept in sync for version compatibility
Does not address the underlying dependency issues

Workaround 3: Manual PDFium Path Configuration

Approach: Pre-deploy PDFium binaries and set the ReferencePath property.

PdfRenderer.ReferencePath = "/app/pdfium/";

Limitations:

Requires extracting and managing native binaries separately
Must ensure correct architecture (x64, ARM64) is deployed
Permission issues may still occur depending on the deployment target

Workaround 4: Font Installation and Substitution

Approach: Install Microsoft fonts in the container and configure font substitution.

# Install Microsoft compatible fonts
RUN apt-get install -y ttf-mscorefonts-installer fontconfig

# Or copy custom fonts
COPY ./fonts /usr/share/fonts/custom
RUN fc-cache -f -v

With font substitution in code:

renderer.Settings.EmbedFonts = true;
renderer.Settings.EmbedCompleteFonts = true;

Limitations:

Microsoft core fonts package has licensing restrictions
Font substitution may produce different layouts than expected
Adds significant complexity to deployment pipelines

A Different Approach: IronPDF

When evaluating alternatives for Linux deployment, architecture becomes the deciding factor. Libraries that embed their own rendering engines avoid the dependency management issues that plague System.Drawing.Common-based solutions.

Why IronPDF Handles Linux Differently

IronPDF uses an embedded Chromium rendering engine for HTML-to-PDF conversion and PDF operations. This architecture provides several advantages for Linux deployment:

No libgdiplus Dependency: IronPDF does not use System.Drawing.Common for graphics operations. The rendering engine is self-contained within the NuGet package.

Single Package Deployment: The IronPDF NuGet package contains all required native binaries for Windows, Linux, and macOS. There are no platform-specific packages to manage.

Docker-Ready: The package is designed for containerized deployment. Native binaries are loaded from within the package rather than extracted to disk at runtime.

Alpine Linux Support: Unlike PDFium-based solutions, IronPDF functions on Alpine Linux containers because it does not depend on glibc-specific libraries.

Code Example

using IronPdf;

public class LinuxDocumentService
{
    public byte[] ConvertHtmlToPdf(string htmlContent)
    {
        // IronPDF automatically handles native library loading on Linux
        // No additional configuration required for Docker deployment
        var renderer = new ChromePdfRenderer();

        // Configure rendering options
        renderer.RenderingOptions.MarginTop = 20;
        renderer.RenderingOptions.MarginBottom = 20;

        // Font handling is managed by the embedded Chromium engine
        // System fonts are used when available, with automatic fallback

        var pdf = renderer.RenderHtmlAsPdf(htmlContent);
        return pdf.BinaryData;
    }

    public byte[] ConvertUrlToPdf(string url)
    {
        var renderer = new ChromePdfRenderer();

        // URL rendering works identically on Windows and Linux
        var pdf = renderer.RenderUrlAsPdf(url);
        return pdf.BinaryData;
    }
}

A minimal Dockerfile for IronPDF on Linux:

FROM mcr.microsoft.com/dotnet/aspnet:8.0

# Only libfontconfig is needed for font discovery
RUN apt-get update && apt-get install -y libfontconfig1

COPY . /app
WORKDIR /app
ENTRYPOINT ["dotnet", "MyApp.dll"]

Key points about this code:

No libgdiplus installation required
No PDFium binaries to manage
No symbolic link workarounds
Works on both Debian-based and Alpine Linux containers

API Reference

For more details on the methods used:

Migration Considerations

Switching document processing libraries requires evaluation of several factors.

Licensing

IronPDF is commercial software with per-developer licensing. A free trial is available for evaluation. Syncfusion uses a per-developer licensing model as well, with a community license available for qualifying individuals and small companies.

API Differences

The primary difference is in the rendering approach. Syncfusion's HtmlToPdfConverter requires the Blink engine binaries and specific command-line arguments for Linux. IronPDF's ChromePdfRenderer handles this internally.

Syncfusion code:

HtmlToPdfConverter converter = new HtmlToPdfConverter(HtmlRenderingEngine.Blink);
BlinkConverterSettings settings = new BlinkConverterSettings();
settings.CommandLineArguments.Add("--no-sandbox");
settings.CommandLineArguments.Add("--disable-setuid-sandbox");

IronPDF equivalent:

var renderer = new ChromePdfRenderer();
// Sandbox settings are managed automatically

What You Gain

Single NuGet package for all platforms
No native dependency management
Alpine Linux compatibility
Reduced Dockerfile complexity
Consistent behavior between development and production environments

What to Consider

Different API surface requiring code changes
Commercial licensing costs
Learning curve for existing Syncfusion users
Testing required to validate output compatibility

Conclusion

Linux deployment issues with Syncfusion document processing stem from architectural dependencies on System.Drawing.Common and platform-specific native libraries. While workarounds exist, they add complexity to deployment pipelines and may not cover all scenarios, particularly Alpine Linux containers. Developers prioritizing Linux-native deployment may find libraries with embedded rendering engines provide a more straightforward path to production.

Written by Jacob Mellor, CTO at Iron Software and original developer of IronPDF.

References

How to create PDF document in Linux Docker using C#{:rel="nofollow"} - Syncfusion KB article on Docker deployment
The type initializer for 'Gdip' threw an exception{:rel="nofollow"} - Forum thread on GDI+ initialization failures
Unable to load shared library libpdfium ALPINE LINUX{:rel="nofollow"} - Discussion of Alpine Linux compatibility issues
PDF Viewer Service died after .NET 6 upgrade{:rel="nofollow"} - Breaking changes in .NET 6
How to use external fonts for HTML to PDF conversion in Linux docker container{:rel="nofollow"} - Font configuration documentation
Converting HTML to PDF using Blink in a Linux docker container fails in Azure App Service{:rel="nofollow"} - Azure deployment issues
Heavy memory leak on PDF creation{:rel="nofollow"} - Memory management issues in Blazor applications
Resolve PDFium initialization error in ASP.NET Core PDF Viewer{:rel="nofollow"} - Official troubleshooting guide

For the latest IronPDF documentation and tutorials, visit ironpdf.com.