DEV Community: IronSoftware

Slow Document Loading in Aspose (Issue Fixed)

IronSoftware — Wed, 08 Apr 2026 10:35:00 +0000

Opening large PDF files with Aspose.PDF can take considerably longer than expected. Developers report that loading a 3000+ page document into memory takes 6x longer than loading the equivalent Word document, while 59MB files require nearly a minute before the first page can even be accessed. For applications that need to process existing PDFs at scale, these loading times create bottlenecks before any actual work begins.

The Problem

Aspose.PDF's document loading performance degrades significantly with file size. The issue manifests at the very first step of PDF processing: instantiating the Document class with an existing file. Before any operations like text extraction, page manipulation, or conversion can occur, the entire document structure must be parsed and loaded into memory.

This creates a fundamental bottleneck that affects every downstream operation. A workflow that needs to extract text from page 5 of a 500-page document must wait for all 500 pages to load first. Applications that batch-process thousands of PDFs spend more time waiting for documents to open than performing actual processing.

The problem compounds in memory-constrained environments. As Aspose.PDF loads large documents, memory consumption climbs rapidly. Users report that a 20MB PDF can cause memory usage to spike to 1.5GB or higher. When processing multiple large files concurrently, servers can exhaust available RAM, triggering garbage collection cycles that further degrade performance or causing outright crashes.

Error Messages and Symptoms

Large document loading in Aspose.PDF produces measurable symptoms before any exceptions occur:

Document Loading Metrics (Aspose.PDF):

Initial load times:
- 3000+ page PDF: 6x slower than equivalent DOCX in Aspose.Words
- 59MB PDF (18 pages): 48 seconds before first page accessible
- 20MB PDF: Memory spikes to 1.5GB+ during load
- 15MB PDF: Memory reaches 1.5GB with multiple concurrent loads
- ~130MB+ files: StackOverflowException during processing

Memory consumption patterns:
- Without Aspose: ~20% RAM usage
- With Aspose loading large files: 97-99% RAM
- After processing 10,000 documents: 6GB memory accumulated
- Two concurrent large file loads: ~3GB memory usage

Loading operation characteristics:
- Full document loaded to memory before any operation
- No incremental or lazy loading option
- Stream-based loading still requires full memory allocation

When memory pressure becomes severe, explicit exceptions occur:

System.OutOfMemoryException: Exception of type 'System.OutOfMemoryException' was thrown.
   at Aspose.Pdf.Document..ctor(Stream input)

System.StackOverflowException
   (for files greater than approximately 130MB)

ContextSwitchDeadlock detected
   (when merging large PDF files, approximately 2GB each)

Who Is Affected

Document loading performance issues in Aspose.PDF impact developers across several scenarios.

Document Processing Services: Applications that process existing PDFs for text extraction, data mining, or format conversion face throughput limitations. If loading a document takes 48 seconds, processing 1,000 documents takes over 13 hours just in load time.

PDF Viewing Applications: Software that displays PDF content must load documents before rendering. Users waiting nearly a minute to view an 18-page file will find the experience unacceptable, particularly when browsers render the same file instantly.

Batch Processing Workflows: Enterprise systems handling document archives, legal discovery, or compliance audits process thousands of files. Loading bottlenecks multiply across the batch, turning hour-long jobs into day-long operations.

Memory-Constrained Deployments: Azure App Service, Docker containers with memory limits, and serverless functions cannot accommodate the memory spikes associated with large document loading. A function allocated 1GB of memory cannot safely process 20MB PDFs.

Concurrent Processing Systems: Web applications and APIs handling multiple simultaneous requests face cascading failures. Two users uploading 15MB documents simultaneously consume 3GB of memory, potentially exhausting server resources.

Linux and Docker Environments: Users report that loading performance issues are often more pronounced in containerized environments. Combined with libgdiplus dependencies, Linux deployments face compounded challenges.

Evidence from the Developer Community

Document loading performance complaints have accumulated across Aspose forums and Stack Overflow, indicating a persistent limitation.

Timeline

Date	Event	Source
Mar 2021	PDF loading 6x slower than equivalent DOCX documented	Aspose Forums
Sep 2022	59MB PDF takes 48 seconds to first page render	Aspose Forums
Jul 2021	ASPOSE.PDF very slow on document.save() - includes load time	Stack Overflow
Jun 2023	High memory usage on pdf document object reported	Aspose Forums
Jan 2025	Production server impacted by high memory consumption	Aspose Forums
Nov 2025	OUT of memory issue when merging large files	Aspose Forums
Dec 2025	Issue with Merging Large PDF Files (OutOfMemory and ContextSwitchDeadlock)	Aspose Forums

Community Reports

"We've noticed that loading PDF documents for conversion (var document = new Aspose.Pdf.Document(stream)) takes considerably longer compared to loading MS Office documents in Aspose.Words. For example, loading a large MS Word document (3000+ pages, text only/no images) is up to 6x faster compared to loading the same document converted to PDF."

Developer comparing document loading, Aspose Forums, March 2021

"A 59MB PDF file with only 18 pages takes a really long time to render using Aspose.PDF.dll. On our fastest machine (AMD Ryzen 7 3800X 8-Core Processor 3.90 GHz with 32 GB Ram), 48 seconds passed before the first page got rendered."

User benchmarking large file performance, Aspose Forums, September 2022

"Without Aspose.PDF the system needs ~20% of RAM, but when Aspose.PDF starts (noticeable with larger files, ~20MB) it drains all available RAM, reaches 97-99% readings and causes server response issues."

Developer documenting memory impact, Aspose Forums, June 2023

"When converting bigger files like about 15MB, the memory goes up to 1.5GB, and when doing multiple converts at a time it gets worse. Converting 1 file causes memory to go up, then converting another one simultaneously can result in memory usage of ~3GB."

User experiencing concurrent processing issues, Aspose Forums, 2023

"We are using Aspose.PDF to convert PDFs to HTML in our application and are experiencing extremely high memory usage on our server. Memory consumption is reaching 95%."

Production environment memory impact, Aspose Forums, January 2025

The consistency of these reports across years suggests an architectural characteristic rather than a fixable bug.

Root Cause Analysis

Aspose.PDF's document loading performance stems from its approach to PDF parsing and memory management.

Full Document Parsing: When creating a Document object, Aspose.PDF parses the entire PDF structure into an in-memory representation. This includes the page tree, cross-reference tables, all embedded resources, font definitions, and content streams. For large documents, this parsing operation becomes the primary bottleneck.

Object Instantiation Overhead: PDF documents contain numerous internal objects (pages, fonts, images, annotations, form fields). Each object is instantiated as a .NET object in memory, creating allocation pressure. A document with thousands of objects creates thousands of managed allocations.

No Lazy Loading: Unlike some PDF libraries that load content on-demand, Aspose.PDF's architecture requires the complete document structure to be available before operations can proceed. There is no option to load only specific pages or defer content stream parsing.

Cross-Reference Resolution: PDF files use cross-reference tables to locate objects. For large documents with complex internal linking, resolving these references requires significant processing. Damaged or non-standard cross-references compound the problem.

Embedded Resource Decompression: Compressed streams within the PDF (images, content streams) may be decompressed during loading, expanding memory requirements beyond the file's disk size. A 20MB PDF file with compressed images can expand to hundreds of megabytes in memory.

Memory Retention: After loading, Aspose.PDF retains the parsed document structure in memory. Unlike streaming approaches that release memory after processing each section, the entire document persists until explicitly disposed.

Attempted Workarounds

The developer community has documented various approaches to mitigate document loading performance, each with significant limitations.

Workaround 1: Load from FileStream Instead of Path

Approach: Use a FileStream with specific options instead of loading directly from a file path.

// Instead of direct path loading
var document = new Document("large-file.pdf");

// Use FileStream with sequential read hint
using (var stream = new FileStream("large-file.pdf",
    FileMode.Open,
    FileAccess.Read,
    FileShare.Read,
    bufferSize: 4096,
    FileOptions.SequentialScan))
{
    var document = new Document(stream);
    // Process document
}

Limitations:

Aspose.PDF still loads the entire document into memory
Sequential scan hint provides minimal benefit for PDF structure
Does not address the fundamental parsing overhead
Memory consumption remains unchanged

Workaround 2: Process Documents in Separate AppDomains

Approach: Load each document in an isolated AppDomain that can be unloaded to release memory.

// Load document in separate AppDomain to force memory release
public byte[] ProcessInIsolation(string filePath)
{
    var domain = AppDomain.CreateDomain("PdfProcessing");
    try
    {
        var processor = (PdfProcessor)domain.CreateInstanceAndUnwrap(
            typeof(PdfProcessor).Assembly.FullName,
            typeof(PdfProcessor).FullName);
        return processor.Process(filePath);
    }
    finally
    {
        AppDomain.Unload(domain);
    }
}

Limitations:

AppDomain unloading is not available in .NET Core/.NET 5+
Significant performance overhead for each document
Serialization required to pass data across domain boundaries
Adds substantial code complexity

Workaround 3: Increase Memory and Accept Slow Loading

Approach: Allocate more memory and configure longer timeouts.

// Configure for large files
var loadOptions = new PdfLoadOptions();
// Accept that loading will be slow and memory-intensive
// Ensure adequate server resources are available

Limitations:

Does not improve loading speed
Increases infrastructure costs
Not viable for memory-constrained environments (serverless, containers)
Multiple concurrent operations still exhaust resources

Workaround 4: Split Large PDFs Before Processing

Approach: Use a lightweight tool to split large PDFs into smaller chunks before loading with Aspose.

// Pre-split approach (pseudo-code)
var pageRanges = SplitIntoChunks("large.pdf", chunkSize: 50);
foreach (var range in pageRanges)
{
    using (var smallerDoc = new Document(range.FilePath))
    {
        // Process smaller document
    }
}

Limitations:

Requires additional tooling for the split operation
Adds I/O overhead writing temporary files
Splitting itself requires loading the source document
Cross-page references (bookmarks, links) may break

A Different Approach: IronPDF

For developers whose workflows involve loading and processing existing PDF files, IronPDF provides an architecture optimized for efficient document handling. Rather than loading entire documents into memory upfront, IronPDF uses techniques that minimize memory pressure and improve loading responsiveness.

Why IronPDF Handles Large Documents Differently

IronPDF's document loading approach addresses the bottlenecks present in Aspose.PDF's architecture:

Optimized Parsing: The internal PDF parser is designed for efficiency, using native code optimizations where possible. Recent versions reduced loading time for large documents by up to 80%.
Memory-Efficient Representation: Documents are represented using memory-efficient data structures that minimize allocation overhead. The internal object model uses less memory per page than full DOM-style representations.
Streaming Support: IronPDF can work with streams efficiently without requiring the entire file to be buffered in memory before processing begins.
Incremental Access: While the full document structure is available, IronPDF optimizes access patterns so that operations on early pages do not require complete processing of later pages.
Proper Resource Disposal: Calling Dispose() on IronPDF documents releases memory promptly, preventing accumulation across batch operations.

Code Example

using IronPdf;
using System.IO;

// Efficient large document loading with IronPDF
public class LargeDocumentLoader
{
    public void ProcessLargeDocument(string filePath)
    {
        // Load document - optimized for large files
        using (var pdf = PdfDocument.FromFile(filePath))
        {
            // Document is ready for operations
            // Access page count without loading all content
            var pageCount = pdf.PageCount;

            // Extract text from specific pages
            for (int i = 0; i < pageCount; i++)
            {
                var pageText = pdf.ExtractTextFromPage(i);
                ProcessPageContent(pageText);
            }
        }
        // Memory released when using block exits
    }

    public void ProcessFromStream(Stream inputStream)
    {
        // Stream-based loading for memory efficiency
        using (var pdf = PdfDocument.FromStream(inputStream))
        {
            // Process document
            var text = pdf.ExtractAllText();
            ProcessContent(text);
        }
    }

    public void BatchProcessLargeFiles(string[] filePaths, string outputDirectory)
    {
        // Process files sequentially with proper disposal
        foreach (var path in filePaths)
        {
            using (var pdf = PdfDocument.FromFile(path))
            {
                // Perform operations
                pdf.AddTextHeader(new TextHeaderFooter
                {
                    CenterText = "Processed"
                });

                var outputPath = Path.Combine(outputDirectory,
                    $"processed_{Path.GetFileName(path)}");
                pdf.SaveAs(outputPath);
            }
            // Memory released after each file
            // No accumulation across batch
        }
    }

    private void ProcessPageContent(string text) { /* ... */ }
    private void ProcessContent(string text) { /* ... */ }
}

Key points about this code:

The using pattern ensures documents are disposed properly, releasing memory
PdfDocument.FromFile() and PdfDocument.FromStream() provide efficient loading options
Page-by-page text extraction does not require loading all pages into active memory
Batch processing releases resources between files, preventing memory accumulation
No need for AppDomain isolation or process recycling

API Reference

For more details on the methods used:

PdfDocument.FromFile - Load PDF from file path
PdfDocument.FromStream - Load PDF from stream
ExtractTextFromPage - Extract text from specific pages
Performance Assistance Guide - Optimization techniques

Migration Considerations

Moving from Aspose.PDF to IronPDF requires evaluating several factors beyond loading performance.

Licensing

IronPDF is commercial software with per-developer licensing. A free trial is available for evaluation. Pricing starts at $749 for a single developer license, compared to Aspose.PDF at $1,199. Both offer site and OEM licensing for larger deployments.

API Differences

The document loading APIs differ in their approach:

// Aspose.PDF document loading
using (var stream = new FileStream(path, FileMode.Open))
{
    var doc = new Aspose.Pdf.Document(stream);
    // Access pages via doc.Pages collection
    var pageCount = doc.Pages.Count;
    // Text extraction
    var absorber = new TextAbsorber();
    doc.Pages[1].Accept(absorber);
    var text = absorber.Text;
}

// IronPDF document loading
using (var pdf = PdfDocument.FromFile(path))
{
    // Access page count directly
    var pageCount = pdf.PageCount;
    // Text extraction
    var text = pdf.ExtractTextFromPage(0);
}

Migration effort depends on which Aspose.PDF features are used. Basic document loading and text extraction map directly. Advanced features like form field manipulation, annotation handling, and digital signatures have corresponding IronPDF APIs but may require code adaptation.

What You Gain

Faster document loading for large files
Lower memory consumption during processing
Better behavior in memory-constrained environments
Predictable resource release with proper disposal
No need for AppDomain isolation workarounds

What to Consider

IronPDF includes an embedded Chromium engine, increasing deployment size
Some advanced Aspose.PDF features may have different API patterns
Testing is required to verify processing results match existing workflows
IronPDF targets .NET platforms; Java applications require alternative solutions

Conclusion

Aspose.PDF's document loading performance creates bottlenecks for applications processing large PDF files. The 6x slower loading compared to equivalent document formats, combined with memory consumption that can reach 97-99% of available RAM, limits throughput and creates stability risks in production environments. For teams where loading performance impacts operations, IronPDF's optimized document handling provides an alternative that maintains reasonable loading times and memory usage as file sizes increase.

Written by Jacob Mellor, who leads technical development at Iron Software.

References

Subject: loading PDF documents for conversion in Aspose.Pdf very slow compared to MS Office documents{:rel="nofollow"} - 6x slower loading benchmark
Slow rendering PDF for large size pdf file{:rel="nofollow"} - 48 second first-page render time
High memory usage on pdf document object{:rel="nofollow"} - Memory consumption reaching 97-99%
IMPACT PRODUCTION SERVER - Aspose.PDF High Memory Consumption{:rel="nofollow"} - Production server memory impact
Very high RAM usage{:rel="nofollow"} - 1.5GB memory for 15MB files
OUT of memory issue when merging large files{:rel="nofollow"} - Large file memory exceptions
Issue with Merging Large PDF Files using Aspose.PDF (OutOfMemory and ContextSwitchDeadlock){:rel="nofollow"} - 2GB file processing failures
ASPOSE.PDF very slow on document.save() - java{:rel="nofollow"} - Stack Overflow performance discussion
Large files & streams{:rel="nofollow"} - Stream-based loading challenges
Problem with memory consumption in Aspose.Pdf{:rel="nofollow"} - Historical memory consumption issues

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

Winnovative to IronPDF: three steps and you're done

IronSoftware — Wed, 08 Apr 2026 09:36:00 +0000

The last commit to Winnovative's NuGet packages was years ago. The open GitHub issues haven't received responses in the same timeframe. The library still works — it does what it always did — but when a bug surfaces or a .NET runtime behavior changes, there's no update path. The decision isn't whether to migrate; it's when and to what.

This article covers migrating from Winnovative HTML to PDF Converter for .NET to IronPDF. You'll have benchmark reference patterns and working before/after code. The comparison tables and checklist apply regardless of which replacement you choose.

Why Migrate (Without Drama)

Teams migrating from Winnovative to IronPDF commonly encounter:

Maintenance signal — verify current commit/release activity; outdated libraries carry growing technical risk as .NET evolves.
Rendering engine age — older rendering engines don't support modern CSS (flex, grid, custom properties); verify what your version supports.
.NET version support — verify .NET 6/7/8/9 compatibility at winnovative-software.com; newer runtimes may not be explicitly tested or supported.
Native component management — some Winnovative versions require native binaries or COM components, adding deployment friction.
Linux/Docker gap — if the rendering engine has Windows dependencies, cross-platform deployment isn't possible.
No PDF manipulation — HTML-to-PDF conversion is the primary feature; merge, watermark, security, and text extraction typically require secondary libraries.
Thread safety — verify concurrent rendering behavior in your version; this varies across HTML-to-PDF tools.
Security updates — an unmaintained library doesn't receive security patches; verify risk for your use case.
Documentation staleness — outdated documentation creates friction when troubleshooting edge cases.
Support void — no active maintainer means no path to resolution when bugs surface.

Comparison Table

Aspect	Winnovative HTML to PDF	IronPDF
Focus	HTML-to-PDF conversion	HTML-to-PDF + PDF manipulation
Pricing	Commercial — verify at winnovative-software.com	Commercial — verify at ironsoftware.com
API Style	`HtmlToPdfConverter.ConvertHtmlString()`	`ChromePdfRenderer.RenderHtmlAsPdfAsync()`
Learning Curve	Low for basic use	Low for .NET devs
HTML Rendering	Verify current rendering engine	Embedded Chromium
Page Indexing	Verify in Winnovative docs	0-based
Thread Safety	Verify in Winnovative docs	Verify IronPDF concurrent instance guidance
Namespace	`Winnovative.HtmlToPdfConverter.*`	`IronPdf`

Migration Complexity Assessment

Effort by Feature

Feature	Winnovative	IronPDF Equivalent	Complexity
HTML string to PDF	`converter.ConvertHtmlString(html)`	`ChromePdfRenderer.RenderHtmlAsPdfAsync()`	Low
URL to PDF	`converter.ConvertUrl(url)`	`renderer.RenderUrlAsPdfAsync(url)`	Low
Save to file	`doc.Save(path)` or byte[] + write	`pdf.SaveAs(path)`	Low
Save to stream	Verify stream API	`pdf.Stream` / `pdf.BinaryData`	Low
Custom page size	`converter.PdfPageSize = ...`	`RenderingOptions.PaperSize`	Low
Margins	Converter settings	`RenderingOptions.Margin*`	Low
Headers/footers	Verify API	`RenderingOptions.HtmlHeader/Footer`	Medium
Merge PDFs	Verify support	`PdfDocument.Merge()`	Medium
Watermark	Verify support	`TextStamper` / `ImageStamper`	Medium
Password protection	Verify support	`pdf.SecuritySettings`	Low
Text extraction	Verify support	`pdf.ExtractAllText()`	Medium

Decision Matrix

Business Scenario	Recommendation
Active maintenance is the primary concern	Switch — eliminates risk of unmaintained dependency
Modern CSS (flex, grid) rendering needed	Switch — Chromium vs older rendering engine
Linux/Docker deployment	Switch — verify Winnovative Linux support; likely not available
Winnovative working well, no maintenance concern	Evaluate migration cost vs risk timeline

Before You Start

Prerequisites

.NET 6/7/8/9
IronPDF license key — get a trial

Find All Winnovative References

# Find Winnovative usage (verify namespace in your version)
rg -l "Winnovative\|HtmlToPdfConverter\b" --type cs
rg "Winnovative\|ConvertHtmlString\|ConvertUrl\b" --type cs -n

# Find NuGet references
grep -r "Winnovative" *.csproj **/*.csproj 2>/dev/null

# Count usage density
rg "HtmlToPdfConverter\|ConvertHtmlString\|ConvertUrl\b" --type cs | wc -l

Uninstall / Install

# Remove Winnovative packages (verify exact package names at NuGet)
dotnet remove package Winnovative.HtmlToPdfConverter  # verify exact name

# Install IronPDF
dotnet add package IronPdf

dotnet restore

Quick Start Migration (3 Steps)

Step 1 — License Configuration

using IronPdf;

// https://ironpdf.com/how-to/license-keys/
IronPdf.License.LicenseKey = Environment.GetEnvironmentVariable("IRONPDF_LICENSE_KEY")
    ?? throw new InvalidOperationException("IRONPDF_LICENSE_KEY not set");

Step 2 — Namespace Swap

Before:

using Winnovative;           // verify namespace
using Winnovative.HtmlToPdfConverter; // verify

After:

using IronPdf;
using IronPdf.Rendering;

Step 3 — Basic HTML to PDF

Before (Winnovative — verify all API names):

using System;
using System.IO;

class Program
{
    static void Main()
    {
        // VERIFY: Winnovative API names for your version
        // All names below are based on commonly documented usage — verify at their site

        var converter = new HtmlToPdfConverter();

        // Converter settings — VERIFY property names
        // converter.PdfPageSize = PdfPageSize.A4;
        // converter.PdfPageOrientation = PdfPageOrientation.Portrait;

        // Convert HTML string — VERIFY method name and return type
        var doc = converter.ConvertHtmlString(
            "<html><body><h1>Hello</h1></body></html>"
        );

        // Save — VERIFY save method
        doc.Save("output.pdf");
        Console.WriteLine("Saved output.pdf — verify all Winnovative API names");
    }
}

After:

using IronPdf;
using System;

IronPdf.License.LicenseKey = Environment.GetEnvironmentVariable("IRONPDF_LICENSE_KEY");

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

var pdf = await renderer.RenderHtmlAsPdfAsync("<html><body><h1>Hello</h1></body></html>");
pdf.SaveAs("output.pdf");

Console.WriteLine($"Saved output.pdf ({pdf.PageCount} page(s))");
// https://ironpdf.com/how-to/html-string-to-pdf/

Benchmark Reference Patterns

Measurement structures only — no claims. Run against your own HTML and environment. Use these to compare Winnovative and IronPDF baseline times before committing.

Single Render Timing

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

IronPdf.License.LicenseKey = Environment.GetEnvironmentVariable("IRONPDF_LICENSE_KEY");

var html = @"
    <html>
    <head>
    <style>
        body { font-family: Arial, sans-serif; padding: 40px; }
        table { width: 100%; border-collapse: collapse; }
        th, td { border: 1px solid #ddd; padding: 6px; font-size: 11px; }
        th { background: #f0f0f0; }
    </style>
    </head>
    <body>
        <h1>Benchmark Report</h1>
        <table>
            <tr><th>Region</th><th>Revenue</th><th>YoY</th></tr>
            <tr><td>North America</td><td>$12.4M</td><td>+8.2%</td></tr>
            <tr><td>Europe</td><td>$9.1M</td><td>+3.7%</td></tr>
            <tr><td>APAC</td><td>$6.8M</td><td>+14.3%</td></tr>
        </table>
    </body>
    </html>";

async Task<(double avg, double p95)> BenchmarkIronPdf(int runs = 25)
{
    var renderer = new ChromePdfRenderer();
    using var warmup = await renderer.RenderHtmlAsPdfAsync(html); // warm up

    var times = new List<double>();
    for (int i = 0; i < runs; i++)
    {
        var sw = Stopwatch.StartNew();
        using var pdf = await renderer.RenderHtmlAsPdfAsync(html);
        sw.Stop();
        times.Add(sw.Elapsed.TotalMilliseconds);
    }

    times.Sort();
    return (times.Average(), times[(int)(times.Count * 0.95)]);
}

var (avg, p95) = await BenchmarkIronPdf(25);
Console.WriteLine($"IronPDF — Avg: {avg:F1}ms | P95: {p95:F1}ms");

// Winnovative benchmark structure (synchronous):
// var sw = Stopwatch.StartNew();
// var converter = new HtmlToPdfConverter(); // VERIFY
// var doc = converter.ConvertHtmlString(html); // VERIFY
// doc.Save("bench.pdf"); // VERIFY
// Console.WriteLine($"Winnovative: {sw.Elapsed.TotalMilliseconds:F1}ms");

Concurrent Throughput

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

IronPdf.License.LicenseKey = Environment.GetEnvironmentVariable("IRONPDF_LICENSE_KEY");

// https://ironpdf.com/examples/parallel/
async Task BenchmarkConcurrency(int degree)
{
    var jobs = Enumerable.Range(1, degree)
        .Select(i => $"<html><body><h1>Doc {i}</h1></body></html>")
        .ToArray();

    var sw = Stopwatch.StartNew();

    await Task.WhenAll(jobs.Select(async html =>
    {
        var renderer = new ChromePdfRenderer();
        using var pdf = await renderer.RenderHtmlAsPdfAsync(html);
        return pdf.PageCount;
    }));

    sw.Stop();
    Console.WriteLine($"Degree {degree}: {sw.Elapsed.TotalMilliseconds:F0}ms | {sw.Elapsed.TotalMilliseconds / degree:F1}ms/doc");
}

await BenchmarkConcurrency(5);
await BenchmarkConcurrency(10);
await BenchmarkConcurrency(20);
// See: https://ironpdf.com/how-to/async/

Memory Profile

using IronPdf;
using System;
using System.Threading.Tasks;

IronPdf.License.LicenseKey = Environment.GetEnvironmentVariable("IRONPDF_LICENSE_KEY");

static async Task MeasureMemoryDelta(int iterations)
{
    var renderer = new ChromePdfRenderer();
    var html = "<html><body><h1>Memory test</h1></body></html>";
    var before = GC.GetTotalMemory(forceFullCollection: true);

    for (int i = 0; i < iterations; i++)
    {
        using var pdf = await renderer.RenderHtmlAsPdfAsync(html);
        // pdf disposed each iteration
    }

    GC.Collect();
    GC.WaitForPendingFinalizers();
    var after = GC.GetTotalMemory(forceFullCollection: true);
    Console.WriteLine($"{iterations} renders: delta {(after - before) / 1024:F0} KB after GC");
}

await MeasureMemoryDelta(50);

API Mapping Tables

Namespace Mapping

Winnovative	IronPDF	Notes
`Winnovative.HtmlToPdfConverter`	`IronPdf`	Core namespace
N/A	`IronPdf.Rendering`	Rendering config
N/A	`IronPdf.Editing`	Watermark / stamp

Core Class Mapping

Winnovative Class	IronPDF Class	Description
`HtmlToPdfConverter`	`ChromePdfRenderer`	Primary rendering class
Converter settings object	`ChromePdfRenderOptions`	Page size, margins, options
PDF document result	`PdfDocument`	Output object
N/A	`PdfDocument.Merge()`	Static merge

Document Loading Methods

Operation	Winnovative	IronPDF
HTML string	`converter.ConvertHtmlString(html)`	`renderer.RenderHtmlAsPdfAsync(html)`
URL	`converter.ConvertUrl(url)`	`renderer.RenderUrlAsPdfAsync(url)`
HTML file	Verify	`renderer.RenderHtmlFileAsPdfAsync(path)`
Load existing PDF	Verify	`PdfDocument.FromFile(path)`

Page Operations

Operation	Winnovative	IronPDF
Page count	Verify	`pdf.PageCount`
Remove page	Verify	`pdf.RemovePage(index)` — verify
Extract text	Verify	`pdf.ExtractAllText()`
Rotate	Verify	Verify in IronPDF docs

Merge / Split Operations

Operation	Winnovative	IronPDF
Merge	Verify support	`PdfDocument.Merge(doc1, doc2)`
Split	Verify	Guide

Four Complete Before/After Migrations

1. HTML String to PDF

Before (Winnovative — verify all API names):

using System;
using System.IO;

class HtmlToPdfBefore
{
    static void Main()
    {
        // VERIFY: all Winnovative class and method names at winnovative-software.com

        var html = @"
            <html>
            <head><style>
            body { font-family: Arial; padding: 40px; }
            .header { font-size: 20px; font-weight: bold; }
            table { width: 100%; border-collapse: collapse; }
            td, th { border: 1px solid #ccc; padding: 6px; }
            </style></head>
            <body>
                <div class='header'>Invoice #INV-2024-0099</div>
                <p>Customer: Acme Corp | Due: 2024-12-31</p>
                <table>
                    <tr><th>Item</th><th>Qty</th><th>Price</th></tr>
                    <tr><td>Widget Pro</td><td>5</td><td>$149.00</td></tr>
                </table>
            </body></html>";

        // VERIFY: HtmlToPdfConverter class and properties
        var converter = new HtmlToPdfConverter();
        // converter.PdfPageSize = PdfPageSize.A4; // VERIFY property name/enum

        // VERIFY: ConvertHtmlString method name and return type
        var doc = converter.ConvertHtmlString(html);

        // VERIFY: Save method
        doc.Save("invoice.pdf");
        Console.WriteLine("Saved invoice.pdf — verify all Winnovative API names");
    }
}

After:

using IronPdf;
using System;

IronPdf.License.LicenseKey = Environment.GetEnvironmentVariable("IRONPDF_LICENSE_KEY");

var html = @"
    <html>
    <head><style>
    body { font-family: Arial; padding: 40px; }
    .header { font-size: 20px; font-weight: bold; }
    table { width: 100%; border-collapse: collapse; }
    td, th { border: 1px solid #ccc; padding: 6px; }
    </style></head>
    <body>
        <div class='header'>Invoice #INV-2024-0099</div>
        <p>Customer: Acme Corp | Due: 2024-12-31</p>
        <table>
            <tr><th>Item</th><th>Qty</th><th>Price</th></tr>
            <tr><td>Widget Pro</td><td>5</td><td>$149.00</td></tr>
        </table>
    </body></html>";

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

var pdf = await renderer.RenderHtmlAsPdfAsync(html);
pdf.SaveAs("invoice.pdf");
Console.WriteLine($"Saved invoice.pdf ({pdf.PageCount} page(s))");
// https://ironpdf.com/how-to/html-string-to-pdf/

2. Merge PDFs

Before (Winnovative — verify merge support):

using System;
using System.Collections.Generic;
using System.IO;

class MergeBefore
{
    static void Main()
    {
        // VERIFY: Winnovative merge support and API
        // May require generating each section separately and merging with secondary library

        var sections = new[]
        {
            "<html><body><h1>Section 1</h1></body></html>",
            "<html><body><h1>Section 2</h1></body></html>",
        };

        var pdfBytes = new List<byte[]>();

        foreach (var html in sections)
        {
            var converter = new HtmlToPdfConverter(); // VERIFY
            var doc = converter.ConvertHtmlString(html); // VERIFY
            // VERIFY: export to bytes
            // pdfBytes.Add(doc.ToBytes()); // illustrative
        }

        // Merge via secondary library if Winnovative doesn't support it:
        // var merged = SomePdfLib.Merge(pdfBytes);
        Console.WriteLine("Verify Winnovative merge API — secondary library may be needed");
    }
}

After:

using IronPdf;
using System;
using System.Threading.Tasks;

IronPdf.License.LicenseKey = Environment.GetEnvironmentVariable("IRONPDF_LICENSE_KEY");

var renderer = new ChromePdfRenderer();

var results = await Task.WhenAll(
    renderer.RenderHtmlAsPdfAsync("<html><body><h1>Section 1</h1></body></html>"),
    renderer.RenderHtmlAsPdfAsync("<html><body><h1>Section 2</h1></body></html>")
);

// https://ironpdf.com/how-to/merge-or-split-pdfs/
var merged = PdfDocument.Merge(results[0], results[1]);
merged.SaveAs("merged.pdf");
Console.WriteLine($"Merged: {merged.PageCount} pages");

3. Watermark

Before (Winnovative — verify support):

using System;
// VERIFY: Winnovative watermark API — may not be native
// If not supported, secondary library needed after generation

class WatermarkBefore
{
    static void Main()
    {
        // var converter = new HtmlToPdfConverter(); // VERIFY
        // var doc = converter.ConvertHtmlString("<html><body><h1>Report</h1></body></html>");
        // VERIFY: watermark method — may not exist

        // If not native: apply via secondary library
        // var bytes = doc.ToBytes();
        // var watermarked = SomePdfLib.AddTextWatermark(bytes, "DRAFT");
        // File.WriteAllBytes("watermarked.pdf", watermarked);

        Console.WriteLine("Verify Winnovative watermark API — may require secondary library");
    }
}

After:

using IronPdf;
using IronPdf.Editing;
using System;

IronPdf.License.LicenseKey = Environment.GetEnvironmentVariable("IRONPDF_LICENSE_KEY");

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

// https://ironpdf.com/how-to/custom-watermark/
var watermark = new TextStamper
{
    Text = "DRAFT",
    FontColor = IronPdf.Imaging.Color.Gray,
    Opacity = 0.15,
    VerticalAlignment = VerticalAlignment.Middle,
    HorizontalAlignment = HorizontalAlignment.Center,
};

pdf.ApplyStamp(watermark);
pdf.SaveAs("watermarked.pdf");
Console.WriteLine("Watermark applied — https://ironpdf.com/examples/pdf-watermarking/");

4. Password Protection

Before (Winnovative — verify security API):

using System;
// VERIFY: Winnovative password/security API

class PasswordBefore
{
    static void Main()
    {
        // var converter = new HtmlToPdfConverter(); // VERIFY
        // var doc = converter.ConvertHtmlString("<html><body><h1>Secured</h1></body></html>");

        // VERIFY: Winnovative security API — property names are version-dependent
        // doc.Security.UserPassword = "open123";   // illustrative — VERIFY
        // doc.Security.OwnerPassword = "admin456"; // illustrative — VERIFY
        // doc.Save("secured.pdf");

        Console.WriteLine("Verify Winnovative security API — check winnovative-software.com docs");
    }
}

After:

using IronPdf;
using System;

IronPdf.License.LicenseKey = Environment.GetEnvironmentVariable("IRONPDF_LICENSE_KEY");

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

// https://ironpdf.com/how-to/pdf-permissions-passwords/
pdf.SecuritySettings.UserPassword = "open123";
pdf.SecuritySettings.OwnerPassword = "admin456";

pdf.SaveAs("secured.pdf");
Console.WriteLine("Saved secured.pdf — https://ironpdf.com/examples/encryption-and-decryption/");

Critical Migration Notes

Verify API Names Before Any Code Removal

Winnovative has limited public documentation compared to larger libraries. Before removing any Winnovative code, run the codebase audit to understand exact method signatures in use:

# Capture all method calls before removing anything
rg "converter\.\|HtmlToPdfConverter\.\|ConvertHtml\|ConvertUrl\b" --type cs -n > winnovative-usage.txt
cat winnovative-usage.txt
# Use this as the migration map — verify each line against Winnovative docs

Rendering Engine Difference

Winnovative uses an internal rendering engine. IronPDF uses Chromium. Modern CSS that didn't work in Winnovative may now work — and some Winnovative-specific CSS workarounds may no longer be needed:

# Find CSS that was added as Winnovative workarounds
rg "TODO.*winnovative\|HACK.*render\|workaround.*pdf" --type css --type html -in

# After migration, test whether these workarounds are still needed

`ConvertHtmlString` Return Type

Winnovative's return type varies by version — it may return byte[] directly or a document object. Map to IronPDF accordingly:

// If Winnovative returned byte[]:
// var bytes = converter.ConvertHtmlString(html);
// File.WriteAllBytes("output.pdf", bytes);

// IronPDF equivalent:
using var pdf = await renderer.RenderHtmlAsPdfAsync(html);
var bytes = pdf.BinaryData; // equivalent byte[]
pdf.SaveAs("output.pdf");   // or save directly

Page Indexing

Verify Winnovative's page indexing (if any page manipulation was used) before assuming 0-based. IronPDF uses 0-based indexing.

Performance Considerations

Parallel Generation

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

IronPdf.License.LicenseKey = Environment.GetEnvironmentVariable("IRONPDF_LICENSE_KEY");

// https://ironpdf.com/examples/parallel/
var pdfs = await Task.WhenAll(dataList.Select(async data =>
{
    var renderer = new ChromePdfRenderer();
    return await renderer.RenderHtmlAsPdfAsync(BuildHtml(data));
}));

foreach (var pdf in pdfs) pdf.Dispose();
// See: https://ironpdf.com/how-to/async/

Disposal Pattern

using IronPdf;
using System.IO;

var renderer = new ChromePdfRenderer();
using var pdf = await renderer.RenderHtmlAsPdfAsync(html);

// Map from Winnovative return:
// If Winnovative returned byte[]: pdf.BinaryData is the equivalent
// If Winnovative returned a document with a Save(stream): pdf.Stream.CopyTo(stream)
pdf.SaveAs("output.pdf");
// pdf disposed at end of 'using' block

Migration Checklist

Pre-Migration

[ ] Verify Winnovative maintenance status at winnovative-software.com
[ ] Find all Winnovative API usage (rg "Winnovative\|ConvertHtmlString\|ConvertUrl" --type cs)
[ ] Document exact method signatures in use
[ ] Identify secondary libraries used for merge/security/watermark
[ ] Measure baseline render time for benchmark comparison
[ ] Obtain IronPDF license key
[ ] Verify IronPDF .NET version compatibility
[ ] Check for native/COM dependency requirements in current Winnovative setup

Code Migration

[ ] Install IronPDF (dotnet add package IronPdf)
[ ] Remove Winnovative NuGet packages
[ ] Add license key at application startup
[ ] Replace HtmlToPdfConverter.ConvertHtmlString() with ChromePdfRenderer.RenderHtmlAsPdfAsync()
[ ] Replace converter.ConvertUrl() with renderer.RenderUrlAsPdfAsync()
[ ] Replace doc.Save(path) with pdf.SaveAs(path)
[ ] Map converter settings properties to RenderingOptions.*
[ ] Replace secondary merge library with PdfDocument.Merge()
[ ] Replace secondary watermark library with TextStamper
[ ] Replace secondary security library with pdf.SecuritySettings

Testing

[ ] Compare PDF output visually against Winnovative reference
[ ] Test modern CSS rendering (flex, grid) — may now work where it didn't before
[ ] Benchmark render time — single and concurrent
[ ] Test Linux/Docker deployment if applicable
[ ] Test merge, watermark, and security
[ ] Verify page size and margin settings match reference

Post-Migration

[ ] Remove Winnovative NuGet packages
[ ] Remove secondary libraries now replaced by IronPDF
[ ] Remove Winnovative native components from deployment if applicable
[ ] Archive Winnovative CSS workarounds in case reference is needed

One Last Thing

The maintenance signal — last update years ago, issues unanswered — is the clearest migration trigger. The technical migration is straightforward because both tools do the same job (HTML-to-PDF); the API surface maps closely even if names differ.

The benchmark patterns above are most useful for understanding how concurrent throughput changes — particularly if the current Winnovative setup has any thread-safety workarounds that added infrastructure overhead.

Discussion question: Which feature was hardest to replicate in IronPDF — was it a specific CSS behavior that worked differently, a margin/header setting that didn't map directly, or something in the rendering output that surprised you?

# SelectPdf Slow Build Times and Conversion Performance (Issue Fixed)

IronSoftware — Wed, 08 Apr 2026 08:34:00 +0000

Developers integrating SelectPdf into .NET projects often encounter unexpected delays during both compilation and runtime. Build times stretch from seconds to minutes as Visual Studio downloads and processes massive NuGet packages. Once deployed, HTML-to-PDF conversions that should complete instantly take 3 seconds on development machines and up to 3.5 minutes on production web servers. These performance characteristics impact developer productivity and end-user experience alike.

The Problem

SelectPdf delivers PDF generation capabilities through a NuGet package architecture that prioritizes feature completeness over build-time efficiency. The primary Select.Pdf package weighs in at 75.61 MB, while the .NET Core variant reaches 105.33 MB. When using the Blink rendering engine (Chromium-based), the package includes an entire Chromium browser folder that must be extracted and deployed with each build.

The runtime conversion performance presents separate concerns. Developers report consistent 3-second delays for simple HTML-to-PDF conversions on .NET Core, with some production environments experiencing conversions stretching to 3.5 minutes. These delays persist regardless of document complexity, indicating overhead in the conversion pipeline itself rather than rendering complexity.

The combination of slow builds and slow conversions creates compounding productivity losses. A developer making iterative changes to PDF output spends significant time waiting for builds to complete and conversions to finish, extending development cycles substantially.

Error Messages and Symptoms

Performance issues do not produce error messages in the traditional sense. Instead, developers observe:

Build time: 45 seconds (previously 12 seconds before adding SelectPdf)
Package restore: Downloading Select.Pdf.NetCore 25.2.0 (105.33 MB)
Conversion time: 3,000ms for single-page HTML document

On production servers, the symptoms become more severe:

Request timeout after 60 seconds
Conversion completed in 210,000ms (3.5 minutes)
Memory usage spike during conversion: 500MB+ for simple documents

Developers debugging performance often enable timing instrumentation:

var stopwatch = Stopwatch.StartNew();
var doc = converter.ConvertHtmlString(html);
stopwatch.Stop();
Console.WriteLine($"Conversion time: {stopwatch.ElapsedMilliseconds}ms");
// Output: Conversion time: 3247ms (simple HTML document)

Who Is Affected

SelectPdf performance issues impact several categories of developers and deployment scenarios:

Development Environment Impact:

Teams using CI/CD pipelines experience extended build times
Developers on slower machines face compounded delays
Projects with frequent build-test cycles suffer productivity losses
Cold builds after cache clearing take significantly longer

Runtime Performance Impact:

Web applications generating PDFs synchronously
Batch processing systems creating multiple documents
Report generation features where users wait for PDF output
High-traffic applications where conversion latency affects throughput

Deployment Scenarios:

Docker containers with SelectPdf experience large image sizes
Azure App Service deployments require Basic tier or higher
Serverless functions face cold start penalties
Kubernetes pods with memory limits may hit constraints

Evidence from the Developer Community

Performance complaints about SelectPdf appear across multiple platforms, with consistent themes around build impact and conversion speed.

Timeline

Date	Event	Source
2016-06	Bubble.io users report "really really slow" export	Bubble Forum
2019-06	GitHub issue opened: "Converting html to pdf takes 3 seconds"	GitHub
2020-07	PDF.js issue reports slow rendering of SelectPdf output	Mozilla GitHub
2021-12	Large data issues and out of memory reports	GitHub
2025-01	Issue remains open, no resolution provided	-

Community Reports

"I like SelectPDF very much, but it takes 3 seconds to convert html to pdf on .NET Core 2.1"
-- Developer, GitHub Issue #7, June 2019

The GitHub issue remains open, with the SelectPdf team responding that performance can be improved by disabling various features, but not providing a fundamental fix for the baseline conversion overhead.

"It takes 3 seconds to convert html to pdf on .NET Core... The same conversion takes about 3.5 minutes on the web server."
-- Stack Overflow discussion, cited in multiple forums

This disparity between local development performance and production server performance indicates environmental factors compound the base performance issues.

On the Bubble.io forum, users running SelectPdf through an integration plugin described the export process as "really really slow" for invoice generation, with the thread spanning multiple pages of developers sharing similar experiences.

Package Size Analysis

The NuGet package sizes directly impact build performance:

Package	Version	Size
Select.Pdf	25.2.0	75.61 MB
Select.Pdf.NetCore	25.2.0	105.33 MB
Select.HtmlToPdf	25.2.0	65.97 MB
Select.Pdf.x64	19.1.0	83.99 MB
Select.Pdf.NetCore.Blink	25.2.0	Additional Chromium folder

For comparison, typical .NET NuGet packages range from 100 KB to 5 MB. SelectPdf packages are 15-100 times larger than average.

Root Cause Analysis

SelectPdf's performance characteristics stem from its architectural design decisions:

Package Size Contributors:

Multiple Rendering Engines: SelectPdf includes both WebKit and Blink (Chromium) rendering engines. Each engine requires substantial native binaries.
Bundled Dependencies: The Select.Html.dep and Select.Tools.dep files contain the actual rendering logic and must be deployed alongside the main assembly.
Chromium Inclusion: When using the Blink engine (required for modern HTML/CSS support), the package includes a full Chromium-124.0.6367.201 folder with browser binaries.
Cross-Platform Support Overhead: The .NET Core package includes binaries for multiple architectures, inflating the package size.

Conversion Speed Contributors:

Process Spawning: SelectPdf spawns external processes (Select.Html.dep) for each conversion, adding process creation overhead.
Engine Initialization: Each conversion may reinitialize the rendering engine, particularly in serverless or containerized environments without warm instances.
Default Configuration: The default settings enable JavaScript, plugins, and other features that add processing time even when not needed.
Memory Management: Developers report that memory is not efficiently released between conversions, leading to garbage collection pauses that affect subsequent operations.

Server Environment Factors:

Production servers often perform worse than development machines due to:

Reduced CPU allocation in shared hosting
Memory pressure from concurrent operations
Cold starts in containerized deployments
Azure App Service sandbox restrictions (requiring restricted rendering engine)

Attempted Workarounds

The SelectPdf documentation and community suggest several performance optimization approaches.

Workaround 1: Disable Unnecessary Features

Approach: Reduce conversion overhead by disabling features not required for the specific use case.

var converter = new HtmlToPdf();

// Disable JavaScript if not needed
converter.Options.JavaScriptEnabled = false;

// Disable image compression processing
converter.Options.JpegCompressionEnabled = false;

// Skip font embedding
converter.Options.EmbedFonts = false;

// Disable plugins
converter.Options.PluginsEnabled = false;

// Set minimum page load time to zero
converter.Options.MinPageLoadTime = 0;

// Use fastest compression
converter.Options.PdfCompressionLevel = PdfCompressionLevel.NoCompression;

Limitations:

Disabling JavaScript breaks dynamic content
No compression increases file sizes
Feature stripping may not address core process overhead
Reported improvements are modest (10-30% reduction, not elimination)

Workaround 2: Switch to Blink Rendering Engine

Approach: Use the Chromium-based Blink engine instead of WebKit.

converter.Options.RenderingEngine = RenderingEngine.Blink;

Limitations:

Blink packages are even larger, increasing build times
Requires .NET Framework 4.6.1+ or .NET Core
Some SelectPdf features unavailable with Blink (bookmarks, post data, partial rendering)
Does not address the fundamental 3-second baseline delay

Workaround 3: Font Caching Configuration

Approach: Configure font caching to use filesystem instead of memory.

Limitations:

Helps in specific scenarios where font loading is the bottleneck
Does not address core conversion overhead
Requires writable filesystem access, complicating containerized deployments

Workaround 4: Increase Timeouts

Approach: Extend timeout settings to prevent failures on slow conversions.

converter.Options.MaxPageLoadTime = 120; // 120 seconds timeout

Limitations:

Does not improve performance, only prevents timeout errors
Users still experience the full delay
Ties up server resources during extended conversions
Masks the underlying performance problem

A Different Approach: IronPDF

IronPDF's architecture prioritizes conversion speed through a different technical approach. Rather than spawning external processes and initializing rendering engines per-conversion, IronPDF maintains a managed Chromium instance that handles conversions with minimal overhead.

Why IronPDF Performs Differently

The architectural differences that affect performance:

Managed Chromium Instance: IronPDF manages the Chromium rendering engine lifecycle, avoiding repeated initialization costs.
Direct Integration: Conversions occur within the .NET process rather than through inter-process communication with external executables.
Optimized Binaries: Platform-specific native components are loaded once and reused across conversions.
Streaming Architecture: Large documents can be processed without loading entirely into memory.

Performance testing in independent comparisons shows sub-second conversion for standard web pages, compared to SelectPdf's 2-3 second baseline.

Code Example

using IronPdf;
using System.Diagnostics;

/// <summary>
/// Demonstrates high-performance HTML to PDF conversion.
/// IronPDF's ChromePdfRenderer maintains an optimized rendering context
/// that avoids the per-conversion initialization overhead.
/// </summary>
public class HighPerformancePdfGenerator
{
    private readonly ChromePdfRenderer _renderer;

    public HighPerformancePdfGenerator()
    {
        // Renderer initialization happens once
        // Subsequent conversions reuse the initialized context
        _renderer = new ChromePdfRenderer();

        // Configure rendering options
        _renderer.RenderingOptions.PaperSize = IronPdf.Rendering.PdfPaperSize.A4;
        _renderer.RenderingOptions.MarginTop = 20;
        _renderer.RenderingOptions.MarginBottom = 20;
    }

    public byte[] ConvertHtmlToPdf(string htmlContent)
    {
        // Conversion benefits from already-initialized renderer
        var pdf = _renderer.RenderHtmlAsPdf(htmlContent);
        return pdf.BinaryData;
    }

    public void ConvertWithTiming(string htmlContent, string outputPath)
    {
        var stopwatch = Stopwatch.StartNew();

        var pdf = _renderer.RenderHtmlAsPdf(htmlContent);
        pdf.SaveAs(outputPath);

        stopwatch.Stop();
        Console.WriteLine($"Conversion completed in {stopwatch.ElapsedMilliseconds}ms");
        // Typical output: Conversion completed in 247ms
    }
}

Key points about this code:

The ChromePdfRenderer instance can be reused across multiple conversions
Initialization cost is paid once, not per-conversion
Memory management is handled within the .NET runtime
No external process spawning required

Batch Processing Example

using IronPdf;
using System.Collections.Generic;
using System.Threading.Tasks;

/// <summary>
/// Demonstrates efficient batch PDF generation.
/// IronPDF supports parallel conversions without the process-spawning
/// overhead that limits SelectPdf batch performance.
/// </summary>
public class BatchPdfProcessor
{
    public async Task<List<byte[]>> ProcessBatchAsync(List<string> htmlDocuments)
    {
        var renderer = new ChromePdfRenderer();
        var results = new List<byte[]>();

        // Process documents with efficient resource utilization
        foreach (var html in htmlDocuments)
        {
            var pdf = renderer.RenderHtmlAsPdf(html);
            results.Add(pdf.BinaryData);
        }

        return results;
    }

    public async Task ProcessLargeVolumeAsync(IEnumerable<string> htmlDocuments)
    {
        var renderer = new ChromePdfRenderer();

        // For high-volume scenarios, IronPDF supports streaming output
        foreach (var html in htmlDocuments)
        {
            var pdf = renderer.RenderHtmlAsPdf(html);

            // Stream directly to storage without holding all PDFs in memory
            using (var stream = pdf.Stream)
            {
                // Write to file system, blob storage, or other destination
                await SaveToStorageAsync(stream);
            }
        }
    }

    private async Task SaveToStorageAsync(System.IO.Stream pdfStream)
    {
        // Implementation depends on storage destination
    }
}

API Reference

For comprehensive documentation on performance optimization:

Migration Considerations

Licensing

IronPDF uses a commercial license model:

Free development and testing with watermark
Lite license starts at $749 (perpetual)
Higher tiers available for multiple projects and enterprise needs
Pricing details

SelectPdf also uses commercial licensing, with the Community Edition limited to 5 pages per document.

API Differences

The migration requires updating class names and method calls:

SelectPdf:

var converter = new HtmlToPdf();
converter.Options.PdfPageSize = PdfPageSize.A4;
converter.Options.JavaScriptEnabled = false;
var doc = converter.ConvertHtmlString(html);
doc.Save("output.pdf");

IronPDF:

var renderer = new ChromePdfRenderer();
renderer.RenderingOptions.PaperSize = PdfPaperSize.A4;
renderer.RenderingOptions.EnableJavaScript = false;
var pdf = renderer.RenderHtmlAsPdf(html);
pdf.SaveAs("output.pdf");

SelectPdf	IronPDF
`HtmlToPdf`	`ChromePdfRenderer`
`ConvertHtmlString()`	`RenderHtmlAsPdf()`
`ConvertUrl()`	`RenderUrlAsPdf()`
`Options.PdfPageSize`	`RenderingOptions.PaperSize`
`doc.Save()`	`pdf.SaveAs()`

What You Gain

Sub-second conversion times for typical documents
Reduced build times (smaller package footprint relative to features)
Consistent performance between development and production
Cross-platform support (Windows, Linux, macOS)
Docker and Azure compatibility without workarounds

What to Consider

Commercial license required for production
IronPDF package sizes are also substantial due to embedded Chromium
Memory usage patterns differ; evaluate for your specific workload
Initial renderer instantiation has a one-time cost

Conclusion

SelectPdf's 75-105 MB NuGet packages extend build times, and its process-spawning architecture introduces 3+ second conversion delays that can reach 3.5 minutes on production servers. While workarounds involving feature disabling provide marginal improvements, they do not address the fundamental architectural overhead. IronPDF's managed Chromium approach delivers sub-second conversions and avoids the repeated initialization costs that characterize SelectPdf's performance profile.

Jacob Mellor has spent 25+ years building developer tools, including IronPDF.

References

Converting html to pdf takes 3 seconds - GitHub Issue #7{:rel="nofollow"} - Original performance report on SelectPdf GitHub
Selectpdf really slow when exporting to PDF - Bubble Forum{:rel="nofollow"} - Community discussion of export performance
PDFs generated by selectpdf.com slow to render - Mozilla pdf.js Issue #12098{:rel="nofollow"} - Report on SelectPdf output rendering performance
Large data Issue using SelectPdf - GitHub Issue #22{:rel="nofollow"} - Memory and performance issues with large documents
SelectPdf Troubleshooting{:rel="nofollow"} - Official troubleshooting documentation
SelectPdf Conversion Delay{:rel="nofollow"} - Official documentation on timeout configuration
NuGet Gallery - Select.Pdf{:rel="nofollow"} - Package size and version information
NuGet Gallery - Select.Pdf.NetCore{:rel="nofollow"} - .NET Core package information

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

Puppeteer Zombie Processes and Browser Instances (Issue Fixed)

IronSoftware — Wed, 08 Apr 2026 06:32:00 +0000

Developers running Puppeteer or PuppeteerSharp in production often discover their servers accumulating orphaned Chrome processes that consume memory but never terminate. These zombie browser processes escape disposal calls, pile up under load, and eventually exhaust system resources. The problem intensifies in containerized environments where memory limits trigger OOM kills, and debugging becomes nearly impossible when logs scatter across dozens of orphaned browser instances.

The Problem

When Puppeteer launches a browser, it spawns multiple operating system processes: a main browser process, GPU process, network service, and renderer processes for each tab. These processes communicate with the Node.js or .NET application through WebSocket connections using the Chrome DevTools Protocol. The parent application sends commands and receives responses, but it does not directly control the lifecycle of these child processes.

Under normal conditions, calling browser.close() in Node.js or Browser.CloseAsync() in PuppeteerSharp signals the browser to terminate gracefully. The browser process should then exit, taking its child processes with it. In practice, this signal frequently fails to reach all processes, or the processes fail to respond to it. The result is a zombie process that remains in memory, consuming resources but no longer responding to commands.

The zombie process problem compounds under high-traffic conditions. Each failed disposal leaves behind processes consuming 100-300MB of RAM. With hundreds of PDF generation requests per hour, memory consumption climbs steadily. Server monitoring shows RAM usage increasing even when the application itself reports successful disposal. Eventually, the operating system intervenes with OOM kills, or the server becomes unresponsive.

Error Messages and Symptoms

Applications experiencing zombie browser processes typically encounter these errors and behaviors:

Error: Protocol error (Target.createTarget): Target closed.

TimeoutError: Timed out after 30000 ms while trying to connect to the browser!
Most likely the browser was closed.

Error: Browser disconnected unexpectedly (closed?)

PuppeteerSharp.TargetClosedException: Protocol error (Target.activateTarget):
Target closed. (Session closed. Most likely the page has been closed.)

Container killed with exit code 137 (OOM killed by kernel)

Error: ECONNREFUSED - Connection refused

Observable symptoms include:

Memory usage climbing without corresponding application load
ps aux | grep chrome showing dozens of orphaned Chrome processes
Application logs reporting successful browser disposal while processes remain
Container restarts due to memory limits without application errors
Browser launch operations timing out due to resource exhaustion
Server becoming unresponsive during peak traffic periods
Logs appearing fragmented across multiple Chrome process outputs

Who Is Affected

The zombie process issue affects deployments across multiple dimensions:

Container Deployments: Docker and Kubernetes environments suffer most severely. Containers typically run with memory ceilings (512MB-2GB), and each orphaned Chrome process consumes a substantial portion of that allocation. The OOM killer terminates containers abruptly, causing request failures and potential data loss.

Long-Running Server Applications: Web servers and background services running Puppeteer for PDF generation accumulate zombie processes over days or weeks of operation. The gradual memory growth is often mistaken for a memory leak in application code rather than orphaned browser processes.

Serverless Functions: AWS Lambda, Azure Functions, and Google Cloud Functions face unique challenges. Each function invocation may leave behind processes that persist beyond the function's execution timeout, consuming resources from subsequent invocations in warm containers.

CI/CD Pipelines: Build servers running Puppeteer for visual testing or screenshot generation accumulate zombie processes across multiple builds. Shared build agents eventually require manual intervention or restarts.

Linux Environments: Linux deployments face additional complexity because of how the kernel handles orphaned processes. When a parent process terminates without properly reaping its children, those children become zombies attached to PID 1 (init), where they remain until explicitly killed.

Evidence from the Developer Community

The zombie process problem is documented across GitHub issues, technical blogs, and developer forums spanning several years.

Timeline

Date	Event	Source
2019-01-15	Page.Dispose() never completing reported	GitHub Issue #122
2020-02-15	Chrome zombie processes in Docker documented	GitHub puppeteer Issue #5645
2021-08-17	DisposeAsync hanging in Docker reported	GitHub PuppeteerSharp Issue #1489
2022-06-01	Zombie Chrome processes in Kubernetes clusters	GitHub Issue #8695
2023-04-10	Multiple browser instances not closing properly	GitHub puppeteer Issue #10030
2024-01-15	Zombie Chrome processes in Docker/Kubernetes	GitHub puppeteer Issue #12854
2024-06-20	Browser version mismatch causing failures	Multiple GitHub discussions

Community Reports

"We found 47 orphaned Chrome processes on our production server. Each was consuming 150-200MB of RAM. The application logs showed all browsers had been properly closed."
— DevOps Engineer, Reddit r/node, 2023

"When running PuppeteerSharp with Docker, I'm finding quite a lot of zombie Chrome processes that never get killed. Even using tini as an entry point didn't resolve the issue."
— Developer, GitHub Issue #1489

"The browser.close() call completes successfully according to our logs, but the Chrome processes remain. We've resorted to periodically running pkill -f chromium in a cron job."
— Developer, Stack Overflow, 2023

"After upgrading Chrome, our entire PDF generation pipeline broke. The library version no longer matched the browser version, and we had no way to know until production failed."
— Developer, GitHub Discussion, 2024

Teams have reported that a healthy Puppeteer deployment typically shows 2-3 Chrome processes, but zombie accumulation can push this to 30+ processes before intervention becomes necessary.

Root Cause Analysis

The zombie process problem stems from several interconnected factors in Puppeteer's architecture and its interaction with operating systems.

WebSocket Communication Failures

Puppeteer communicates with Chrome through WebSocket connections. When network conditions, system load, or timing issues cause the WebSocket connection to fail before the close command completes, the browser process receives no termination signal. The process continues running, believing it still has an active client.

Process Tree Management

Chrome spawns multiple child processes that form a process tree. The main browser process is the parent of GPU processes, utility processes, and renderer processes. When the parent process terminates abnormally, its children may not receive termination signals, especially on Linux where SIGTERM propagation depends on process group configuration.

Docker and Container Isolation

Containers complicate process management significantly. The PID namespace isolation means Chrome processes see a different process hierarchy than the host system. Without an init process (like tini or Docker's --init flag), zombie processes cannot be reaped properly because there is no PID 1 process designed to adopt orphans.

Async Disposal Race Conditions

PuppeteerSharp's DisposeAsync() implementation has documented edge cases where the disposal task never completes. The method internally waits for the browser process to acknowledge shutdown, but if the acknowledgment is lost or delayed, the disposal hangs indefinitely. Developers have reported that DisposeAsync() calls simply never return in certain Docker configurations.

Version Management Complexity

Puppeteer downloads and manages its own Chromium version. When library updates change the expected Chromium version, existing deployments can break. Auto-update mechanisms in CI/CD environments can inadvertently upgrade Puppeteer without upgrading Chromium, or vice versa, causing version mismatches that manifest as silent failures or zombie processes.

Scattered Logging

Debugging zombie processes requires examining logs from multiple sources: the Node.js or .NET application, each Chrome process, and system logs. Chrome processes write to their own stdout/stderr streams, which may not be captured by application logging. This makes it difficult to correlate browser behavior with application state.

Attempted Workarounds

The developer community has developed various strategies to manage zombie processes, each with significant trade-offs.

Workaround 1: Using Docker's Init Process

Approach: Run containers with an init process that properly reaps zombie children.

FROM node:18-slim

# Install tini for proper process supervision
RUN apt-get update && apt-get install -y tini

# Install Chrome dependencies
RUN apt-get install -y \
    chromium \
    fonts-liberation \
    libasound2 \
    libatk-bridge2.0-0 \
    libatk1.0-0 \
    libcups2 \
    --no-install-recommends

ENTRYPOINT ["/usr/bin/tini", "--"]
CMD ["node", "app.js"]

Or using Docker's built-in init:

docker run --init --memory=1g your-puppeteer-app

Limitations:

Only addresses zombie reaping, not the root cause of failed disposals
Requires container configuration changes that may conflict with existing infrastructure
Does not prevent memory consumption before zombies are reaped
Cannot prevent processes from becoming zombies in the first place

Workaround 2: Aggressive Process Killing

Approach: Periodically kill all Chrome processes and restart the browser pool.

const { execSync } = require('child_process');

// Kill all Chrome processes - nuclear option
function killAllChromeProcesses() {
    try {
        if (process.platform === 'linux') {
            execSync('pkill -9 -f chromium || true');
            execSync('pkill -9 -f chrome || true');
        } else if (process.platform === 'darwin') {
            execSync('pkill -9 -f "Google Chrome" || true');
        }
    } catch (error) {
        // Ignore errors - processes may not exist
    }
}

// Run periodically
setInterval(killAllChromeProcesses, 60000 * 30); // Every 30 minutes

Limitations:

Kills active browser sessions, causing in-flight requests to fail
Creates race conditions with ongoing PDF generation
Not suitable for high-availability deployments
Crude approach that indicates architectural problems

Workaround 3: Browser Instance Pooling with Timeout

Approach: Maintain a pool of browser instances with forced recycling after a time limit.

const puppeteer = require('puppeteer');

class BrowserPool {
    constructor(maxAge = 300000, maxInstances = 3) {
        this.maxAge = maxAge;
        this.maxInstances = maxInstances;
        this.instances = [];
    }

    async getBrowser() {
        // Remove expired instances
        const now = Date.now();
        for (const instance of this.instances) {
            if (now - instance.createdAt > this.maxAge) {
                await this.destroyInstance(instance);
            }
        }
        this.instances = this.instances.filter(i => !i.destroyed);

        // Find available instance or create new one
        let instance = this.instances.find(i => !i.inUse);
        if (!instance && this.instances.length < this.maxInstances) {
            instance = await this.createInstance();
            this.instances.push(instance);
        }

        if (instance) {
            instance.inUse = true;
            return instance.browser;
        }

        throw new Error('No available browser instances');
    }

    async createInstance() {
        const browser = await puppeteer.launch({
            headless: 'new',
            args: ['--no-sandbox', '--disable-dev-shm-usage']
        });
        return {
            browser,
            createdAt: Date.now(),
            inUse: false,
            destroyed: false
        };
    }

    async destroyInstance(instance) {
        instance.destroyed = true;
        try {
            await Promise.race([
                instance.browser.close(),
                new Promise((_, reject) =>
                    setTimeout(() => reject(new Error('Close timeout')), 5000)
                )
            ]);
        } catch (error) {
            // Force kill if close times out
            const pid = instance.browser.process()?.pid;
            if (pid) {
                try {
                    process.kill(pid, 'SIGKILL');
                } catch (e) {
                    // Process may already be dead
                }
            }
        }
    }

    release(browser) {
        const instance = this.instances.find(i => i.browser === browser);
        if (instance) {
            instance.inUse = false;
        }
    }
}

Limitations:

Complex implementation with potential for bugs
Forced destruction can still leave zombie child processes
Pool management adds latency and resource overhead
Does not solve the fundamental disposal problem

Workaround 4: Monitor and Alert on Process Count

Approach: Track Chrome process count and alert when it exceeds thresholds.

const { exec } = require('child_process');
const { promisify } = require('util');
const execAsync = promisify(exec);

async function countChromeProcesses() {
    const { stdout } = await execAsync('pgrep -c chromium || echo 0');
    return parseInt(stdout.trim(), 10);
}

async function monitorProcesses() {
    const count = await countChromeProcesses();
    const expectedMax = 6; // 2 browsers * 3 processes each

    if (count > expectedMax) {
        console.error(`WARNING: ${count} Chrome processes detected (expected max: ${expectedMax})`);
        // Send alert to monitoring system
        // Consider triggering cleanup or restart
    }
}

setInterval(monitorProcesses, 30000);

Limitations:

Reactive rather than preventive
Requires external monitoring infrastructure
Alert fatigue if thresholds are too sensitive
Does not fix the underlying issue

Workaround 5: Version Pinning

Approach: Pin both Puppeteer and Chromium versions to prevent auto-update breakage.

{
  "dependencies": {
    "puppeteer": "21.5.0"
  }
}

const puppeteer = require('puppeteer');

async function launchWithSpecificVersion() {
    const browser = await puppeteer.launch({
        executablePath: '/usr/bin/chromium-browser', // Use system Chromium
        headless: 'new'
    });
    return browser;
}

Limitations:

Security updates require manual intervention
System Chromium may have different behavior than bundled version
Coordination required across development, staging, and production
Does not prevent zombie processes, only reduces one cause

A Different Approach: IronPDF

For .NET applications where managing Chromium processes has become a maintenance burden, IronPDF offers an alternative that eliminates the process management problem entirely. Instead of spawning external browser processes that must be tracked and disposed, IronPDF embeds the Chrome rendering engine within the .NET process itself.

Why IronPDF Avoids Zombie Processes

IronPDF's architecture is fundamentally different from Puppeteer's external process model:

Single Process Architecture: The Chrome rendering engine runs as part of the .NET application process, not as a separate executable. There are no external Chrome processes to become zombies because there are no external processes at all.

Standard .NET Disposal: Memory and resources are managed through normal .NET garbage collection and IDisposable patterns. When a PdfDocument is disposed, its resources are released through the same mechanisms as any other .NET object.

No WebSocket Communication: Without external processes, there is no WebSocket protocol layer that can fail, time out, or lose messages. Commands execute directly within the application's memory space.

No Version Coordination: The rendering engine version is fixed to the IronPDF library version. Upgrading IronPDF upgrades the rendering engine automatically, eliminating version mismatch issues.

Unified Logging: All rendering activity occurs within the application process, meaning logs appear in the application's standard output without scattering across multiple process streams.

Code Example

using IronPdf;
using System;
using System.Collections.Generic;
using System.Threading.Tasks;

// PDF generation service demonstrating process-stable operation
// No external Chrome processes to manage or monitor
public class StablePdfService
{
    private readonly ChromePdfRenderer _renderer;

    public StablePdfService()
    {
        // Initialize renderer once - no browser launch needed
        _renderer = new ChromePdfRenderer();

        // Configure rendering options
        _renderer.RenderingOptions.PaperSize = IronPdf.Rendering.PdfPaperSize.A4;
        _renderer.RenderingOptions.MarginTop = 25;
        _renderer.RenderingOptions.MarginBottom = 25;
    }

    public byte[] GeneratePdf(string htmlContent)
    {
        // Render HTML to PDF - no external process spawned
        // No zombie process possible because no process is created
        using (var pdf = _renderer.RenderHtmlAsPdf(htmlContent))
        {
            return pdf.BinaryData;
        }
        // Memory released through standard .NET disposal
    }

    public async Task<List<byte[]>> GenerateBatchAsync(IEnumerable<string> htmlDocuments)
    {
        var results = new List<byte[]>();

        // Process multiple PDFs without process accumulation
        foreach (var html in htmlDocuments)
        {
            using (var pdf = _renderer.RenderHtmlAsPdf(html))
            {
                results.Add(pdf.BinaryData);
            }
            // Each PDF is fully released before the next begins
            // No process monitoring required
        }

        return results;
    }

    public byte[] GenerateFromUrl(string url)
    {
        // Render external URL with JavaScript execution
        // Chrome engine runs internally, not as separate process
        using (var pdf = _renderer.RenderUrlAsPdf(url))
        {
            return pdf.BinaryData;
        }
    }
}

// Docker deployment - no init process or process supervision required
public class DockerCompatibleService
{
    public byte[] GenerateInContainer(string html)
    {
        // Works in standard Docker containers without --init flag
        // No zombie processes to reap because no external processes exist
        var renderer = new ChromePdfRenderer();

        using (var pdf = renderer.RenderHtmlAsPdf(html))
        {
            return pdf.BinaryData;
        }
    }
}

Key points about this code:

No browser launch, close, or disposal methods to call
No WebSocket connections that can fail or time out
Standard using statements handle all resource cleanup
Process count remains constant regardless of PDF volume
Container deployments require no special configuration
Logs appear in application output, not scattered across processes

API Reference

For more details on the methods used:

ChromePdfRenderer - Main rendering class
RenderHtmlAsPdf - HTML to PDF conversion
RenderUrlAsPdf - URL to PDF conversion
Docker Deployment Guide - Container configuration

Migration Considerations

Licensing

IronPDF is commercial software requiring a license for production deployment. Licenses are per-developer and include deployment to unlimited servers. A free trial is available for evaluation. Teams should weigh licensing costs against the engineering time currently spent managing Puppeteer processes and the infrastructure costs of running containers with extra headroom for zombie processes.

API Differences

Puppeteer exposes browser automation primitives (launch browser, create page, navigate, execute script, generate PDF). IronPDF provides a direct path from HTML to PDF without the browser automation layer. Migration involves:

Removing Puppeteer.launch() / BrowserFetcher code entirely
Replacing page creation and navigation with RenderHtmlAsPdf() or RenderUrlAsPdf()
Removing disposal code for browsers and pages
Removing process monitoring and cleanup infrastructure
Removing Docker init process configuration

For applications using Puppeteer purely for PDF generation, this simplifies the codebase significantly. For applications using Puppeteer for other browser automation (testing, scraping), IronPDF addresses only the PDF portion.

What You Gain

Zero external processes to manage, monitor, or clean up
No zombie process accumulation under any load conditions
Predictable memory usage bounded by application behavior
Simplified Docker deployments without init processes
Unified logging through application output
No version coordination between library and browser
Consistent behavior across Windows, Linux, and macOS

What to Consider

Commercial licensing versus open-source Puppeteer
IronPDF is specific to PDF generation; Puppeteer offers broader browser automation
Different rendering engine may produce slightly different output
Initial integration adds the IronPDF package (approximately 150MB)

Conclusion

Puppeteer's external process architecture creates inherent challenges when browser disposal fails. Zombie Chrome processes accumulate under load, exhaust container memory limits, and scatter debugging information across multiple process outputs. Version management between library and browser adds another failure mode. For .NET applications where PDF generation is the primary use case, IronPDF eliminates these issues by removing external processes from the architecture entirely.

Jacob Mellor is CTO at Iron Software and built the company's core codebase, pioneering C# PDF technology.

References

Page.Dispose() never completing - GitHub Issue #122{:rel="nofollow"} - Early disposal issue documentation
DisposeAsync hanging in Docker - GitHub Issue #1489{:rel="nofollow"} - PuppeteerSharp disposal hanging
Chrome zombie processes in Docker - GitHub Issue #5645{:rel="nofollow"} - Container zombie process reports
Docker container memory always increasing - GitHub Issue #8695{:rel="nofollow"} - Memory growth in containers
Zombie Chrome processes in Docker/Kubernetes - GitHub Issue #12854{:rel="nofollow"} - Orchestration environment issues
Browser instances not closing properly - GitHub Issue #10030{:rel="nofollow"} - Multiple browser disposal failures
Puppeteer Zombie Process Solution - Medium{:rel="nofollow"} - Community workaround documentation
Puppeteer Troubleshooting Guide{:rel="nofollow"} - Official troubleshooting documentation
How to workaround RAM-leaking libraries like Puppeteer - DevForth{:rel="nofollow"} - Memory management strategies
The Hidden Cost of Headless Browsers - Medium{:rel="nofollow"} - Production memory leak journey

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

FO.NET vs IronPDF: an unbiased look for .NET teams

IronSoftware — Mon, 06 Apr 2026 12:54:00 +0000

Picture a scenario common in enterprise .NET environments: a report generation system built in 2012 using FO.NET suddenly needs updates for compliance reporting, but the original library has been dormant on CodePlex for nearly a decade, the maintainer unreachable, and .NET 6 deployment throws compatibility warnings. This isn't hypothetical—teams encounter this situation when legacy XSL-FO pipelines collide with modern infrastructure requirements. FO.NET was designed for precise XML-based page layout, targeting applications where data arrives as XML and must render with millimeter-level positioning accuracy.

IronPDF approaches document generation from the opposite direction: it assumes your layout is expressed in HTML/CSS (the universal design language of the web) and renders PDFs using a Chromium engine. This architectural choice reflects the reality of 2026 .NET development, where most teams already use HTML for web UIs and prefer reusing those skills for PDF generation rather than learning XSL-FO's specialized syntax.

Understanding IronPDF

IronPDF is a .NET library built around HTML-to-PDF conversion, leveraging Chromium's rendering engine to produce PDFs that match browser output. Teams adopt it when they need to convert web pages, Razor views, or dynamically generated HTML into distributable documents. The library handles modern CSS (Grid, Flexbox), JavaScript execution, and web fonts, ensuring that complex layouts render correctly without manual coordinate positioning.

Beyond rendering, IronPDF provides full PDF lifecycle management: merging documents, extracting text, filling forms, applying digital signatures, encrypting files, and manipulating pages. The API is designed for developers already familiar with HTML/CSS, eliminating the learning curve associated with XSL-FO's formatting object model.

Key Limitations of FO.NET

Product Status

FO.NET is effectively discontinued. The original CodePlex project is defunct. Several GitHub forks exist (nholik, hahmed, leekelleher) but show minimal activity post-2018. No official maintainer, no roadmap, no security patches. Teams using FO.NET are maintaining legacy code with no upstream support.

Missing Capabilities

No .NET Core or .NET 5+ support in any known fork. XSL-FO spec is frozen (W3C Recommendation from 2006); no modern CSS features. Cannot render HTML directly—requires XSLT transformation to XSL-FO first. No built-in support for interactive PDF forms, digital signatures, or modern encryption standards (AES-256).

Technical Issues

XSL-FO learning curve is steep: developers must learn formatting objects (fo:block, fo:table, fo:page-sequence) instead of reusing HTML/CSS knowledge. XSLT transformations add a pre-processing step. Font embedding is manual and error-prone. Limited Unicode support depending on font configuration. Performance degrades with large documents or complex tables.

Support Status

No commercial support available. Community support via GitHub forks is sporadic. Documentation is primarily the W3C XSL-FO spec plus Apache FOP guides (Java-focused). Troubleshooting requires forum archaeology or source code diving.

Architecture Problems

Two-stage pipeline (XML → XSL-FO → PDF) adds failure points. XSLT debugging is notoriously difficult. Cannot leverage modern web design tools (browser DevTools, CSS frameworks). Tight coupling to XML data sources—JSON or object models require conversion. No browser-based preview; must generate PDF to see results.

Feature Comparison Overview

Aspect	FO.NET	IronPDF
Current Status	Discontinued/unmaintained forks	Active commercial development
HTML Support	No (XSL-FO only)	Full HTML5/CSS3/JavaScript
Rendering Quality	Coordinate-based precision	Chromium pixel-perfect
Installation	Manual DLL or unofficial NuGet	Official NuGet, self-contained
Support	None	Commercial SLA available
Future Viability	Legacy maintenance only	Continuous updates

Troubleshooting Scenario: Page Break Issues

FO.NET — XSL-FO Page Break Control

<!-- XSL-FO document structure (verify syntax in W3C spec) -->
<fo:root xmlns:fo="http://www.w3.org/1999/XSL/Format">
  <fo:layout-master-set>
    <fo:simple-page-master master-name="A4">
      <fo:region-body margin="1in"/>
    </fo:simple-page-master>
  </fo:layout-master-set>

  <fo:page-sequence master-reference="A4">
    <fo:flow flow-name="xsl-region-body">

      <fo:block font-size="18pt" space-after="12pt">
        Section 1: Introduction
      </fo:block>
      <fo:block>Content for section 1...</fo:block>

      <!-- Force page break -->
      <fo:block break-before="page"/>

      <fo:block font-size="18pt" space-after="12pt">
        Section 2: Details
      </fo:block>
      <fo:block>Content for section 2...</fo:block>

      <!-- Keep content together on same page -->
      <fo:block keep-together="always">
        <fo:block font-weight="bold">Critical Data:</fo:block>
        <fo:table>
          <fo:table-column column-width="3in"/>
          <fo:table-column column-width="2in"/>
          <fo:table-body>
            <fo:table-row>
              <fo:table-cell><fo:block>Metric A</fo:block></fo:table-cell>
              <fo:table-cell><fo:block>Value 1</fo:block></fo:table-cell>
            </fo:table-row>
          </fo:table-body>
        </fo:table>
      </fo:block>

    </fo:flow>
  </fo:page-sequence>
</fo:root>

// C# code to process XSL-FO (conceptual - verify API in specific FO.NET fork)
// Note: Exact implementation varies by fork and may not work on modern .NET
using System;
using System.IO;
using System.Xml;

namespace FoNetExample
{
    class Program
    {
        static void Main(string[] args)
        {
            // Typical workflow (verify against fork documentation):
            // 1. Load XSL-FO document
            // 2. Create FO processor
            // 3. Render to PDF

            // WARNING: This is conceptual code
            // FO.NET forks have inconsistent APIs
            // Refer to specific fork documentation

            try
            {
                var foDocument = new XmlDocument();
                foDocument.Load("report.fo");

                // FO.NET processor creation (API varies by fork)
                // Some forks use: FoNet.Render.Pdf.PdfRenderer
                // Documentation is sparse - expect trial and error

                Console.WriteLine("Check fork-specific documentation for exact API");
            }
            catch (Exception ex)
            {
                Console.WriteLine($"Error: {ex.Message}");
            }
        }
    }
}

Common troubleshooting issues:

Page break ignored: XSL-FO break-before may not trigger if preceding content doesn't fill the page; use fo:block with explicit height to force breaks
Content split unexpectedly: keep-together="always" can cause overflow errors if content exceeds page height; no automatic graceful degradation
Table rendering issues: Column widths must be explicitly set; auto-sizing doesn't work reliably
Font embedding failures: Fonts must be registered manually; missing fonts cause silent substitution or rendering errors
Namespace errors: XSL-FO namespace must match exactly: http://www.w3.org/1999/XSL/Format
No preview workflow: Must generate full PDF to see layout; no incremental rendering

IronPDF — CSS-Based Page Control

using IronPdf;
using System;

namespace IronPdfPageBreakExample
{
    class Program
    {
        static void Main(string[] args)
        {
            var htmlWithPageBreaks = @"
                <html>
                <head>
                    <style>
                        body { font-family: Arial, sans-serif; }
                        h1 { font-size: 18pt; margin-bottom: 12pt; }
                        .page-break { page-break-before: always; }
                        .keep-together { page-break-inside: avoid; }
                        table { border-collapse: collapse; width: 100%; }
                        td { border: 1px solid #ccc; padding: 8px; }
                    </style>
                </head>
                <body>
                    <h1>Section 1: Introduction</h1>
                    <p>Content for section 1...</p>

                    <div class='page-break'></div>

                    <h1>Section 2: Details</h1>
                    <p>Content for section 2...</p>

                    <div class='keep-together'>
                        <strong>Critical Data:</strong>
                        <table>
                            <tr><td>Metric A</td><td>Value 1</td></tr>
                            <tr><td>Metric B</td><td>Value 2</td></tr>
                        </table>
                    </div>
                </body>
                </html>";

            var renderer = new ChromePdfRenderer();
            renderer.RenderingOptions.PaperSize = IronPdf.Rendering.PdfPaperSize.A4;
            renderer.RenderingOptions.MarginTop = 72; // 1 inch = 72 points
            renderer.RenderingOptions.MarginBottom = 72;

            var pdf = renderer.RenderHtmlAsPdf(htmlWithPageBreaks);
            pdf.SaveAs("SectionedReport.pdf");

            Console.WriteLine("PDF created with controlled page breaks");
            pdf.Dispose();
        }
    }
}

CSS page-break-before and page-break-inside work as expected in browsers, making layout predictable. For complex page break scenarios—widow/orphan control, running headers—see IronPDF's HTML to PDF guide.

Troubleshooting Scenario: Font Rendering Problems

FO.NET — Manual Font Configuration

<!-- XSL-FO font configuration (verify exact syntax in fork docs) -->
<fo:root xmlns:fo="http://www.w3.org/1999/XSL/Format">
  <fo:layout-master-set>
    <fo:simple-page-master master-name="main">
      <fo:region-body margin="1in"/>
    </fo:simple-page-master>
  </fo:layout-master-set>

  <fo:page-sequence master-reference="main">
    <fo:flow flow-name="xsl-region-body">

      <fo:block font-family="Arial" font-size="12pt">
        Standard Arial text
      </fo:block>

      <fo:block font-family="CustomFont" font-size="14pt">
        Custom font text (requires font file registration)
      </fo:block>

      <fo:block font-family="Arial" font-weight="bold">
        Bold text
      </fo:block>

    </fo:flow>
  </fo:page-sequence>
</fo:root>

Common font troubleshooting:

Font not found: FO.NET doesn't auto-discover system fonts; must register font files in configuration (exact method varies by fork)
Fallback substitution: If specified font missing, FO.NET silently uses default sans-serif; no warning or error
Bold/italic failures: Font variations (Arial Bold, Arial Italic) must be registered separately as distinct font families
Unicode characters missing: Font must contain glyphs for characters used; limited Unicode support depending on font
Embedding issues: PDF may not embed fonts correctly, causing rendering problems on different systems
Configuration file complexity: Font registration typically requires XML config file with exact paths to TTF files

IronPDF — Automatic Font Handling

using IronPdf;
using System;

namespace IronPdfFontExample
{
    class Program
    {
        static void Main(string[] args)
        {
            var htmlWithFonts = @"
                <html>
                <head>
                    <style>
                        body { font-family: Arial, sans-serif; }
                        .custom-font { font-family: 'Roboto', Arial, sans-serif; }
                        .bold-text { font-weight: bold; }
                    </style>
                    <link href='https://fonts.googleapis.com/css2?family=Roboto:wght@400;700&display=swap'
                          rel='stylesheet'>
                </head>
                <body>
                    <p>Standard Arial text</p>
                    <p class='custom-font'>Custom Roboto font text</p>
                    <p class='bold-text'>Bold text</p>
                    <p>Unicode test: こんにちは 你好 مرحبا</p>
                </body>
                </html>";

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

            var pdf = renderer.RenderHtmlAsPdf(htmlWithFonts);
            pdf.SaveAs("FontTestReport.pdf");

            Console.WriteLine("PDF with various fonts created");
            pdf.Dispose();
        }
    }
}

IronPDF's Chromium engine handles fonts like a browser: system fonts work automatically, web fonts load from CDNs, and Unicode support is comprehensive. No manual configuration required.

Troubleshooting Scenario: Dynamic Table Generation

FO.NET — XSL-FO Table Construction

<!-- XSL-FO table with data binding (typically generated via XSLT) -->
<fo:root xmlns:fo="http://www.w3.org/1999/XSL/Format">
  <fo:layout-master-set>
    <fo:simple-page-master master-name="table-page">
      <fo:region-body margin="0.5in"/>
    </fo:simple-page-master>
  </fo:layout-master-set>

  <fo:page-sequence master-reference="table-page">
    <fo:flow flow-name="xsl-region-body">

      <fo:table table-layout="fixed" width="100%">
        <fo:table-column column-width="proportional-column-width(2)"/>
        <fo:table-column column-width="proportional-column-width(1)"/>
        <fo:table-column column-width="proportional-column-width(1)"/>

        <fo:table-header>
          <fo:table-row background-color="#cccccc">
            <fo:table-cell border="1pt solid black" padding="4pt">
              <fo:block font-weight="bold">Product</fo:block>
            </fo:table-cell>
            <fo:table-cell border="1pt solid black" padding="4pt">
              <fo:block font-weight="bold">Quantity</fo:block>
            </fo:table-cell>
            <fo:table-cell border="1pt solid black" padding="4pt">
              <fo:block font-weight="bold">Price</fo:block>
            </fo:table-cell>
          </fo:table-row>
        </fo:table-header>

        <fo:table-body>
          <!-- Data rows - typically generated via XSLT loop -->
          <fo:table-row>
            <fo:table-cell border="1pt solid black" padding="4pt">
              <fo:block>Item A</fo:block>
            </fo:table-cell>
            <fo:table-cell border="1pt solid black" padding="4pt">
              <fo:block>100</fo:block>
            </fo:table-cell>
            <fo:table-cell border="1pt solid black" padding="4pt">
              <fo:block>$50.00</fo:block>
            </fo:table-cell>
          </fo:table-row>
        </fo:table-body>
      </fo:table>

    </fo:flow>
  </fo:page-sequence>
</fo:root>

Common table troubleshooting:

Column width calculation errors: proportional-column-width() doesn't always distribute space as expected; fixed widths more reliable
Border rendering gaps: Borders may not align correctly at cell intersections; workaround involves careful padding/border settings
Header repetition on page breaks: fo:table-header should repeat on each page, but implementation varies by fork
Cell content overflow: Long text in cells doesn't wrap automatically; must use wrap-option="wrap" and test thoroughly
Performance degradation: Large tables (1000+ rows) can cause severe slowdowns; XSL-FO processors aren't optimized for data tables
No auto-sizing: Column widths must be calculated manually; no "fit content to column" feature

IronPDF — HTML Table Rendering

using IronPdf;
using System;
using System.Text;

namespace IronPdfTableExample
{
    class Program
    {
        static void Main(string[] args)
        {
            var tableHtml = GenerateTableHtml(1000); // Generate large table

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

            var pdf = renderer.RenderHtmlAsPdf(tableHtml);
            pdf.SaveAs("LargeDataTable.pdf");

            Console.WriteLine("Large table PDF created");
            pdf.Dispose();
        }

        static string GenerateTableHtml(int rowCount)
        {
            var sb = new StringBuilder();
            sb.AppendLine("<html><head><style>");
            sb.AppendLine("table { width: 100%; border-collapse: collapse; }");
            sb.AppendLine("th { background-color: #ccc; padding: 8px; border: 1px solid black; }");
            sb.AppendLine("td { padding: 8px; border: 1px solid black; }");
            sb.AppendLine("thead { display: table-header-group; }"); // Repeat header
            sb.AppendLine("</style></head><body>");
            sb.AppendLine("<table>");
            sb.AppendLine("<thead><tr><th>Product</th><th>Quantity</th><th>Price</th></tr></thead>");
            sb.AppendLine("<tbody>");

            for (int i = 0; i < rowCount; i++)
            {
                sb.AppendLine($"<tr><td>Item {i}</td><td>{i * 10}</td><td>${i * 5.50:F2}</td></tr>");
            }

            sb.AppendLine("</tbody></table></body></html>");
            return sb.ToString();
        }
    }
}

HTML tables handle automatic column sizing, text wrapping, and header repetition without manual intervention. The thead element automatically repeats on page breaks.

API Mapping Reference

FO.NET Operation	XSL-FO Syntax	IronPDF Equivalent	Notes
Page setup	`<fo:simple-page-master>`	`RenderingOptions.PaperSize`	XSL-FO: XML config; IronPDF: property
Margins	`<fo:region-body margin="">`	`RenderingOptions.MarginTop/Bottom/etc`	FO.NET: layout master; IronPDF: options
Font selection	`font-family="Arial"`	CSS `font-family: Arial;`	XSL-FO: attribute; IronPDF: CSS
Bold text	`font-weight="bold"`	CSS `font-weight: bold;`	Same concept, different syntax
Page breaks	`break-before="page"`	CSS `page-break-before: always;`	XSL-FO: attribute; IronPDF: CSS
Keep content together	`keep-together="always"`	CSS `page-break-inside: avoid;`	Different property names
Tables	`<fo:table>` structure	`<table>` HTML element	XSL-FO: verbose XML; IronPDF: standard HTML
Table columns	`<fo:table-column>`	CSS `width` on `<th>`/`<td>`	FO.NET: explicit; IronPDF: auto-sizing
Headers/footers	`<fo:static-content>`	`RenderingOptions.TextHeader/Footer`	FO.NET: XML; IronPDF: API
Images	`<fo:external-graphic>`	`<img>` HTML tag	XSL-FO: element; IronPDF: standard tag
Hyperlinks	`<fo:basic-link>`	`<a href="">` HTML	FO.NET: FO object; IronPDF: HTML
Unicode support	Font-dependent	Built-in	FO.NET: manual; IronPDF: automatic

Comprehensive Feature Comparison

Feature	FO.NET	IronPDF
Status
Active Development	No (discontinued)	Yes
Last Update	2017-2018 (varies by fork)	Regular updates
Official Maintainer	None	Iron Software
Support
Community Forums	Dead GitHub repos	Active support
Commercial SLA	No	Available
Documentation	W3C spec + Apache FOP	Comprehensive
Code Samples	Sparse	Extensive
Content Creation
Layout System	XSL-FO (XML)	HTML/CSS
Modern CSS Support	No	Full CSS3
JavaScript Support	No	Yes
HTML Input	No	Yes
XML Input	Yes (via XSLT)	Via HTML conversion
PDF Operations
Generate PDF	Yes	Yes
Merge PDFs	No	Yes
Split PDFs	No	Yes
Extract Text	No	Yes
Edit Existing PDFs	No	Yes
Form Filling	Limited	Yes
Digital Signatures	No	Yes
Security
Encryption	Basic	AES 128/256-bit
Password Protection	Basic	User/Owner passwords
Permissions	Limited	Full control
Known Issues
.NET Core support	No	Yes
.NET 5+ support	No	Yes
Font embedding	Manual	Automatic
Large document performance	Poor	Optimized
Table auto-sizing	No	Yes
Unicode rendering	Limited	Full
Development
.NET Framework	4.0-4.6 (fork-dependent)	4.6.2+
.NET Core	No	3.1+
.NET 5+	No	Yes
Linux	Unknown	Yes
Docker	Problematic	Yes

Known FO.NET Issues

Based on historical reports and fork documentation gaps:

Memory leaks: Long-running processes may accumulate memory; no official fix
Threading issues: Not thread-safe; requires external synchronization
Image format limitations: Limited support beyond JPEG/PNG; TIFF/BMP problematic
Complex table crashes: Tables with merged cells or nested tables cause errors
SVG rendering: Minimal or no SVG support depending on fork

These issues vary by fork and may not be documented. Verify behavior through testing.

Installation Comparison

FO.NET

# No official NuGet package
# Manual DLL reference or fork-specific package
# Example for unofficial fork package:
# dotnet add package Fonet --version X.X.X

// Namespace varies by fork
// Commonly: using Fonet
// or: using FO.NET
// Verify in fork documentation

IronPDF

dotnet add package IronPdf

using IronPdf;

Conclusion

FO.NET served a specific need in the .NET ecosystem circa 2006-2012: teams with XML data pipelines who required precise, declarative page layout via XSL-FO standards. The library's dormancy reflects broader industry shifts—HTML/CSS emerged as the dominant layout language, XML processing moved to JSON/REST APIs, and .NET Framework-only libraries became incompatible with cloud-native architectures.

For existing FO.NET codebases, the migration decision hinges on pain points: if you're encountering .NET Core incompatibility, font rendering issues, or need features like digital signatures, the technical debt of maintaining FO.NET outweighs refactoring costs. IronPDF's HTML-based approach means most teams already possess the skills (HTML/CSS) to rebuild layouts, eliminating XSL-FO's learning curve.

Migration becomes mandatory when: deployment targets shift to .NET 5+; compliance requires modern encryption/signatures; or vendor-lock to unmaintained code becomes a security audit flag. In these cases, IronPDF's Chromium engine and active development provide a supported path forward.

Have you encountered XSL-FO codebases in legacy projects? What triggered the decision to migrate or maintain?

Learn IronPDF's HTML-to-PDF workflow: Complete HTML to PDF tutorial
Explore IronPDF's full API capabilities: C# PDF generation guide

Grabzit External HTML to PDF APIs: Privacy, GDPR, and Hidden Costs

IronSoftware — Mon, 06 Apr 2026 08:53:00 +0000

When developers integrate external services like GrabzIt or PDFmyURL for HTML-to-PDF conversion, they inherit risks that extend beyond technical implementation. Sending HTML content to third-party servers introduces data privacy concerns, GDPR compliance complexity, and operational dependencies that can create long-term problems. Understanding these risks before committing to an external API prevents costly migrations later.

The Problem

Cloud-based HTML-to-PDF services operate by receiving your HTML content, processing it on their infrastructure, and returning the generated PDF. This architecture creates several categories of risk that compound over time.

Data Transmission: Every conversion request sends your HTML content across the internet to a third-party server. For applications generating invoices, contracts, medical documents, or internal reports, this means sensitive data leaves your controlled environment on every request.

Processing Jurisdiction: GrabzIt, registered in England and Wales, explicitly states in their privacy policy that "depending on the physical location of you or the nominated receiving party, this automated action could mean that personal data is transmitted across international borders and beyond the United Kingdom and/or the European Union." This cross-border data flow complicates compliance with data residency requirements.

Data Retention: PDFmyURL states they retain server logs containing IP addresses and converted documents, which are "cleared out monthly." GrabzIt retains personal data until users have "stopped using GrabzIt's services for six months." Neither retention period may align with your organization's data minimization requirements.

Performance and Availability Impacts

Typical conversion request flow with external API:

Your Server → Internet → API Server → Processing → Internet → Your Server
                ↓                           ↓
           Network latency           API processing time
           (50-500ms each way)       (variable, up to 60 seconds)

Total added latency per conversion: 200-2000ms minimum

External API dependencies add network round-trip time to every conversion. When PDFmyURL documentation notes they "stop each conversion process after 60 seconds if your page is too large or loads too slow," that timeout happens on their infrastructure, outside your control.

Who Is Affected

Organizations in these categories face heightened risk when using external HTML-to-PDF APIs:

Healthcare and Financial Services: Applications handling protected health information (PHI) or financial data face regulatory requirements that may prohibit sending content to external processors. HIPAA requires Business Associate Agreements (BAAs) with any third party handling PHI. Not all cloud PDF services offer BAAs.

Legal and Government Entities: Document confidentiality requirements often mandate that data never leave approved infrastructure. Court documents, contracts, and government records may be subject to specific handling requirements.

Enterprise Applications Processing PII: GDPR's data processor requirements apply when sending European user data to any third party. The service becomes a data processor, requiring documented agreements, security assessments, and potentially Data Protection Impact Assessments (DPIAs).

High-Volume Production Systems: Applications generating thousands of PDFs per hour depend entirely on the external service's availability. Rate limiting, service outages, or API changes directly impact business operations.

Organizations with Data Residency Requirements: Some industries and regions mandate that data processing occur within specific geographic boundaries. Cross-border data transfers require additional legal mechanisms under GDPR.

Evidence of Industry Concerns

The challenges of external PDF API dependencies are documented across the developer community and security research.

Privacy and Data Processing

G2 reviews for PDFmyURL note the inherent privacy risk: "Files uploaded to servers inherently run the risk of being compromised." While reviewers haven't experienced breaches, the architectural risk remains.

GrabzIt's own documentation acknowledges international data transfer: their API "could mean that personal data is transmitted across international borders and beyond the United Kingdom and/or the European Union."

Security researchers have extensively documented risks in HTML-to-PDF converters. The Daily Swig reported that "five popular open source libraries used to convert HTML files to PDF documents are vulnerable to server-side request forgery (SSRF), directory traversal, and denial-of-service (DoS) attacks." While this research focused on libraries, cloud services using similar underlying technology inherit comparable risks.

Availability and Performance Issues

GrabzIt's support documentation addresses a common problem: "If all of your requests to GrabzIt's API never complete and then timeout, there could be a problem with your network. The most likely issue is a firewall or network configuration issue."

G2 reviews for PDFmyURL identify the "conversion time limit (60 seconds) for complex or slow-loading pages" as a main drawback, along with the service being "relatively expensive compared to competitors."

One GrabzIt user on G2 reported that "the tool was bugging out and wasn't able to capture any PDFs due to it crashing. The support team blamed it on poor code and gave no insight or help." Production applications cannot afford such debugging uncertainty when revenue-generating functions depend on PDF generation.

Vendor Lock-In Concerns

Research published in ResearchGate on SaaS migration notes that "the vendor lock-in problem is often caused by cloud computing SaaS provider's use of unique and proprietary user interfaces, application programming interfaces (APIs) and databases."

The practical impact: once your application integrates with a specific API's request format, authentication scheme, and response handling, migrating to an alternative requires code changes throughout your application.

Root Cause Analysis

The fundamental issues with external HTML-to-PDF APIs stem from architectural decisions that prioritize ease of initial integration over long-term operational control.

Data Must Leave Your Control

There is no way to use GrabzIt, PDFmyURL, or similar services without sending your HTML content to their servers. The service cannot render HTML to PDF without receiving the HTML. This is not a bug to be fixed but the fundamental nature of external API services.

For organizations with data handling requirements, this architecture creates an irreconcilable conflict: the service cannot function without data access, but data access may violate policy.

Network Dependency on Every Operation

External APIs add network latency to every conversion. Even with optimal network conditions:

Step	Latency
DNS resolution	1-50ms
TLS handshake	50-200ms
Request transmission	10-100ms
API processing	500-60000ms
Response transmission	50-500ms
Total minimum	611ms+

For batch processing scenarios generating hundreds or thousands of PDFs, this per-conversion overhead compounds significantly.

Ongoing Cost Structure

External APIs use subscription models with per-conversion or monthly fees. PDFmyURL pricing starts at $19/month, with additional fees for volume beyond 20,000 conversions (additional 10,000 conversions cost $60/month). GrabzIt offers monthly subscriptions with similar scaling costs.

Over multi-year application lifespans, subscription costs accumulate:

Annual Cost	3-Year Total	5-Year Total
$228/year ($19/mo)	$684	$1,140
$720/year ($60/mo)	$2,160	$3,600
$2,400/year ($200/mo)	$7,200	$12,000

These costs recur indefinitely. Failure to maintain subscription results in complete loss of PDF generation capability.

GDPR Compliance Complexity

When using an external HTML-to-PDF service, the service becomes a data processor under GDPR. This creates several obligations:

Data Processing Agreement: Article 28 requires a written contract with specific provisions regarding processing instructions, confidentiality, security measures, and audit rights.
International Transfer Mechanisms: For services processing data outside the EU (or transferring to non-adequate jurisdictions), Standard Contractual Clauses (SCCs) or other transfer mechanisms are required.
Records of Processing: Organizations must document the use of external processors, the categories of data processed, and the purposes of processing.
Data Subject Rights: If a user exercises their right to erasure, the organization must ensure the processor also deletes the data, which may conflict with the processor's retention policies.

Attempted Workarounds

Organizations have attempted various approaches to mitigate external API risks while continuing to use them.

Workaround 1: Minimizing Sensitive Data

Approach: Strip sensitive fields from HTML before sending to the external service, then merge data back into the PDF locally.

// Attempting to minimize sensitive data exposure
public byte[] GeneratePdfWithReducedExposure(CustomerData customer)
{
    // Replace sensitive values with placeholders
    var sanitizedHtml = htmlTemplate
        .Replace("{SSN}", "[REDACTED]")
        .Replace("{AccountNumber}", "[REDACTED]")
        .Replace("{PhoneNumber}", "[REDACTED]");

    // Send sanitized HTML to external service
    var pdfBytes = ExternalPdfService.Convert(sanitizedHtml);

    // Problem: How do you put the real values back?
    // The PDF is a rendered image - you cannot simply
    // search and replace text

    return pdfBytes; // Missing sensitive data
}

Limitations:

PDFs are rendered documents, not text files; merging data post-conversion is technically complex
Positioning replacement text requires precise coordinate calculation
Any data that affects layout must be present during conversion
Partial data in the PDF may still be useful to attackers
Approach adds significant complexity without eliminating the core risk

Workaround 2: Self-Hosted API Proxy

Approach: Run a local proxy that intercepts requests, potentially encrypting or transforming data before forwarding.

Limitations:

The external service still receives the HTML (encrypted or not)
Adding a proxy introduces another failure point
Does not address compliance requirements for data residency
Increases operational complexity without solving the fundamental architecture

Workaround 3: Contractual Protections

Approach: Rely on the service's terms of service and privacy policy to protect data.

Limitations:

Terms of service are typically drafted to protect the provider, not the customer
Privacy policies can be changed with notice
Breach notification timelines may not meet regulatory requirements
Limited recourse if data is mishandled

Workaround 4: Separate Environment for Sensitive Documents

Approach: Use external APIs only for non-sensitive documents; use a different solution for confidential content.

Limitations:

Requires maintaining two different PDF generation systems
Developers must correctly classify document sensitivity
Edge cases and misclassification create risk
Doubles maintenance and testing burden

A Different Approach: On-Premises Processing with IronPDF

For organizations where data privacy, compliance, or operational independence matter, processing HTML-to-PDF conversion locally eliminates the architectural constraints of external APIs.

Why On-Premises Processing Addresses These Concerns

Data Never Leaves Your Infrastructure: IronPDF processes HTML to PDF entirely within your application. The HTML content, rendered PDF, and all intermediate states remain within your controlled environment. There is no network transmission to external parties.

No Third-Party Data Processor: When conversion happens within your application, no external data processor exists. This eliminates GDPR data processing agreements, international transfer mechanisms, and third-party audit requirements for the PDF generation component.

No Network Dependency: Conversion speed depends on your server's resources, not internet latency. Typical conversion times for moderate HTML documents are 100-500ms, with no network round-trip overhead.

Predictable Cost Structure: IronPDF uses perpetual licensing, not subscriptions. After the initial purchase, the software continues functioning indefinitely without recurring fees. Organizations concerned about long-term costs can calculate total cost of ownership with certainty.

Code Example

using IronPdf;
using System;

public class OnPremisesPdfGenerator
{
    public byte[] GenerateConfidentialDocument(CustomerData customer)
    {
        // HTML never leaves your server
        var html = BuildInvoiceHtml(customer);

        var renderer = new ChromePdfRenderer();

        // Configure rendering - all processing happens locally
        renderer.RenderingOptions.MarginTop = 20;
        renderer.RenderingOptions.MarginBottom = 20;
        renderer.RenderingOptions.MarginLeft = 15;
        renderer.RenderingOptions.MarginRight = 15;

        // Set paper size
        renderer.RenderingOptions.PaperSize = IronPdf.Rendering.PdfPaperSize.A4;

        // Generate PDF - no network calls, no external data transmission
        using var pdf = renderer.RenderHtmlAsPdf(html);

        return pdf.BinaryData;
    }

    public void GenerateBatchReports(IEnumerable<ReportData> reports)
    {
        var renderer = new ChromePdfRenderer();
        renderer.RenderingOptions.EnableJavaScript = false;

        foreach (var report in reports)
        {
            // Each conversion is independent, no API rate limits
            var html = BuildReportHtml(report);

            using var pdf = renderer.RenderHtmlAsPdf(html);
            pdf.SaveAs($"/secure-storage/reports/{report.Id}.pdf");

            // No per-conversion charges, no external service calls
        }
    }

    private string BuildInvoiceHtml(CustomerData customer)
    {
        // Sensitive data stays in your application
        return $@"
        <!DOCTYPE html>
        <html>
        <head>
            <style>
                body {{ font-family: Arial, sans-serif; margin: 40px; }}
                .header {{ border-bottom: 2px solid #333; padding-bottom: 20px; }}
                .customer-info {{ margin: 20px 0; }}
                .confidential {{ color: #c00; font-weight: bold; }}
            </style>
        </head>
        <body>
            <div class='header'>
                <h1>Invoice #{customer.InvoiceNumber}</h1>
                <p class='confidential'>CONFIDENTIAL</p>
            </div>
            <div class='customer-info'>
                <p><strong>Customer:</strong> {customer.Name}</p>
                <p><strong>Account:</strong> {customer.AccountNumber}</p>
                <p><strong>Tax ID:</strong> {customer.TaxId}</p>
            </div>
            <!-- This sensitive HTML never leaves your server -->
        </body>
        </html>";
    }

    private string BuildReportHtml(ReportData report) =>
        $"<html><body><h1>{report.Title}</h1></body></html>";
}

public class CustomerData
{
    public string InvoiceNumber { get; set; }
    public string Name { get; set; }
    public string AccountNumber { get; set; }
    public string TaxId { get; set; }
}

public class ReportData
{
    public string Id { get; set; }
    public string Title { get; set; }
}

Key points about this implementation:

All HTML content, including sensitive fields, remains within your application
No network requests occur during PDF generation
Batch processing has no rate limits or per-conversion fees
Conversion timing is deterministic, based on document complexity and server resources
The same code runs in development, staging, and production without API key management

Processing Without Internet Access

using IronPdf;

public class AirGappedEnvironmentGenerator
{
    public void GenerateInSecureEnvironment()
    {
        // IronPDF works in air-gapped environments
        // No license validation calls required during conversion
        // No telemetry transmitted

        var renderer = new ChromePdfRenderer();

        // Configure for offline operation
        renderer.RenderingOptions.EnableJavaScript = false;

        // Process classified documents without network access
        var html = GetClassifiedDocumentHtml();

        using var pdf = renderer.RenderHtmlAsPdf(html);
        pdf.SaveAs("/secure/classified-output.pdf");
    }

    private string GetClassifiedDocumentHtml() =>
        "<html><body><h1>Classified Document</h1></body></html>";
}

API Reference

For implementation details on on-premises PDF generation:

ChromePdfRenderer - HTML-to-PDF conversion without external dependencies
RenderingOptions - Configuration options for PDF output
Security and Encryption - Applying PDF security features locally

Migration Considerations

Licensing

IronPDF is commercial software using perpetual licensing. The initial cost is higher than a single month of API subscription, but there are no recurring fees for continued use. Organizations should compare:

Subscription API: Lower initial cost, ongoing monthly fees, perpetual dependency
Perpetual License: Higher initial cost, no recurring fees, indefinite use

For applications with multi-year lifespans, the break-even calculation typically favors perpetual licensing within 12-24 months.

Code Migration Effort

Switching from an external API to IronPDF requires code changes:

Change Area	Effort
Remove API client libraries	Minimal
Add IronPDF NuGet package	Minimal
Replace HTTP calls with IronPDF API	Moderate
Update error handling	Moderate
Adjust for synchronous processing	Varies
Testing and validation	Moderate

The actual migration typically takes 1-3 days for straightforward implementations, longer for applications with complex API integrations or custom error handling.

What You Gain

Complete control over when and how conversions occur
No dependency on external service availability
Elimination of per-conversion network latency
Simplified compliance posture (no external data processor)
Predictable performance characteristics
Offline and air-gapped capability

What to Consider

Initial licensing cost versus subscription costs
Server resource requirements for local processing
Team familiarity with .NET ecosystem (IronPDF is a .NET library)
Deployment complexity in containerized environments

IronPDF provides Docker images and documentation for Linux deployment, but organizations unfamiliar with .NET deployment may need additional setup time.

Conclusion

External HTML-to-PDF APIs like GrabzIt and PDFmyURL introduce data privacy risks, GDPR compliance obligations, and operational dependencies that compound over time. Organizations processing sensitive documents should evaluate whether architectural convenience justifies sending confidential HTML to third-party servers. On-premises processing eliminates these concerns while providing predictable performance and cost structures.

Jacob Mellor has led Iron Software's technical development for over two decades, building tools that process documents without external dependencies.

References

GrabzIt Privacy Policy{:rel="nofollow"} - Official privacy documentation detailing data processing and international transfers
PDFmyURL Privacy Policy{:rel="nofollow"} - Service privacy terms and data retention policies
PDFmyURL Pricing{:rel="nofollow"} - Subscription cost structure
GrabzIt Pricing{:rel="nofollow"} - Premium package options and costs
GrabzIt API Timeout Support{:rel="nofollow"} - Documentation on network and timeout issues
PDFmyURL Usage Restrictions{:rel="nofollow"} - Conversion timeout limitations
GrabzIt Reviews - G2{:rel="nofollow"} - User reviews including performance and support experiences
PDFmyURL Reviews - G2{:rel="nofollow"} - User reviews on limitations and costs
HTML-to-PDF Converters Security Vulnerabilities - The Daily Swig{:rel="nofollow"} - Security research on PDF converter vulnerabilities
SaaS Vendor Lock-In Analysis - ResearchGate{:rel="nofollow"} - Academic research on migration challenges
DocRaptor Security Documentation{:rel="nofollow"} - Example of enterprise-grade API security measures for comparison
GDPR Legal Text{:rel="nofollow"} - Official GDPR regulation reference

For IronPDF documentation on private, on-premises PDF generation, visit ironpdf.com.

Understanding GdPicture.NET Pricing: Is the Document Imaging SDK Worth the Cost?

IronSoftware — Mon, 06 Apr 2026 07:51:00 +0000

When developers need HTML-to-PDF conversion in their .NET applications, they often encounter GdPicture.NET during their search for solutions. GdPicture positions itself as an enterprise-grade document imaging SDK with over 3,000 functionalities. However, this comprehensive approach comes with a significant price tag that may not align with the needs of developers who simply require PDF generation capabilities.

The Problem

GdPicture.NET is designed as an all-in-one document imaging toolkit. The SDK bundles PDF processing with OCR, barcode recognition, TWAIN scanning, DICOM medical imaging, and dozens of other features. For organizations needing PDF generation from HTML or basic document manipulation, this bundled approach presents several challenges:

Forced feature bundling: PDF capabilities are packaged with imaging features you may never use
Enterprise-focused pricing: License costs designed for large document processing operations
Annual maintenance requirements: 20% of license cost annually for updates and support
Per-developer licensing: Each developer who compiles code using the SDK needs a separate license

Pricing Structure Overview

GdPicture.NET uses a modular licensing model with five core editions:

Edition	Target Use Case	Approximate Cost Range
Ultimate SDK	Full document imaging suite	$3,000+ per developer
Document Imaging SDK	PDF, imaging, annotations	$1,200+ per developer
Image SDK	Image processing only	$500+ per developer
TWAIN SDK	Scanner integration	$350+ per developer
Document Viewer SDK	PDF viewing	$950+ per developer

Additionally, individual plugins can be purchased separately:

PDF Plugin: ~$700
OCR Plugin: ~$700
Annotation Plugin: ~$700
Barcode plugins: ~$500 each

These figures are based on historical pricing and the company's stated "contact sales for pricing" model. Actual costs may vary based on negotiation and volume.

Who Is Affected

The GdPicture pricing structure most significantly impacts:

Small to mid-sized development teams: A team of three developers working on a web application that generates PDF invoices would need three separate licenses. At $1,200+ per developer for the Document Imaging SDK, the initial investment exceeds $3,600 before annual maintenance.

Startups and indie developers: The entry cost for basic PDF functionality requires significant upfront capital that may not fit early-stage budgets.

Projects with focused requirements: Applications that only need HTML-to-PDF conversion or basic PDF manipulation end up paying for OCR, barcode, and imaging capabilities they will never use.

Organizations with strict procurement policies: The "contact sales for pricing" approach requires procurement negotiations rather than transparent self-service licensing.

The SDK Bundle vs. PDF-Only Needs

GdPicture markets itself as a "Five-in-One Toolkit" that delivers "an all-in-one SDK without extra costs or complex licensing." However, this bundled approach means developers cannot purchase only the PDF features they need at a reduced price.

What GdPicture.NET Includes

The Ultimate SDK bundles together:

PDF creation, editing, and rendering
OCR (Optical Character Recognition)
1D and 2D barcode reading/writing
Image processing (500+ functions)
TWAIN scanner integration
DICOM medical image support
JBIG2 compression
Document annotation
Form field processing

What Many Developers Actually Need

For typical web application PDF generation:

HTML-to-PDF conversion
PDF merging and splitting
Adding headers, footers, and page numbers
Digital signatures
Basic PDF editing

The mismatch between GdPicture's comprehensive offering and these focused requirements results in paying for functionality that remains unused.

Cost Analysis for Typical PDF Use Cases

Scenario 1: E-commerce Invoice Generation

A small e-commerce platform needs to generate PDF invoices from HTML templates.

With GdPicture.NET:

Minimum viable option: Document Imaging SDK
Cost per developer: ~$1,200
Team of 2 developers: ~$2,400
Annual maintenance (20%): ~$480/year
First-year cost: ~$2,880

Features used: PDF generation from HTML
Features paid for but unused: OCR, barcode recognition, image processing, TWAIN scanning, annotations

Scenario 2: Report Generation System

A business application generates weekly reports as PDFs.

With GdPicture.NET:

Required: Document Imaging SDK + PDF Plugin
Team of 3 developers: ~$3,600+
Annual maintenance: ~$720/year
First-year cost: ~$4,320

Features used: PDF creation, basic styling
Features unused: OCR, barcode, medical imaging, scanner integration

Scenario 3: Document Management Platform

A larger system needs PDF viewing, annotation, and conversion.

With GdPicture.NET:

Required: Ultimate SDK for full functionality
Team of 5 developers: ~$15,000+
Annual maintenance: ~$3,000/year
First-year cost: ~$18,000

This scenario better utilizes GdPicture's capabilities, but many organizations do not require the full imaging suite.

The Annual Maintenance Consideration

GdPicture.NET requires an Annual Maintenance Contract (AMC) for continued access to updates and support:

Initial cost: 20% of the Suggested Retail Price (SRP)
Renewal cost: 20% annually
Without AMC: No access to new versions or technical support

For a team using the Ultimate SDK ($15,000 initial investment), annual maintenance adds $3,000 per year indefinitely. Over a five-year period, maintenance costs alone total $15,000, effectively doubling the total cost of ownership.

A Focused Alternative: IronPDF

For developers whose primary need is PDF generation rather than comprehensive document imaging, IronPDF offers a more targeted solution.

Why Consider IronPDF for PDF-Focused Projects

IronPDF is built specifically for PDF operations in .NET applications. Rather than bundling PDF capabilities into a larger imaging SDK, IronPDF focuses on common PDF tasks:

HTML-to-PDF rendering using an embedded Chromium engine
PDF creation, editing, and manipulation
Digital signatures and security
Form filling and extraction
PDF merging, splitting, and conversion

Pricing Comparison

Feature	GdPicture.NET	IronPDF
Entry-level license	~$950+ (Viewer only)	$749 (Lite)
PDF creation capability	~$1,200+ (Doc Imaging SDK)	$749 (Lite)
Small team (3 devs)	~$3,600+	$1,499 (Plus)
Unlimited developers	Contact sales	$2,999 (Professional)
Annual maintenance	20% required	Optional (included first year)
SaaS deployment	Additional licensing	Available in license tiers

IronPDF's pricing structure is transparent and publicly available, allowing developers to calculate costs without contacting a sales team.

Code Example: HTML to PDF

using IronPdf;

public class InvoiceGenerator
{
    public void GenerateInvoice(string htmlContent, string outputPath)
    {
        // Configure the renderer with Chrome-based rendering
        var renderer = new ChromePdfRenderer();

        // Set rendering options for invoice formatting
        renderer.RenderingOptions.MarginTop = 20;
        renderer.RenderingOptions.MarginBottom = 20;
        renderer.RenderingOptions.MarginLeft = 15;
        renderer.RenderingOptions.MarginRight = 15;

        // Enable CSS media type for print-optimized styling
        renderer.RenderingOptions.CssMediaType = IronPdf.Rendering.PdfCssMediaType.Print;

        // Render HTML to PDF
        var pdf = renderer.RenderHtmlAsPdf(htmlContent);

        // Save the generated invoice
        pdf.SaveAs(outputPath);
    }
}

This code generates a PDF from HTML content using IronPDF's Chromium-based renderer. The approach handles CSS, JavaScript, and modern web features without requiring additional plugins or configuration.

API Reference

For more details on the methods used:

Feature Comparison for PDF Tasks

PDF Capability	GdPicture.NET	IronPDF
HTML to PDF	Yes (via plugin)	Yes (built-in Chrome engine)
CSS3 support	Limited	Full Chromium support
JavaScript execution	Limited	Full Chromium support
PDF/A compliance	Yes	Yes
Digital signatures	Yes	Yes
PDF editing	Yes	Yes
Form filling	Yes	Yes
Merge/Split	Yes	Yes
Watermarks	Yes	Yes
Headers/Footers	Yes	Yes
Docker/Linux	Yes	Yes
.NET Core/.NET 5+	Yes	Yes

For HTML-to-PDF specifically, IronPDF's embedded Chromium engine provides accurate rendering of modern web pages, including complex CSS layouts and JavaScript-generated content.

Migration Considerations

When GdPicture.NET Makes Sense

GdPicture.NET remains a valid choice when:

Your application requires OCR, barcode processing, and PDF in the same workflow
You need TWAIN scanner integration for document capture
Medical imaging (DICOM) is part of your requirements
You have existing GdPicture integration and migration cost exceeds licensing cost

When IronPDF Is More Appropriate

IronPDF better fits projects that:

Focus primarily on PDF generation from HTML/CSS
Need accurate rendering of modern web content
Have small to medium development teams
Prefer transparent, self-service licensing
Want to avoid paying for unused features

Licensing Model Differences

GdPicture.NET:

Per-developer licensing (each developer compiling code needs a license)
Mandatory annual maintenance for updates
Contact sales for pricing
Enterprise-focused negotiation

IronPDF:

Tiered licensing (Lite: 1 dev, Plus: 3 devs, Professional: unlimited)
First year support included
Optional renewal for continued updates
Transparent public pricing

Total Cost of Ownership: 3-Year Comparison

For a team of 3 developers building a PDF invoice system:

GdPicture.NET Document Imaging SDK:

Initial license: ~$3,600
Year 1 maintenance: ~$720
Year 2 maintenance: ~$720
Year 3 maintenance: ~$720
3-year total: ~$5,760

IronPDF Plus License:

Initial license: $1,499
Year 1 support: Included
Year 2 support (optional): ~$450
Year 3 support (optional): ~$450
3-year total: ~$2,399 (or $1,499 if support not renewed)

The difference represents significant budget that could be allocated to other development resources.

Conclusion

GdPicture.NET is a comprehensive document imaging SDK that serves organizations needing its full range of capabilities. However, for developers whose requirements center on PDF generation, particularly HTML-to-PDF conversion, the bundled pricing structure results in paying for features that remain unused.

IronPDF provides a focused alternative with transparent pricing, modern HTML rendering via Chromium, and licensing designed for teams of varying sizes. Before committing to either solution, evaluate your actual PDF requirements against the features included in each offering.

Jacob Mellor is CTO at Iron Software and originally built IronPDF.

References

GdPicture.NET SDK Pricing{:rel="nofollow"} - Official pricing page
GdPicture Product Price Lists{:rel="nofollow"} - Complete product pricing in USD
GdPicture Annual Maintenance Contract{:rel="nofollow"} - AMC terms and pricing structure
GdPicture Sales FAQ{:rel="nofollow"} - Licensing model details
GdPicture.NET Editions Comparison{:rel="nofollow"} - Feature comparison across editions
GdPicture Licensing Model{:rel="nofollow"} - Per-developer licensing explanation

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

Rotativa Not Working in .NET Core: Modern Alternative (Issue Fixed)

IronSoftware — Fri, 03 Apr 2026 16:07:00 +0000

Rotativa has been a popular choice for converting ASP.NET MVC views to PDF documents. Developers appreciate its simple API patterns like ViewAsPdf and ActionAsPdf that integrate naturally with MVC controller actions. However, migrating to .NET Core reveals significant compatibility issues that stem from Rotativa's architecture: it wraps wkhtmltopdf, a command-line tool that has been archived and is no longer maintained.

This article documents the common errors developers encounter when using Rotativa.AspNetCore, explains why these issues persist, and demonstrates how to achieve the same MVC-to-PDF functionality with IronPDF.

The Problem

Rotativa.AspNetCore exists as a port of the original Rotativa library for .NET Core, but it inherits fundamental limitations from its dependency on wkhtmltopdf. Developers encounter a range of errors depending on their deployment environment.

How Rotativa Works

Rotativa acts as a wrapper around wkhtmltopdf, spawning the external executable to render HTML content as PDF. This architecture requires:

The wkhtmltopdf binary to be present in a specific location
The application process to have permission to execute external binaries
Platform-specific binaries (Windows .exe vs Linux/Mac executables)
All native dependencies that wkhtmltopdf requires

When any of these requirements fail, Rotativa produces errors that can be difficult to diagnose.

The wkhtmltopdf Dependency Problem

The wkhtmltopdf project was archived on January 2, 2023. The repository is now read-only with no further development planned. This matters because:

No bug fixes or security patches will be released
The rendering engine uses Qt WebKit, which hasn't been updated since 2012
Modern HTML5, CSS3, and JavaScript features are not supported
Known security vulnerabilities remain unpatched

Error Messages and Symptoms

Developers migrating to .NET Core commonly encounter these errors:

Binary Not Found

System.ComponentModel.Win32Exception: The system cannot find the file specified
   at System.Diagnostics.Process.StartWithShellExecuteEx(ProcessStartInfo startInfo)
   at Rotativa.AspNetCore.WkhtmlDriver.Convert(...)

This occurs because the NuGet package does not automatically deploy the wkhtmltopdf executable. Developers must manually copy the binary to the correct location.

Permission Denied on Linux

System.ComponentModel.Win32Exception (13): Permission denied
   at Interop.Sys.ForkAndExecProcess(...)
   at System.Diagnostics.Process.StartCore(ProcessStartInfo startInfo)
   at Rotativa.AspNetCore.WkhtmlDriver.Convert(...)

Linux deployments fail when the wkhtmltopdf binary lacks execute permissions or when the application process cannot spawn external executables.

Broken Pipe on Linux

System.IO.IOException: Broken pipe
   at System.IO.Pipes.PipeStream.WriteCore(ReadOnlySpan`1 buffer)
   at Rotativa.AspNetCore.WkhtmlDriver.Convert(...)

This error indicates communication failure between the .NET application and the wkhtmltopdf process, often due to missing native dependencies.

ArgumentNullException with ActionAsPdf

System.ArgumentNullException: Value cannot be null. (Parameter 'key')
   at Rotativa.AspNetCore.ActionAsPdf.CallTheDriver(...)

The ActionAsPdf pattern can fail in .NET Core with null reference errors even when the same code works with ViewAsPdf.

Authentication Loss with ActionAsPdf

When using ActionAsPdf with authenticated controllers, Rotativa often renders the login page instead of the intended view. The wkhtmltopdf process makes a separate HTTP request that does not carry the user's authentication cookies.

Who Is Affected

Deployment Environments

Linux servers and containers: Most cloud deployments use Linux, where Rotativa requires manual binary installation and permission configuration
Docker containers: The .NET Core containers from Microsoft do not include wkhtmltopdf or its dependencies
Azure App Service on Linux: No built-in wkhtmltopdf support
Windows servers without Visual C++ Redistributable: Requires msvcp120.dll to be manually deployed

Use Cases

ASP.NET Core applications migrated from .NET Framework
Projects using ViewAsPdf or ActionAsPdf patterns for invoice generation, report exports, or document creation
Continuous integration pipelines that build and test on Linux
Containerized microservices requiring PDF generation

Evidence from the Developer Community

The Rotativa.AspNetCore GitHub repository documents persistent issues across multiple years.

Timeline

Date	Event	Source
2018	Permission denied on Ubuntu reported	GitHub Issue #197{:rel="nofollow"}
2019	Unable to run under Linux	GitHub Issue #13{:rel="nofollow"}
2020	Docker deployment questions	GitHub Issue #7{:rel="nofollow"}
2021	.NET Core 3.1 setup issues	GitHub Issue #79{:rel="nofollow"}
2023-01-02	wkhtmltopdf repository archived	GitHub{:rel="nofollow"}

Community Reports

"Rotativa worked perfectly on Windows with .NET Core web API (2.1) and was able to generate PDFs from cshtml files, but when deploying the same project to Ubuntu, it gives permission denied exceptions."
— Developer, GitHub Issues, 2018

The pattern repeats across multiple issues: functionality that works on Windows development machines fails when deployed to Linux production environments.

"Using ViewAsPdf now passing model to send some data and it's working but using ActionAsPdf getting an error: ArgumentNullException: Value cannot be null."
— Developer, Microsoft Forums, 2017

The ActionAsPdf pattern, which was a key feature of Rotativa's MVC integration, exhibits inconsistent behavior in .NET Core that developers must work around by switching to ViewAsPdf.

Root Cause Analysis

Architectural Dependency

Rotativa's architecture creates a process dependency chain:

ASP.NET Core App → Rotativa.AspNetCore → wkhtmltopdf binary → Qt WebKit → libgdiplus (Linux)

Each link in this chain introduces potential failure points. The NuGet package installs only the .NET wrapper; the external binary and its native dependencies must be managed separately.

wkhtmltopdf's Obsolete Rendering Engine

wkhtmltopdf uses a patched version of Qt WebKit that stopped receiving updates in 2012. The Qt project deprecated QtWebKit in 2015 and removed it from Qt 5.6 in 2016. The wkhtmltopdf maintainers considered migrating to QtWebEngine (which uses Chromium) but concluded it was not feasible because certain APIs required by wkhtmltopdf do not exist in the newer engine.

As a result, wkhtmltopdf cannot render:

CSS Flexbox or Grid layouts
Modern JavaScript ES6+ features
Web fonts that require JavaScript loading
Many HTML5 elements and attributes

Security Vulnerabilities

CVE-2022-35583 documents a critical (CVSS 9.8) Server-Side Request Forgery vulnerability in wkhtmltopdf 0.12.6. Because the project is archived, this vulnerability will not be patched. The wkhtmltopdf maintainers stated this is an application-level concern, but the practical effect is that any application using wkhtmltopdf must implement its own input sanitization to prevent SSRF attacks.

The archived status means:

No security patches for future CVEs
No fixes for rendering bugs
No updates for newer operating systems
No support for modern web standards

Attempted Workarounds

Workaround 1: Manual Binary Deployment

Approach: Copy wkhtmltopdf executables to the project folder and set "Copy Always" in file properties.

Project/
├── Rotativa/
│   ├── Windows/
│   │   └── wkhtmltopdf.exe
│   └── Linux/
│       └── wkhtmltopdf
└── Program.cs

// In Program.cs or Startup.cs
RotativaConfiguration.Setup(env.WebRootPath, "Rotativa");

Limitations:

Increases deployment package size significantly
Requires maintaining platform-specific binaries
Linux binaries need execute permissions set post-deployment
Does not solve the underlying technology obsolescence

Workaround 2: Docker Layer Installation

Approach: Install wkhtmltopdf in the Docker image during build.

FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS base
RUN apt-get update && apt-get install -y \
    wkhtmltopdf \
    libgdiplus \
    libc6-dev \
    && rm -rf /var/lib/apt/lists/*

Limitations:

Adds container build time and image size
Version of wkhtmltopdf from package managers may differ from expected
Still using archived, vulnerable software
libgdiplus introduces its own compatibility issues

Workaround 3: Replace ActionAsPdf with ViewAsPdf

Approach: Avoid the ActionAsPdf pattern that makes separate HTTP requests.

// Instead of:
public IActionResult DownloadPdf()
{
    return new ActionAsPdf("Invoice", new { id = 123 });
}

// Use:
public IActionResult DownloadPdf()
{
    var model = GetInvoiceModel(123);
    return new ViewAsPdf("Invoice", model);
}

Limitations:

Requires refactoring existing code
Loses the ability to generate PDFs from actions with complex setup logic
Does not solve permission or binary issues
Still relies on wkhtmltopdf

A Different Approach: IronPDF

IronPDF provides PDF generation capabilities for ASP.NET Core without external binary dependencies. Instead of wrapping a command-line tool, IronPDF embeds a Chromium rendering engine directly in the .NET process.

Why IronPDF Avoids These Issues

The architectural difference eliminates the root causes of Rotativa's problems:

No external binary: The rendering engine is packaged as .NET assemblies
No spawn/exec permissions needed: Everything runs in-process
Cross-platform by design: Same code works on Windows, Linux, and macOS
Modern rendering: Uses Chromium, supporting current HTML5, CSS3, and JavaScript
Actively maintained: Regular updates with security patches and new features

Code Example: Replacing ViewAsPdf

The following example shows how to achieve the same result as Rotativa's ViewAsPdf pattern:

using IronPdf;
using Microsoft.AspNetCore.Mvc;

public class InvoiceController : Controller
{
    // Rotativa pattern - requires external wkhtmltopdf binary
    // public IActionResult DownloadPdfRotativa()
    // {
    //     var model = GetInvoiceModel();
    //     return new ViewAsPdf("Invoice", model);
    // }

    // IronPDF pattern - no external dependencies
    public IActionResult DownloadPdf()
    {
        // Create the renderer with Chromium engine
        var renderer = new ChromePdfRenderer();

        // Configure page settings similar to Rotativa options
        renderer.RenderingOptions.MarginTop = 25;
        renderer.RenderingOptions.MarginBottom = 25;
        renderer.RenderingOptions.PaperSize = IronPdf.Rendering.PdfPaperSize.A4;

        // Get the invoice model
        var model = GetInvoiceModel();

        // Render HTML content to PDF
        // This HTML would typically come from rendering a Razor view
        string htmlContent = GenerateInvoiceHtml(model);
        var pdf = renderer.RenderHtmlAsPdf(htmlContent);

        // Return as file result - displays in browser
        return File(pdf.BinaryData, "application/pdf");
    }

    // Or to force download with filename:
    public IActionResult DownloadPdfAsFile()
    {
        var renderer = new ChromePdfRenderer();
        var model = GetInvoiceModel();
        string htmlContent = GenerateInvoiceHtml(model);
        var pdf = renderer.RenderHtmlAsPdf(htmlContent);

        // Third parameter triggers download instead of inline display
        return File(pdf.BinaryData, "application/pdf", "invoice.pdf");
    }

    private InvoiceModel GetInvoiceModel()
    {
        // Your existing model retrieval logic
        return new InvoiceModel { /* ... */ };
    }

    private string GenerateInvoiceHtml(InvoiceModel model)
    {
        // Generate HTML from your template
        // This could use Razor rendering or string interpolation
        return $@"
        <!DOCTYPE html>
        <html>
        <head>
            <style>
                body {{ font-family: Arial, sans-serif; }}
                .invoice-header {{ background: #2c3e50; color: white; padding: 20px; }}
                table {{ width: 100%; border-collapse: collapse; margin-top: 20px; }}
                th, td {{ border: 1px solid #ddd; padding: 12px; text-align: left; }}
                th {{ background-color: #3498db; color: white; }}
            </style>
        </head>
        <body>
            <div class='invoice-header'>
                <h1>Invoice #{model.InvoiceNumber}</h1>
            </div>
            <table>
                <tr><th>Item</th><th>Quantity</th><th>Price</th></tr>
                <!-- Invoice items would be rendered here -->
            </table>
        </body>
        </html>";
    }
}

Key points about this approach:

No wkhtmltopdf binary required
No platform-specific file deployment
Works identically on Windows, Linux, and macOS
Full CSS support including Flexbox and Grid
JavaScript executes as in a real browser

Rendering Razor Views to PDF

For projects heavily using Razor views, IronPDF provides an extension package that renders views directly:

using IronPdf;
using IronPdf.Extensions.Mvc.Core;
using Microsoft.AspNetCore.Mvc;
using Microsoft.AspNetCore.Mvc.ViewEngines;

public class ReportController : Controller
{
    private readonly ICompositeViewEngine _viewEngine;
    private readonly ITempDataProvider _tempDataProvider;

    public ReportController(
        ICompositeViewEngine viewEngine,
        ITempDataProvider tempDataProvider)
    {
        _viewEngine = viewEngine;
        _tempDataProvider = tempDataProvider;
    }

    public async Task<IActionResult> GenerateReport(int reportId)
    {
        var model = await GetReportData(reportId);

        // Render the Razor view to HTML string
        var htmlContent = await RenderViewToStringAsync("Report", model);

        // Convert to PDF
        var renderer = new ChromePdfRenderer();
        renderer.RenderingOptions.EnableJavaScript = true;
        renderer.RenderingOptions.WaitFor.RenderDelay(100);

        var pdf = renderer.RenderHtmlAsPdf(htmlContent);

        return File(pdf.BinaryData, "application/pdf", $"report-{reportId}.pdf");
    }

    private async Task<string> RenderViewToStringAsync(string viewName, object model)
    {
        ViewData.Model = model;

        using var writer = new StringWriter();
        var viewResult = _viewEngine.FindView(ControllerContext, viewName, false);

        var viewContext = new ViewContext(
            ControllerContext,
            viewResult.View,
            ViewData,
            TempData,
            writer,
            new HtmlHelperOptions()
        );

        await viewResult.View.RenderAsync(viewContext);
        return writer.GetStringBuilder().ToString();
    }
}

Equivalent to ActionAsPdf

IronPDF can also render URLs, providing functionality similar to Rotativa's ActionAsPdf:

public IActionResult GenerateFromUrl()
{
    var renderer = new ChromePdfRenderer();

    // Enable JavaScript for dynamic content
    renderer.RenderingOptions.EnableJavaScript = true;
    renderer.RenderingOptions.WaitFor.RenderDelay(500);

    // Render from URL - similar to ActionAsPdf
    // Note: For local development, ensure the URL is accessible
    var pdf = renderer.RenderUrlAsPdf("https://localhost:5001/Report/View/123");

    return File(pdf.BinaryData, "application/pdf");
}

API Reference

For detailed documentation on the methods demonstrated:

Migration Considerations

NuGet Package Changes

Remove Rotativa packages and add IronPDF:

<!-- Remove -->
<PackageReference Include="Rotativa.AspNetCore" Version="*" />

<!-- Add -->
<PackageReference Include="IronPdf" Version="*" />
<!-- Optional: For Razor view rendering -->
<PackageReference Include="IronPdf.Extensions.Mvc.Core" Version="*" />

Configuration Changes

Remove Rotativa setup code:

// Remove from Program.cs or Startup.cs:
// RotativaConfiguration.Setup(env.WebRootPath, "Rotativa");

// IronPDF requires no global setup
// Optionally configure license key:
IronPdf.License.LicenseKey = "your-license-key";

Licensing

IronPDF is commercial software with per-developer licensing. A free trial is available for evaluation. For projects currently using Rotativa (which is MIT licensed), the licensing model represents a change, but must be weighed against:

Time saved debugging deployment issues
Security of actively maintained software
Support for modern web standards
Cross-platform reliability

API Pattern Mapping

Rotativa Pattern	IronPDF Equivalent
`ViewAsPdf("ViewName", model)`	Render HTML string with `RenderHtmlAsPdf`
`ActionAsPdf("ActionName")`	Use `RenderUrlAsPdf` or render view to string
`CustomSwitches`	`RenderingOptions` properties
`PageSize.A4`	`PdfPaperSize.A4`
`PageMargins`	Individual margin properties

What You Gain

Elimination of wkhtmltopdf binary deployment
No platform-specific configuration
Modern CSS support (Flexbox, Grid, CSS variables)
JavaScript execution with configurable wait times
Active security updates
Technical support

What to Consider

Commercial licensing required for production use
Different API patterns require code changes
Larger assembly size than Rotativa wrapper (Chromium engine is included)

Conclusion

Rotativa's architecture as a wrapper around wkhtmltopdf creates deployment challenges in .NET Core that stem from external binary dependencies and an archived rendering engine. The common errors (binary not found, permission denied, authentication loss) all trace back to this design. With wkhtmltopdf archived and unpatched against known security vulnerabilities, continuing to use Rotativa introduces both technical debt and security risk.

IronPDF provides equivalent functionality through an embedded Chromium engine that requires no external binaries, works consistently across platforms, and supports modern web standards. For projects experiencing Rotativa issues in .NET Core deployments, migration eliminates the root causes rather than adding workarounds.

Written by Jacob Mellor, CTO at Iron Software. He leads technical development at Iron Software and originally built IronPDF.

References

Rotativa.AspNetCore GitHub Repository{:rel="nofollow"} - Official .NET Core port
Permission Denied on Ubuntu - Issue #197{:rel="nofollow"} - Linux deployment error
Unable to Run Under Linux - Issue #13{:rel="nofollow"} - Cross-platform issues
Docker Deployment - Issue #7{:rel="nofollow"} - Container configuration
.NET Core 3.1 Setup - Issue #79{:rel="nofollow"} - Configuration changes
wkhtmltopdf Status Page{:rel="nofollow"} - Official archive announcement
CVE-2022-35583 - NVD{:rel="nofollow"} - SSRF vulnerability details
wkhtmltopdf SSRF Issue #5249{:rel="nofollow"} - Security vulnerability discussion
Qt WebKit Deprecation - Issue #3391{:rel="nofollow"} - Why migration to QtWebEngine was not possible
ActionAsPdf Authentication Issue #120{:rel="nofollow"} - Login page rendering problem

For comprehensive IronPDF documentation including tutorials, API reference, and code examples, visit ironpdf.com.

Spire.PDF HTML Conversion Renders Text as Rasterized Image (Fixed)

IronSoftware — Fri, 03 Apr 2026 13:06:00 +0000

Developers using Spire.PDF for .NET to convert HTML to PDF frequently discover that the resulting documents contain no actual text layer. Instead of selectable, searchable text, the PDF contains rasterized bitmap images of text. This creates immediate problems: users cannot select or copy text, search functionality fails completely, screen readers cannot interpret the content, and file sizes balloon to 10-50 times larger than vector-based PDFs. The issue stems from Spire.PDF's reliance on Internet Explorer's rendering engine, which screenshots web content rather than constructing a proper PDF text layer.

The Problem

Spire.PDF's LoadFromHTML method does not actually parse HTML and render it as PDF text. Instead, it captures a screenshot of the HTML content as rendered by Internet Explorer and embeds that screenshot as an image within the PDF. The result is a PDF that looks correct visually but is fundamentally broken for any use case requiring actual text.

When developers open a PDF generated by LoadFromHTML, they discover that clicking and dragging to select text does nothing. The cursor does not change to a text selection cursor because there is no text to select. What appears to be text is actually a bitmap image of text rendered at whatever DPI Internet Explorer used during the capture.

This architectural decision has cascading consequences. PDF search functionality, which relies on an embedded text layer, returns no results regardless of what text appears visually in the document. Screen readers used by visually impaired users cannot interpret the document because the accessibility APIs find no text content. Copy and paste operations fail entirely. And because images require significantly more storage than vector text, file sizes increase dramatically.

The root cause is dependency on the Internet Explorer rendering engine. When IE version 9 or later is installed on the system (which is the case for all modern Windows installations), Spire.PDF renders HTML as an image rather than as text.

Error Messages and Symptoms

Developers typically do not receive error messages because the conversion technically succeeds. The symptoms manifest when using the resulting PDF:

// When attempting to extract text programmatically:
PdfTextExtractor extractor = new PdfTextExtractor(page);
string text = extractor.ExtractAllText();
// Returns empty string or null - no text layer exists

// Text selection in PDF viewer:
// Cursor remains as pointer, not text selection cursor
// Ctrl+A selects nothing
// Ctrl+F finds nothing

Symptoms include:

Text cursor never appears when hovering over "text" in the PDF
Ctrl+F search finds zero results for words clearly visible on the page
Copy operation copies nothing or copies garbled characters
Screen readers report the document as empty or containing only images
File size of 500KB HTML becomes 5-50MB PDF
PDF appears grainy or blurry when zoomed, revealing pixel artifacts
Hyperlinks in the original HTML do not work in the PDF
Text appears fuzzy compared to vector-rendered PDFs

Who Is Affected

This issue impacts any deployment using Spire.PDF's HTML-to-PDF functionality on systems with Internet Explorer 9 or later:

Operating Systems: All Windows versions since Windows 7, which ship with IE9+. Windows 10 and 11 include Edge but retain IE components that Spire.PDF uses for rendering. The issue affects 100% of modern Windows deployments.

Framework Versions: .NET Framework 4.x, .NET Core 3.1, .NET 5, .NET 6, .NET 7, and .NET 8. The IE rendering dependency exists across all supported .NET versions when using the LoadFromHTML method.

Use Cases: Invoice generation systems, report builders, document archival workflows, web page preservation tools, email-to-PDF converters, and any application that needs searchable PDFs from HTML content.

Accessibility Requirements: Any organization subject to accessibility compliance (ADA in the US, AODA in Canada, EN 301 549 in the EU) faces legal exposure because the generated PDFs are completely inaccessible to assistive technology.

Evidence from the Developer Community

The text rasterization issue has been reported consistently on the E-iceblue forums for years, with users expressing frustration at the fundamental limitation.

Timeline

Date	Event	Source
2017	Initial reports of text rendered as images	E-iceblue Forums
2018	Forum thread: "LoadFromHTML as text instead of image?"	E-iceblue Forums
2019	Multiple threads about links not working, text not selectable	E-iceblue Forums
2020	Qt plugin introduced as workaround, links still not supported	E-iceblue Forums
2021	"Grainy HTML to PDF" quality issues reported	E-iceblue Forums
2022	Linux Qt plugin issues documented	E-iceblue Forums
2023	Issue persists, workarounds remain incomplete	E-iceblue Forums
2024	Community still seeking solutions	E-iceblue Forums

Community Reports

"doc.LoadFromHTML(url, false, true, true); This seems to only take screenshots of the webpage and save as an image in the pdf. I am looking to save the html page as text so it can be selectable in the pdf."
— Developer, E-iceblue Forums

"It seems that spire.pdf only makes a screenshot of the html file because in the final pdf you cannot mark text or follow links."
— Developer, E-iceblue Forums

"The quality of the PDF is, quite frankly, awful. The text is blurred and of very poor quality, unlike the original."
— Developer, E-iceblue Forums, discussing LoadFromHTML output

"Spire generates a PDF file that is just an image. Some of the css is not even correct, such as ignoring bold fonts."
— Developer, E-iceblue Forums

The official E-iceblue response confirms the architectural limitation: "The method 'LoadFromHTML' would render the pdf depending on the IE engine installed on your system, if it is IE9 or above, it would be rendered as an image while version 8 or below as text."

Root Cause Analysis

The text rasterization issue exists because Spire.PDF delegates HTML rendering to Internet Explorer's MSHTML engine rather than implementing proper HTML parsing and PDF text rendering. This design decision made development simpler but created a fundamental limitation in the output.

When LoadFromHTML executes, Spire.PDF:

Loads the HTML content into an embedded IE WebBrowser control
Waits for IE to render the page
Captures a bitmap screenshot of the rendered content
Embeds that bitmap as an image in the PDF
Returns a PDF that visually represents the HTML but contains no text layer

Internet Explorer versions 9 and later changed how content is captured, resulting in image-based output. On systems with IE8 or earlier (essentially non-existent in production today), text was captured differently and remained selectable. This created a situation where the feature worked during initial development on older Windows versions but broke on all modern systems.

The consequences of this architecture:

No text layer: PDF/A compliance is impossible without a text layer
No hyperlinks: Since the PDF contains an image, anchor tags become static pixels
Quality loss: Bitmap text at screen DPI becomes fuzzy when zoomed
File bloat: A page of text as vectors might be 50KB; as a 300DPI image, it becomes 2-5MB
No accessibility: Screen readers require a text layer to function

This is a design-level limitation, not a bug to be fixed. Spire.PDF would need to replace its entire HTML rendering pipeline to generate actual PDF text content from HTML.

Attempted Workarounds

The Spire.PDF community and E-iceblue support have suggested several workarounds, each with significant limitations.

Workaround 1: Qt Plugin Converter

Approach: Use the separate Qt-based HTML converter plugin instead of LoadFromHTML.

using Spire.Pdf.HtmlConverter.Qt;

// Set the plugin path
HtmlConverter.PluginPath = @"C:\path\to\plugins";

// Convert using Qt engine
HtmlConverter.Convert(
    htmlContent,
    @"C:\output\document.pdf",
    true,                           // Enable JavaScript
    60000,                          // Timeout in milliseconds
    new System.Drawing.SizeF(612, 792),  // Page size
    new Spire.Pdf.Graphics.PdfMargins(0),
    LoadHtmlType.SourceCode
);

Limitations:

Text becomes selectable but hyperlinks are lost
Official response: "The plugin method uses QT, which doesn't support keeping the link during conversion. Sorry there is no good way to deal with it yet."
Requires separate plugin download and deployment
Platform compatibility issues: "The plugin is compatible with X86 platform well, but the compatibility with the X64 platform is not good at present"
Requires Microsoft Visual C++ 2015 Redistributable
Linux support is problematic with additional dependencies

Workaround 2: Use Spire.Doc Instead

Approach: Use the Spire.Doc library to convert HTML to DOCX, then DOCX to PDF.

using Spire.Doc;

Document doc = new Document();
doc.LoadFromFile(htmlFile, FileFormat.Html);
doc.SaveToFile("output.pdf", FileFormat.PDF);

Limitations:

Requires additional license for Spire.Doc
Two-step conversion adds processing time
HTML/CSS support limited to what Word can interpret
Complex layouts may not convert correctly
Cannot add PDF-specific features like attachments

Workaround 3: PdfHTMLTextElement for Simple HTML

Approach: Use PdfHTMLTextElement class for rendering basic HTML tags as actual text.

using Spire.Pdf;
using Spire.Pdf.HtmlConverter;

PdfDocument doc = new PdfDocument();
PdfPageBase page = doc.Pages.Add();

PdfHTMLTextElement htmlElement = new PdfHTMLTextElement(
    "<b>Bold</b> and <i>italic</i> text",
    PdfFontBase,
    PdfBrush
);
htmlElement.Draw(page, new PointF(0, 0));

Limitations:

Only supports basic tags: Font, B, I, U, Sub, Sup, BR
No CSS support
No JavaScript support
No complex layouts
Not available in .NET Core or .NET Standard
Unusable for real-world HTML documents

Workaround 4: Increase Screenshot DPI

Approach: Configure higher DPI for the IE rendering to improve image quality.

Limitations:

Text is still rasterized, just at higher resolution
File sizes increase even further
Still no text selection, search, or accessibility
Does not solve the fundamental problem

A Different Approach: IronPDF

For applications that require actual PDF text content from HTML, the solution requires a library that renders HTML using a modern browser engine and constructs proper PDF text layers. IronPDF uses an embedded Chromium browser engine that renders HTML with full CSS3 and JavaScript support, then constructs PDFs with vector text, working hyperlinks, and accessibility metadata.

Why IronPDF Produces Selectable Text

IronPDF's architecture differs fundamentally from Spire.PDF's IE-based approach. Rather than capturing screenshots, IronPDF:

Renders HTML using an embedded Chromium engine (the same engine as Chrome and Edge)
Processes the rendered DOM to construct PDF text objects
Preserves hyperlinks as PDF annotations
Maintains the document structure for accessibility
Generates vector-based text that scales without quality loss

This approach produces PDFs where:

Text is selectable with click-and-drag
Ctrl+F search finds all text content
Copy and paste works correctly
Screen readers can interpret the document
Hyperlinks remain clickable
File sizes remain small (text as vectors, not bitmaps)
Zooming shows sharp text at any scale

Code Example

The following example demonstrates HTML-to-PDF conversion that produces fully selectable, searchable text:

using IronPdf;
using System;

public class HtmlToPdfWithSelectableText
{
    public void ConvertHtmlWithTextLayer()
    {
        // Initialize the Chromium-based renderer
        var renderer = new ChromePdfRenderer();

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

        // Enable JavaScript for dynamic content
        renderer.RenderingOptions.EnableJavaScript = true;

        // HTML with various formatting and links
        string htmlContent = @"
            <!DOCTYPE html>
            <html>
            <head>
                <style>
                    body {
                        font-family: 'Segoe UI', Arial, sans-serif;
                        line-height: 1.6;
                        color: #333;
                    }
                    h1 { color: #2c3e50; }
                    .highlight { background-color: #ffffcc; }
                    a { color: #3498db; }
                    table { border-collapse: collapse; width: 100%; }
                    td, th { border: 1px solid #ddd; padding: 8px; }
                </style>
            </head>
            <body>
                <h1>Invoice #12345</h1>
                <p>This text is <span class='highlight'>fully selectable</span>
                   and searchable in the resulting PDF.</p>

                <p>Visit our website: <a href='https://example.com'>example.com</a></p>

                <table>
                    <tr><th>Item</th><th>Price</th></tr>
                    <tr><td>Widget A</td><td>$29.99</td></tr>
                    <tr><td>Widget B</td><td>$49.99</td></tr>
                </table>

                <p>Total: $79.98</p>
            </body>
            </html>";

        // Render HTML to PDF with proper text layer
        using (var pdf = renderer.RenderHtmlAsPdf(htmlContent))
        {
            // Save the PDF - text will be selectable
            pdf.SaveAs("invoice.pdf");

            // Demonstrate that text extraction works
            string extractedText = pdf.ExtractAllText();
            Console.WriteLine("Extracted text (proves text layer exists):");
            Console.WriteLine(extractedText);
        }

        // File size comparison:
        // - Rasterized image-based PDF: typically 2-5 MB for a single page
        // - Vector text-based PDF: typically 50-200 KB for the same content
    }

    public void ConvertUrlWithAccessibility()
    {
        var renderer = new ChromePdfRenderer();

        // Configure for accessibility compliance
        renderer.RenderingOptions.Title = "Accessible PDF Document";
        renderer.RenderingOptions.PaperSize = IronPdf.Rendering.PdfPaperSize.A4;

        // Render from URL - hyperlinks remain clickable
        using (var pdf = renderer.RenderUrlAsPdf("https://example.com/article"))
        {
            pdf.SaveAs("accessible-article.pdf");
        }

        // The resulting PDF:
        // - Contains actual text that screen readers can interpret
        // - Preserves hyperlinks as clickable PDF annotations
        // - Maintains reading order from the HTML structure
        // - Complies with accessibility requirements
    }

    public void BatchConvertWithConsistentQuality()
    {
        var renderer = new ChromePdfRenderer();

        string[] htmlFiles = { "report1.html", "report2.html", "report3.html" };

        foreach (var htmlFile in htmlFiles)
        {
            string html = System.IO.File.ReadAllText(htmlFile);

            using (var pdf = renderer.RenderHtmlAsPdf(html))
            {
                string outputPath = htmlFile.Replace(".html", ".pdf");
                pdf.SaveAs(outputPath);

                // Every PDF has:
                // - Selectable text (not screenshots)
                // - Working hyperlinks
                // - Searchable content
                // - Small file size
            }
        }
    }
}

Key points about this code:

ChromePdfRenderer uses Chromium for rendering, not Internet Explorer
Text is rendered as vector PDF text objects, not rasterized images
Hyperlinks in HTML become clickable PDF link annotations
ExtractAllText() returns actual content because a text layer exists
File sizes remain small because text is stored as vectors
CSS and JavaScript are fully supported

API Reference

For details on the methods used above:

ChromePdfRenderer - Main rendering class using Chromium engine
RenderHtmlAsPdf - Convert HTML string to PDF
RenderUrlAsPdf - Convert web page URL to PDF
ExtractAllText - Text extraction proving text layer exists
HTML to PDF Tutorial - Complete guide to HTML rendering

Migration Considerations

Licensing

IronPDF is commercial software with per-developer licensing. A free trial is available for evaluation without watermarks for development purposes. Teams should verify that IronPDF meets their specific HTML rendering requirements before committing to migration.

API Differences

The migration from Spire.PDF to IronPDF for HTML conversion is straightforward:

// Spire.PDF (produces rasterized images)
PdfDocument doc = new PdfDocument();
doc.LoadFromHTML(url, false, true, true);
doc.SaveToFile("output.pdf");

// IronPDF (produces selectable text)
var renderer = new ChromePdfRenderer();
var pdf = renderer.RenderUrlAsPdf(url);
pdf.SaveAs("output.pdf");

The conceptual model differs slightly: Spire.PDF loads HTML into an existing document object, while IronPDF's renderer creates new PDF documents. For most use cases, this requires minimal code changes.

What You Gain

Text that is actually selectable and searchable
Hyperlinks that work in the PDF
Accessibility for screen readers and assistive technology
File sizes 10-50x smaller (text as vectors, not images)
Modern CSS3 and JavaScript support
Consistent rendering across platforms
No dependency on Internet Explorer or system-installed browsers

What to Consider

Commercial licensing cost
Slightly different API structure
Chromium engine adds approximately 100-200MB to deployment size
First render may take 1-2 seconds for Chromium initialization

Conclusion

Spire.PDF's HTML-to-PDF conversion produces rasterized screenshots rather than actual PDF text, making the resulting documents unsearchable, inaccessible, and unnecessarily large. This is an architectural limitation of the IE-based rendering approach that cannot be fixed with configuration changes. For applications requiring proper PDF text layers, migrating to a library with Chromium-based rendering provides PDFs where text is selectable, searchable, and accessible.

Written by Jacob Mellor, CTO at Iron Software and original developer of IronPDF.

References

Html to PDF can't select text in PDF - Spire.PDF Forums{:rel="nofollow"} - Primary thread documenting the text selection issue
LoadFromHTML as text instead of image? - Spire.PDF Forums{:rel="nofollow"} - Developer request for actual text rendering
HtmlToPdf not possible to mark text or follow links - Spire.PDF Forums{:rel="nofollow"} - Links and text selection issues
Grainy HTML to PDF - Spire.PDF Forums{:rel="nofollow"} - Quality degradation from rasterization
Issue with Spire HTML to PDF conversion - Spire.PDF Forums{:rel="nofollow"} - General conversion problems
Convert HTML to PDF with New Plugin - E-iceblue Knowledge Base{:rel="nofollow"} - Qt plugin documentation
Massive Filesize Increase Problem - Spire.PDF Forums{:rel="nofollow"} - File size bloat from image-based conversion
HTML to PDF - Spire.PDF Forums{:rel="nofollow"} - Official confirmation of IE dependency
Troubleshoot QT Plugin Issue - Spire.PDF Forums{:rel="nofollow"} - Qt plugin limitations
html string to pdf one Linux with QT plugin not working - Spire.PDF Forums{:rel="nofollow"} - Cross-platform plugin issues

For IronPDF documentation and tutorials, visit ironpdf.com.

iTextSharp HTML to PDF in C#: Why HTMLWorker Breaks (Issue Fixed)

IronSoftware — Fri, 03 Apr 2026 10:05:00 +0000

Developers searching for HTML-to-PDF conversion with iTextSharp encounter a fundamental limitation: iTextSharp and iText 7 were not designed for rendering HTML as a web browser would. The libraries provide limited HTML parsing capabilities that break with modern HTML5/CSS3 content. With over 300,000 developers viewing this question on Stack Overflow, the demand is clear but the solution within iText is not straightforward. This article examines the limitations, shows the correct patterns for iTextSharp, and presents alternatives with browser-accurate rendering.

The Problem

iTextSharp (the .NET port of iText 5) and its successor iText 7 are PDF manipulation libraries, not HTML rendering engines. They provide HTMLWorker (deprecated) and pdfHTML (add-on product) for HTML parsing, but neither implements a browser-compatible rendering engine.

When developers attempt to convert HTML to PDF with iTextSharp, they encounter:

Incomplete CSS support (no flexbox, grid, or modern layout)
Missing JavaScript execution (dynamic content doesn't render)
Broken layouts for responsive designs
No support for web fonts without manual configuration
Image handling issues with relative URLs

The expectation gap is significant: developers want browser-quality PDF output, but iTextSharp provides basic HTML parsing at best.

Error Messages and Symptoms

Common issues when using iTextSharp's HTMLWorker:

iTextSharp.text.html.simpleparser.HTMLWorker is obsolete

// This approach produces broken output for modern HTML
using (var stringReader = new StringReader(html))
{
    HTMLWorker htmlWorker = new HTMLWorker(document);
    htmlWorker.Parse(stringReader); // Fails on CSS3, HTML5 elements
}

With iText 7's pdfHTML add-on:

com.itextpdf.html2pdf.exceptions.CssApplierInitializationException:
Cannot find CSS applier for tag 'article'

com.itextpdf.html2pdf.exceptions.TagWorkerInitializationException:
Tag worker for element 'section' was not found

Symptoms include:

Tables rendering without proper column widths
Floated elements collapsing or overlapping
Background images not appearing
Custom fonts displaying as fallback fonts
Responsive layouts breaking completely

Who Is Affected

The 309,000+ views on Stack Overflow indicate massive demand across:

Industries: Reporting systems, invoice generation, document automation, legal document processing, healthcare records, and any system generating documents from web content.

Frameworks: .NET Framework with iTextSharp, .NET Core/5/6/7/8 with iText 7.

Use Cases:

Converting HTML templates to PDF invoices or receipts
Generating reports from HTML dashboards
Creating printable versions of web pages
Automating document generation from CMS content

Evidence from the Developer Community

Scale of the Problem

Stack Overflow tracks these highly-viewed questions:

Question	Views	Score
"How to convert HTML to PDF using iTextSharp"	309,021	77
"Convert HTML to PDF in .NET"	959,034	528
"iText 7 HTML to PDF conversion"	185,727	21

Timeline

Date	Event	Source
2014-08-06	Original question posted	Stack Overflow
2015-2018	Answers reference HTMLWorker (now deprecated)	Stack Overflow
2019-2021	Answers shift to pdfHTML add-on recommendation	Stack Overflow
2025-01-15	Question still receiving new views and answers	Stack Overflow

Community Reports

"I want to convert the below HTML to PDF using iTextSharp but don't know where to start."
— Developer, Stack Overflow, August 2014

"HTMLWorker is deprecated and limited. pdfHTML is better but requires a separate license."
— Stack Overflow Answer, 2020

"For anything with complex CSS, you need a browser engine. iText's HTML support is basic."
— Stack Overflow Comment, 2023

Getting Started: NuGet Package Installation

Before examining the limitations, developers need to understand the different package options.

iTextSharp (.NET Framework)

# For .NET Framework 4.x projects
Install-Package iTextSharp -Version 5.5.13.3

<!-- Package reference in .csproj -->
<PackageReference Include="iTextSharp" Version="5.5.13.3" />

Note: iTextSharp 5.x is no longer actively developed. The last release was in 2022.

iText 7 (.NET Core / .NET 5+)

# Core library
Install-Package iText7 -Version 8.0.2

# HTML conversion add-on (separate commercial license required)
Install-Package itext7.pdfhtml -Version 5.0.2

<!-- Package references -->
<PackageReference Include="iText7" Version="8.0.2" />
<PackageReference Include="itext7.pdfhtml" Version="5.0.2" />

Project Configuration

For .NET Core or .NET 6+ projects:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="iText7" Version="8.0.2" />
    <PackageReference Include="itext7.pdfhtml" Version="5.0.2" />
  </ItemGroup>
</Project>

Licensing Considerations

iText uses dual licensing:

AGPL v3: Free for open-source projects that release source code
Commercial License: Required for proprietary/closed-source applications

The pdfHTML add-on requires an additional commercial license beyond the base iText 7 license.

Root Cause Analysis

iTextSharp and iText 7 are fundamentally PDF object manipulation libraries. PDF generation from scratch, modification, form filling, and extraction are their primary purposes.

HTML-to-PDF conversion requires:

HTML Parser: Understanding HTML5 elements and structure
CSS Engine: Implementing the CSS box model, selectors, cascading
Layout Engine: Calculating positions, handling floats, flexbox, grid
Font Renderer: Loading and rendering fonts including web fonts
JavaScript Engine: Executing scripts that modify content

iText provides partial implementations of 1 and 2, with significant gaps. It does not include 3, 4, or 5 in any browser-compatible form.

HTMLWorker vs pdfHTML Comparison

Feature	HTMLWorker (iText 5)	pdfHTML (iText 7)
Status	Deprecated	Active
License	AGPL/Commercial	Additional license required
HTML5 elements	Limited	Partial
CSS3 support	Minimal	Partial (no flexbox/grid)
JavaScript	No	No
Web fonts	No	Limited
Active development	No	Yes

The pdfHTML add-on improves on HTMLWorker but still lacks:

Full CSS3 support (flexbox, grid, variables)
JavaScript execution
Browser-compatible rendering

This is a design limitation, not a bug. Implementing a full browser engine would be a separate product entirely.

Attempted Workarounds

Workaround 1: pdfHTML Add-on

Approach: Purchase and use iText's pdfHTML commercial add-on.

using iText.Html2pdf;

public byte[] ConvertWithPdfHtml(string html)
{
    using var outputStream = new MemoryStream();
    HtmlConverter.ConvertToPdf(html, outputStream);
    return outputStream.ToArray();
}

Limitations:

Separate commercial license required
Still lacks flexbox, grid, and modern CSS3
No JavaScript execution
Output quality varies significantly from browser rendering

Workaround 2: Pre-process HTML

Approach: Simplify HTML to only use features iTextSharp supports.

// Convert modern HTML to iText-compatible subset
string simplifiedHtml = html
    .Replace("<article>", "<div>")
    .Replace("</article>", "</div>")
    .Replace("<section>", "<div>")
    .Replace("</section>", "</div>");
// Remove CSS that won't work
// Inline all styles
// Etc.

Limitations:

Significant development effort
Maintains two versions of templates
Breaks responsive designs
Not scalable for complex documents

Workaround 3: HTML to Image to PDF

Approach: Render HTML to an image using a browser automation tool, then embed in PDF.

Limitations:

Text is not selectable in output PDF
File sizes much larger
Quality issues with scaling
Loss of PDF features (links, bookmarks)

A Different Approach: IronPDF

IronPDF embeds a Chromium browser engine specifically for HTML-to-PDF conversion. Rather than parsing HTML and approximating browser behavior, it renders HTML exactly as Chrome would.

Why IronPDF Handles HTML Differently

IronPDF's architecture is fundamentally different:

Full Chromium Engine: Same rendering engine used by Google Chrome
Complete CSS3: Flexbox, Grid, Variables, Animations (rendered as final state)
JavaScript Execution: Dynamic content, charting libraries, frameworks all work
Web Fonts: Google Fonts, custom fonts load automatically
Responsive Rendering: Media queries and viewport handling included

When you convert HTML with IronPDF, you're generating a PDF from an actual browser render, not a parsed approximation.

Code Example

using IronPdf;

public class ReportGenerator
{
    public byte[] GenerateReport(string htmlContent)
    {
        var renderer = new ChromePdfRenderer();

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

        // Enable features for complex content
        renderer.RenderingOptions.EnableJavaScript = true;
        renderer.RenderingOptions.RenderDelay = 500; // Wait for JS to complete

        // Render HTML to PDF - uses actual Chrome rendering
        using var pdf = renderer.RenderHtmlAsPdf(htmlContent);

        return pdf.BinaryData;
    }
}

Example with modern HTML/CSS:

public byte[] CreateModernDashboardPdf()
{
    var renderer = new ChromePdfRenderer();

    string html = @"
<!DOCTYPE html>
<html>
<head>
    <link href='https://fonts.googleapis.com/css2?family=Inter:wght@400;600&display=swap' rel='stylesheet'>
    <style>
        body {
            font-family: 'Inter', sans-serif;
            margin: 0;
            padding: 20px;
        }
        .dashboard {
            display: grid;
            grid-template-columns: repeat(3, 1fr);
            gap: 20px;
        }
        .card {
            background: linear-gradient(135deg, #667eea 0%, #764ba2 100%);
            border-radius: 12px;
            padding: 24px;
            color: white;
        }
        .card h3 {
            margin: 0 0 8px 0;
            font-weight: 600;
        }
        .card .value {
            font-size: 2.5rem;
            font-weight: 600;
        }
        @media print {
            .dashboard { grid-template-columns: repeat(2, 1fr); }
        }
    </style>
</head>
<body>
    <h1>Q4 2025 Dashboard</h1>
    <div class='dashboard'>
        <div class='card'>
            <h3>Revenue</h3>
            <div class='value'>$2.4M</div>
        </div>
        <div class='card'>
            <h3>Users</h3>
            <div class='value'>48.2K</div>
        </div>
        <div class='card'>
            <h3>Conversion</h3>
            <div class='value'>3.2%</div>
        </div>
    </div>
</body>
</html>";

    using var pdf = renderer.RenderHtmlAsPdf(html);
    return pdf.BinaryData;
}

Key points about this code:

CSS Grid layout works exactly as in a browser
Google Fonts load automatically
Gradients and border-radius render correctly
Print media queries are respected

Converting URLs

public byte[] ConvertWebPage(string url)
{
    var renderer = new ChromePdfRenderer();

    // Render a live web page
    using var pdf = renderer.RenderUrlAsPdf(url);

    return pdf.BinaryData;
}

JavaScript Execution: Charts and Dynamic Content

One major difference is JavaScript support. iText cannot execute JavaScript, so charts and dynamically generated content do not render.

public byte[] GenerateChartPdf()
{
    var renderer = new ChromePdfRenderer();

    // Enable JavaScript and wait for execution
    renderer.RenderingOptions.EnableJavaScript = true;
    renderer.RenderingOptions.WaitFor.JavaScript(2000); // Wait up to 2 seconds

    string html = @"
<!DOCTYPE html>
<html>
<head>
    <script src='https://cdn.jsdelivr.net/npm/chart.js'></script>
</head>
<body>
    <h1>Sales Report</h1>
    <canvas id='myChart' width='400' height='200'></canvas>
    <script>
        var ctx = document.getElementById('myChart').getContext('2d');
        new Chart(ctx, {
            type: 'bar',
            data: {
                labels: ['Jan', 'Feb', 'Mar', 'Apr', 'May', 'Jun'],
                datasets: [{
                    label: 'Sales ($K)',
                    data: [12, 19, 3, 5, 2, 3],
                    backgroundColor: 'rgba(54, 162, 235, 0.8)'
                }]
            }
        });
    </script>
</body>
</html>";

    using var pdf = renderer.RenderHtmlAsPdf(html);
    return pdf.BinaryData;
}

Print-Specific CSS Handling

IronPDF respects print media queries, allowing print-specific styling:

public byte[] GeneratePrintOptimizedDocument()
{
    var renderer = new ChromePdfRenderer();

    // Use print media type
    renderer.RenderingOptions.CssMediaType = IronPdf.Rendering.PdfCssMediaType.Print;

    string html = @"
<!DOCTYPE html>
<html>
<head>
    <style>
        /* Screen styles */
        @media screen {
            body { background: #f5f5f5; }
            .no-print { display: block; }
        }

        /* Print styles */
        @media print {
            body {
                background: white;
                font-size: 12pt;
            }
            .no-print { display: none; }
            .page-break { page-break-after: always; }

            a[href]::after {
                content: ' (' attr(href) ')';
            }
        }
    </style>
</head>
<body>
    <div class='no-print'>This navigation won't appear in PDF</div>

    <h1>Chapter 1</h1>
    <p>Content for first page...</p>

    <div class='page-break'></div>

    <h1>Chapter 2</h1>
    <p>Content for second page...</p>
</body>
</html>";

    using var pdf = renderer.RenderHtmlAsPdf(html);
    return pdf.BinaryData;
}

PDF/A Compliance for Archival

For long-term document archival:

public byte[] GenerateArchivalPdf()
{
    var renderer = new ChromePdfRenderer();

    string html = "<html><body><h1>Archived Document</h1></body></html>";

    using var pdf = renderer.RenderHtmlAsPdf(html);

    // Save as PDF/A-3b for archival compliance
    pdf.SaveAsPdfA("archived-document.pdf", IronPdf.PdfAVersions.PdfA3b);

    return pdf.BinaryData;
}

API Reference

For more details on the methods used:

Migration Considerations

Licensing

IronPDF is commercial software with per-developer licensing
Free trial available for evaluation
Pricing details

API Differences

iTextSharp: PDF object manipulation with limited HTML parsing
IronPDF: HTML/CSS-first approach with full browser rendering

Migration typically means:

Remove HTMLWorker or pdfHTML code
Replace with ChromePdfRenderer
Keep existing HTML templates unchanged (or simplify them)

What You Gain

Browser-quality PDF output from any HTML/CSS
JavaScript support for dynamic content
Full CSS3 including modern layout (flexbox, grid)
Web fonts load automatically

What to Consider

Chromium binaries add to deployment size
Different pricing model than iText
Different API paradigm (HTML-first vs PDF-first)

Conclusion

iTextSharp and iText 7 were designed for PDF manipulation, not browser-quality HTML rendering. Developers seeking accurate HTML-to-PDF conversion face fundamental limitations with these libraries. For projects where HTML templates must render exactly as they appear in browsers, a Chromium-based approach provides the rendering accuracy that parsed HTML cannot achieve.

Jacob Mellor has spent 25+ years building developer tools, including IronPDF.

References

Stack Overflow: How to convert HTML to PDF using iTextSharp{:rel="nofollow"} - 309K+ views
Stack Overflow: Convert HTML to PDF in .NET{:rel="nofollow"} - 959K+ views

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

SelectPdf Linux Error: Unable to Load kernel32.dll (Issue Fixed)

IronSoftware — Thu, 02 Apr 2026 14:34:00 +0000

Developers attempting to use SelectPdf on Linux environments encounter a runtime exception: Unable to load shared library 'kernel32.dll' or one of its dependencies. This error indicates a fundamental platform limitation rather than a configuration issue. SelectPdf is a Windows-only library with no Linux support.

The Problem

SelectPdf relies on Windows-specific native libraries, including kernel32.dll, which is a core Windows system component. When developers deploy applications using SelectPdf to Linux servers, Docker containers, or other non-Windows environments, the application fails immediately upon attempting any PDF operation.

This limitation affects developers who initially build and test on Windows development machines, only to discover the incompatibility when deploying to production Linux environments. The error occurs regardless of .NET version, framework configuration, or runtime settings because the underlying dependency simply does not exist on Linux.

Unlike some libraries where Linux compatibility issues stem from optional dependencies that can be worked around, SelectPdf's Windows-only architecture means there is no configuration change, package installation, or code modification that enables Linux operation.

Error Messages and Symptoms

System.DllNotFoundException: Unable to load shared library 'kernel32.dll' or one of its dependencies.
In order to help diagnose loading problems, consider setting the LD_DEBUG environment variable:
libkernel32.dll: cannot open shared object file: No such file or directory

The error surfaces immediately when SelectPdf attempts to initialize its rendering engine, preventing any HTML-to-PDF conversion from occurring.

Who Is Affected

This limitation impacts developers in several common scenarios:

Linux server deployments (Ubuntu, Debian, CentOS, RHEL, Alpine)
Docker containerized applications using Linux base images
Azure App Service on Linux
AWS Lambda and other serverless platforms
CI/CD pipelines running on Linux build agents
Kubernetes deployments with Linux nodes
macOS development environments

The issue affects all .NET versions including .NET Core 3.1, .NET 5, .NET 6, .NET 7, and .NET 8. Since the limitation is architectural rather than version-specific, no framework update resolves it.

Evidence from the Developer Community

Developers have reported this issue across multiple channels, consistently receiving the same response: SelectPdf does not support Linux.

Timeline

Date	Event	Source
2021-02-10	First GitHub issue opened	GitHub
2021-02-10	Official response confirms Windows-only	GitHub
2025-01-20	No Linux support announced	-

Community Reports

"Unable to load shared library 'kernel32.dll' or one of its dependencies"
-- GitHub Issue #2, SelectPdf Repository, 2021

The GitHub issue repository for SelectPdf shows multiple developers encountering this same limitation when attempting Linux deployments. The maintainer response confirms SelectPdf's Windows-only architecture.

Additional developers on Stack Overflow and Reddit have reported discovering this limitation only after building applications with SelectPdf, leading to significant refactoring efforts when deployment requirements included Linux environments.

Root Cause Analysis

SelectPdf depends directly on Windows API calls through P/Invoke to kernel32.dll and potentially other Windows system libraries. This architectural decision means:

Native Dependency: The library makes system calls to Windows kernel functions that have no Linux equivalents
No Abstraction Layer: Unlike cross-platform libraries that use abstraction layers (like .NET's own cross-platform APIs), SelectPdf calls Windows APIs directly
Binary Incompatibility: The compiled native components are Windows PE (Portable Executable) format, not Linux ELF format

This is not a bug that can be fixed with a patch or configuration change. Supporting Linux would require a complete rewrite of SelectPdf's rendering engine architecture, which the maintainers have indicated is not planned.

Attempted Workarounds

Workaround 1: Wine Compatibility Layer

Approach: Some developers have attempted running SelectPdf through Wine on Linux.

Limitations:

Unreliable rendering results
Performance overhead
Additional deployment complexity
Not suitable for production environments
Incompatible with containerized deployments

Workaround 2: Windows Container

Approach: Using Windows containers instead of Linux containers.

Limitations:

Windows containers have significantly larger image sizes (gigabytes vs megabytes)
Limited orchestration platform support
Higher resource consumption
Increased licensing costs
Many cloud platforms prefer or require Linux containers

Workaround 3: Remote Windows Service

Approach: Running a separate Windows service/API that handles PDF generation.

Limitations:

Added infrastructure complexity
Network latency for each PDF operation
Additional points of failure
Higher operational costs
Complicates deployment pipelines

None of these workarounds provide a production-ready solution for Linux deployments.

A Different Approach: IronPDF

For developers who need cross-platform PDF generation, IronPDF provides native support for Windows, Linux, macOS, and Docker environments. The library uses a self-contained Chromium-based rendering engine that ships with the package, eliminating external dependencies.

Why IronPDF Works on Linux

IronPDF's architecture differs fundamentally from SelectPdf:

Embedded Rendering Engine: IronPDF includes its own Chromium-based renderer, packaged as platform-specific native binaries for each supported OS
Platform Detection: The library automatically loads the correct native components based on the runtime environment
No System Dependencies: Linux deployments require minimal additional packages (standard libraries that most distributions include by default)
Docker-Native Support: IronPDF provides tested Docker configurations and base images

Code Example: HTML to PDF on Linux

using IronPdf;

// IronPDF works identically on Windows, Linux, and macOS
// No platform-specific code required

public class LinuxPdfGenerator
{
    public void GeneratePdfFromHtml()
    {
        // Configure renderer for Linux environment
        // Note: This configuration works on any platform
        var renderer = new ChromePdfRenderer();

        // Set rendering options
        renderer.RenderingOptions.MarginTop = 20;
        renderer.RenderingOptions.MarginBottom = 20;
        renderer.RenderingOptions.PaperSize = IronPdf.Rendering.PdfPaperSize.A4;

        // Convert HTML string to PDF
        string html = @"
            <html>
            <head>
                <style>
                    body { font-family: Arial, sans-serif; }
                    h1 { color: #333; }
                </style>
            </head>
            <body>
                <h1>Generated on Linux</h1>
                <p>This PDF was created using IronPDF running on a Linux server.</p>
            </body>
            </html>";

        var pdf = renderer.RenderHtmlAsPdf(html);

        // Save to file
        pdf.SaveAs("/app/output/document.pdf");
    }
}

Key points about this code:

The code runs identically on Windows, Linux, and macOS
No platform-specific configuration required
IronPDF handles native library loading automatically
Full CSS and JavaScript support via Chromium engine

Docker Deployment Example

# Dockerfile for IronPDF on Linux
FROM mcr.microsoft.com/dotnet/aspnet:8.0

# Install minimal dependencies for IronPDF
RUN apt-get update && apt-get install -y \
    libgdiplus \
    libc6-dev \
    && rm -rf /var/lib/apt/lists/*

WORKDIR /app
COPY --from=build /app/publish .

ENTRYPOINT ["dotnet", "YourApp.dll"]

using IronPdf;

// Docker-specific configuration (optional, for optimization)
public class DockerPdfService
{
    public byte[] ConvertHtmlToPdf(string htmlContent)
    {
        // Enable Docker compatibility mode
        Installation.LinuxAndDockerDependenciesAutoConfig = true;

        var renderer = new ChromePdfRenderer();

        // Configure for containerized environment
        renderer.RenderingOptions.EnableJavaScript = true;
        renderer.RenderingOptions.RenderDelay = 500; // Wait for JS execution

        var pdf = renderer.RenderHtmlAsPdf(htmlContent);

        return pdf.BinaryData;
    }
}

Azure App Service on Linux

using IronPdf;
using Microsoft.AspNetCore.Mvc;

[ApiController]
[Route("api/[controller]")]
public class PdfController : ControllerBase
{
    [HttpPost("generate")]
    public IActionResult GeneratePdf([FromBody] string htmlContent)
    {
        // Works on Azure App Service Linux without additional configuration
        var renderer = new ChromePdfRenderer();

        var pdf = renderer.RenderHtmlAsPdf(htmlContent);

        return File(pdf.BinaryData, "application/pdf", "document.pdf");
    }
}

API Reference

For complete documentation on Linux deployment:

Migration Considerations

Licensing

IronPDF operates under a commercial license model:

Free development and testing with watermark
Licensed versions for production use
Perpetual licenses available
Licensing details

API Differences

Migrating from SelectPdf requires code changes:

SelectPdf	IronPDF
`HtmlToPdf`	`ChromePdfRenderer`
`PdfDocument`	`PdfDocument`
`SelectPdf.Converter.ConvertUrl()`	`renderer.RenderUrlAsPdf()`
`SelectPdf.Converter.ConvertHtmlString()`	`renderer.RenderHtmlAsPdf()`

Most migrations involve updating class names and method calls. The conceptual approach remains similar.

What You Gain

Native Linux, macOS, and Windows support
Docker container compatibility
Azure App Service Linux deployment
AWS Lambda support
Kubernetes deployment capability
Consistent behavior across platforms

What to Consider

Commercial license required for production
Package size is larger than SelectPdf due to embedded Chromium
Initial render may take slightly longer as Chromium initializes

Conclusion

SelectPdf does not support Linux and there is no workaround available. The Unable to load kernel32.dll error indicates a fundamental platform limitation. Developers requiring PDF generation on Linux environments need to evaluate alternative libraries. IronPDF provides cross-platform support with native Linux compatibility, eliminating platform-related deployment failures.

Jacob Mellor originally built IronPDF and leads technical development at Iron Software.

References

SelectPdf GitHub Issue #2: Linux Support{:rel="nofollow"} - Original report of Linux incompatibility
IronPDF Docker and Linux Documentation - Official guide for Linux deployment
IronPDF Linux Installation Guide - Platform-specific setup instructions

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

Fixing Memory Growth in PDFTron and Apryse SDK Applications (Fixed)

IronSoftware — Thu, 02 Apr 2026 11:33:00 +0000

Developers using PDFTron (now Apryse) SDK frequently encounter a frustrating problem: memory that grows continuously during document processing and never gets released. Applications that work fine with a few documents start crashing with "bad memory allocation" errors when processing batches. Web viewers consume more RAM with each document opened until the browser tab crashes. This article examines why these memory issues occur and explores a different architectural approach that avoids them.

The Problem

The PDFTron/Apryse SDK is built on native C++ libraries with wrappers for .NET, Java, Python, Ruby, and JavaScript. This architecture creates a fundamental tension: developers writing in managed languages like C# expect the garbage collector to handle memory cleanup, but the underlying native memory requires explicit disposal calls that the garbage collector cannot manage.

When a .NET developer creates a PDFDoc object, calls methods on it, and lets it go out of scope, the managed wrapper gets collected but the native memory often remains allocated. This pattern repeats across PDFDraw, ElementBuilder, ElementWriter, TextExtractor, and other core classes. In a batch processing scenario where thousands of documents flow through the system, memory accumulates until the process crashes.

The StreamingPDFConversion API exhibits particularly problematic behavior. This API, designed for converting images and other formats to PDF, has documented memory leaks that persist across multiple SDK versions. Apryse acknowledged in their version 10.11.0 changelog that they "fixed a memory leak that could occur during conversion from TIFF to PDF with Convert.StreamingPDFConversion() or Convert.UniversalConversion()."

Error Messages and Symptoms

Developers report various symptoms depending on their platform and use case:

System.OutOfMemoryException: Exception of type 'System.OutOfMemoryException' was thrown.

Error code: Out of Memory (browser crash)

bad allocation errors during PDF to image conversion

System.IO.IOException: Stream was too long

The WebViewer JavaScript component shows similar patterns. Memory allocated when loading documents does not get released when documents are closed, leading to progressive degradation in browser tab performance.

Who Is Affected

This memory growth issue spans the entire Apryse/PDFTron product line:

Operating Systems: Windows, Linux, macOS, iOS, Android

SDK Platforms: .NET Framework, .NET Core/.NET 5+, Java, Python, Ruby, Go, PHP, JavaScript/WebViewer

Affected Versions: Reports span from version 5.1.10 (2019) through version 10.1 (2023) and beyond, with some fixes appearing in 10.11.0 (2024) and 11.8.0 (2025)

Use Cases:

Batch document conversion (converting hundreds or thousands of files)
Long-running web applications with PDF viewing
PDF merging operations (combining many documents into one)
Image to PDF conversion via StreamingPDFConversion
Mobile applications where users view multiple documents in a session

The issue is particularly acute in cloud environments like AWS Lambda where memory limits are strict and disk caching may not be available as a workaround.

Evidence from the Developer Community

The PDFTron memory leak problem has been reported consistently for over fifteen years across multiple platforms and languages.

Timeline

Date	Event	Source
2009-02-01	First reports of bad allocation errors during batch PDF to image conversion	Apryse Community{:rel="nofollow"}
2019-07-01	WebViewer memory leak identified in loadScript.js and webviewer-ui.js	GitHub Issue #317{:rel="nofollow"}
2021-03-01	iOS PTDocumentController memory leak confirmed by PDFTron on iOS 14	Google Groups{:rel="nofollow"}
2022-05-01	React WebViewer memory leak reported	Apryse Community{:rel="nofollow"}
2022-11-01	.NET SDK memory leak in Save() method identified	Apryse Community{:rel="nofollow"}
2023-06-01	StreamingPDFConversion memory leak confirmed	Apryse Community{:rel="nofollow"}
2024-07-24	StreamingPDFConversion memory leak fixed in v10.11.0	Apryse Changelog
2025-10-08	Additional memory leaks fixed in v11.8.0	Apryse Changelog

Community Reports

"Ever-growing memory usage with StreamingPDFConversion. Our app was crashing with errors related to bad memory allocation. Memory profiling was done with a simple script and it appeared to potentially be an issue in the SDK."
— Developer report, Apryse Community, June 2023

"~10mb memory leak each time the PDF viewer was loaded. Rather catastrophic memory leak. In src/helpers/loadScript.js there is a window.addEventListener('message'...) call that isn't properly unsubscribed."
— Developer report, GitHub Issue #317, July 2019

"Memory continues to grow as they view documents. Overriding viewWillDisappear and manually calling closeDocument seems to help a LOT, but the memory still grows pretty quickly."
— iOS developer, Apryse Community, March 2021

A developer attempting to merge 8,000 PDF files reported "memory is exceeding what is available on the system" with "roughly linear correlation in memory usage while merging PDFs." Another developer working with a 175MB document containing 7,600 pages experienced browser crashes with out of memory errors.

The issue also manifests when converting HTML to PDF. One developer reported that "HTML to PDF conversion fails when trying to create a PDF with over 3000 pages from an HTML string. Even with the timeout set to approximately 3 hours and 20 minutes (1200000ms), the conversion fails after about an hour."

Root Cause Analysis: Why PDFTron Memory Leak Occurs

Multiple architectural factors contribute to the persistent memory issues in Apryse/PDFTron:

Native Memory Management: The SDK wraps native C++ libraries. In managed languages, developers expect garbage collection to handle cleanup. However, native memory allocated by the C++ layer cannot be freed by the garbage collector. The SDK requires explicit Dispose() or Close() calls on most objects, but this is not intuitive for developers accustomed to automatic memory management.

Event Listener Leaks in WebViewer: The JavaScript WebViewer component attaches event listeners that are not properly cleaned up when instances are destroyed. The GitHub issue identified specific leaks in window.addEventListener('message'...) calls and closures over options objects in window.WebViewer.l and window.WebViewer.workerTransportPromise.

iOS-Specific Deallocation Issues: On iOS 14, Apryse confirmed that PTDocumentController was not being deallocated when removed from the view hierarchy. This platform-specific bug caused memory to grow with each document viewed.

Linear Memory Growth in Batch Operations: When processing multiple documents, the SDK does not automatically release memory between operations. Without intermediate saves and explicit disposal, memory grows proportionally with the number of documents processed.

Stream Handling Issues: The Save method in the .NET SDK uses unsafe code with TRN_PDFDocSaveMemoryBuffer. When saving to streams, particularly with large documents, this can trigger Stream was too long exceptions when the accumulated data exceeds internal limits.

Attempted Workarounds for Apryse SDK Memory Issues

The developer community has documented various approaches to mitigate the PDFTron WebViewer memory and SDK memory issues, though none fully resolve the underlying problems.

Workaround 1: Explicit Disposal of All Objects

Approach: Wrap every PDFTron object in a using statement or explicitly call Dispose() after use.

// Apryse/PDFTron pattern requiring explicit disposal
using (var doc = new PDFDoc("input.pdf"))
{
    using (var draw = new PDFDraw())
    {
        draw.SetDPI(92);
        for (int i = 1; i <= doc.GetPageCount(); i++)
        {
            using (var page = doc.GetPage(i))
            {
                draw.Export(page, $"page_{i}.png");
            }
        }
    }
} // Must ensure all objects are disposed

Limitations:

Requires remembering to dispose every object, including nested ones
Missing even one disposal in a loop can cause cumulative leaks
Not intuitive for developers coming from fully managed environments
Some leaks occur in SDK internals that developers cannot control

Workaround 2: Enable Disk Caching

Approach: Configure the SDK to use disk-based caching instead of keeping everything in memory.

PDFNet.SetDefaultDiskCachingEnabled(true);

Limitations:

Creates temporary files that need cleanup
Slower than in-memory operations
Not available in all environments (AWS Lambda, some containerized deployments)
Does not fix all memory leak sources

Workaround 3: Batch Processing with Intermediate Saves

Approach: Process documents in small batches, saving results and disposing objects between batches.

// Process in batches of 100 documents
var files = Directory.GetFiles(inputDir, "*.pdf");
for (int batch = 0; batch < files.Length; batch += 100)
{
    var batchFiles = files.Skip(batch).Take(100);
    ProcessBatch(batchFiles);
    GC.Collect();
    GC.WaitForPendingFinalizers();
}

Limitations:

Significantly more complex code
Slower overall processing
Requires managing intermediate files
Still may not prevent all memory growth within each batch

Workaround 4: WebViewer Instance Reuse

Approach: Instead of creating new WebViewer instances, reuse existing ones by loading new documents into them.

Limitations:

Requires architectural changes to the application
May not fit all use cases
Still shows memory growth over time, just slower

A Different Approach: IronPDF

For developers who have exhausted workaround options or cannot afford the complexity of managing native memory manually, switching to a library with a different architecture may be the practical solution.

IronPDF uses an embedded Chromium rendering engine that operates within the managed .NET environment. The library implements the standard IDisposable pattern, and its memory management integrates with .NET's garbage collection in a way that does not require developers to manually track and dispose every internal object.

Why IronPDF Handles Memory Differently

The architectural difference is fundamental. Rather than wrapping a native C++ library, IronPDF renders documents using Chromium processes that are managed by the library. When a document operation completes and objects go out of scope, the memory can be reclaimed through normal .NET garbage collection.

For batch operations, IronPDF does not exhibit the linear memory growth pattern seen with PDFTron. Each document is processed, resources are released, and the next document starts from a clean state.

Code Example

The following example demonstrates batch HTML-to-PDF conversion with proper resource handling:

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

/// <summary>
/// Demonstrates batch PDF generation without memory accumulation.
/// Each document is processed independently with automatic resource cleanup.
/// </summary>
public class BatchPdfGenerator
{
    public void ConvertHtmlFilesToPdf(IEnumerable<string> htmlFilePaths, string outputDirectory)
    {
        // ChromePdfRenderer implements IDisposable and manages its own lifecycle
        using var renderer = new ChromePdfRenderer();

        // Configure rendering options once
        renderer.RenderingOptions.PaperSize = IronPdf.Rendering.PdfPaperSize.A4;
        renderer.RenderingOptions.MarginTop = 25;
        renderer.RenderingOptions.MarginBottom = 25;

        int processedCount = 0;

        foreach (string htmlPath in htmlFilePaths)
        {
            try
            {
                // Read HTML content
                string htmlContent = File.ReadAllText(htmlPath);

                // Render to PDF - memory is managed automatically
                using var pdf = renderer.RenderHtmlAsPdf(htmlContent);

                // Generate output filename
                string outputPath = Path.Combine(
                    outputDirectory,
                    Path.GetFileNameWithoutExtension(htmlPath) + ".pdf"
                );

                // Save to disk
                pdf.SaveAs(outputPath);

                processedCount++;

                // No manual memory cleanup required between documents
                // The 'using' statement ensures proper disposal
            }
            catch (Exception ex)
            {
                Console.WriteLine($"Error processing {htmlPath}: {ex.Message}");
            }
        }

        Console.WriteLine($"Processed {processedCount} documents.");
    }
}

For merging multiple documents, IronPDF provides a straightforward approach that does not accumulate memory linearly:

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

/// <summary>
/// Merges multiple PDF files without the linear memory growth
/// seen when merging large numbers of documents with some libraries.
/// </summary>
public class PdfMerger
{
    public void MergeDocuments(IEnumerable<string> pdfPaths, string outputPath)
    {
        // Load all PDFs - IronPDF handles memory efficiently
        var documents = pdfPaths
            .Select(path => PdfDocument.FromFile(path))
            .ToList();

        try
        {
            // Merge all documents
            var merged = PdfDocument.Merge(documents);

            // Save the result
            merged.SaveAs(outputPath);

            // Dispose the merged document
            merged.Dispose();
        }
        finally
        {
            // Clean up source documents
            foreach (var doc in documents)
            {
                doc.Dispose();
            }
        }
    }
}

Key differences in this code:

Standard IDisposable pattern works as expected
No native memory leaks from missed disposal calls
Memory does not grow linearly during batch processing
No need for explicit GC calls or batch processing workarounds

API Reference

For detailed documentation on the classes and methods used:

ChromePdfRenderer - HTML and URL to PDF conversion
Merge or Split PDFs - Combining multiple documents
HTML to PDF Tutorial - Complete guide to HTML conversion

Migration Considerations

Switching PDF libraries is not a trivial decision. Developers should evaluate several factors.

Licensing

IronPDF is commercial software. Licenses are available per-developer and include free trial periods for evaluation. Pricing information is available on the IronPDF website. For teams currently using Apryse's commercial license, the cost comparison may be straightforward. For those using PDFTron's legacy free tier (if applicable to their use case), there is a licensing cost to consider.

API Differences

The APIs differ significantly. PDFTron uses a lower-level API with explicit element builders and writers. IronPDF uses a higher-level API centered on the ChromePdfRenderer and PdfDocument classes. Migration requires rewriting document generation code, not just swapping class names.

Example comparison:

// PDFTron approach
using (var doc = new PDFDoc())
using (var eb = new ElementBuilder())
using (var ew = new ElementWriter())
{
    var page = doc.PageCreate();
    ew.Begin(page);
    var element = eb.CreateTextBegin(font, 12);
    ew.WriteElement(element);
    // ... many more low-level operations
}

// IronPDF approach
var renderer = new ChromePdfRenderer();
var pdf = renderer.RenderHtmlAsPdf("<html><body>Content</body></html>");
pdf.SaveAs("output.pdf");

What You Gain

Standard .NET memory management without native memory quirks
No need for explicit disposal of every internal object
Batch processing without linear memory growth
Chrome-based rendering for accurate HTML/CSS support

What to Consider

Learning curve for a new API
Testing required to verify output matches expectations
IronPDF uses Chromium, which has its own resource footprint
Some advanced PDFTron features may not have direct equivalents

Conclusion

The PDFTron/Apryse memory leak issue stems from fundamental architectural decisions around native memory management. While workarounds exist, they add complexity and do not fully solve the problem. For development teams spending significant time debugging memory issues in production, evaluating an alternative library with managed memory handling may be more cost-effective than continuing to work around SDK limitations.

Jacob Mellor is CTO at Iron Software, where he leads technical development and built the original IronPDF library. He has over 25 years of experience developing commercial software tools.

References

Possible memory leak with StreamingPDFConversion{:rel="nofollow"} - Apryse Community forum thread documenting streaming conversion memory issues
Possible memory leak in PDFTron .NET SDK{:rel="nofollow"} - .NET SDK memory leak investigation
WebViewer Memory Leaks - GitHub Issue #317{:rel="nofollow"} - Detailed analysis of JavaScript memory leaks
React: PDFTron Memory Leak{:rel="nofollow"} - WebViewer memory issues in React applications
Possible memory leak - iOS{:rel="nofollow"} - iOS-specific memory growth issues
PDFTron WebViewer Out of Memory{:rel="nofollow"} - Large file handling crashes
Running out of memory when merging PDFs{:rel="nofollow"} - Batch merging memory issues
Memory Management - Google Groups{:rel="nofollow"} - iOS PTDocumentController deallocation issue
How to keep memory under control - Java{:rel="nofollow"} - Early reports of batch processing issues

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

DEV Community: IronSoftware

Slow Document Loading in Aspose (Issue Fixed)

The Problem

Error Messages and Symptoms

Who Is Affected

Evidence from the Developer Community

Timeline

Community Reports

Root Cause Analysis

Attempted Workarounds

Workaround 1: Load from FileStream Instead of Path

Workaround 2: Process Documents in Separate AppDomains

Workaround 3: Increase Memory and Accept Slow Loading

Workaround 4: Split Large PDFs Before Processing

A Different Approach: IronPDF

Why IronPDF Handles Large Documents Differently

Code Example

API Reference

Migration Considerations

Licensing

API Differences

What You Gain

What to Consider

Conclusion

References

Winnovative to IronPDF: three steps and you're done

Why Migrate (Without Drama)

Comparison Table

Migration Complexity Assessment

Effort by Feature

Decision Matrix

Before You Start

Prerequisites

Find All Winnovative References

Uninstall / Install

Quick Start Migration (3 Steps)

Step 1 — License Configuration

Step 2 — Namespace Swap

Step 3 — Basic HTML to PDF

Benchmark Reference Patterns

Single Render Timing

Concurrent Throughput

Memory Profile

API Mapping Tables

Namespace Mapping

Core Class Mapping

Document Loading Methods

Page Operations

Merge / Split Operations

Four Complete Before/After Migrations

1. HTML String to PDF

2. Merge PDFs

3. Watermark

4. Password Protection

Critical Migration Notes

Verify API Names Before Any Code Removal

Rendering Engine Difference

ConvertHtmlString Return Type

Page Indexing

Performance Considerations

Parallel Generation

Disposal Pattern

Migration Checklist

Pre-Migration

Code Migration

Testing

Post-Migration

One Last Thing

# SelectPdf Slow Build Times and Conversion Performance (Issue Fixed)

The Problem

Error Messages and Symptoms

Who Is Affected

Evidence from the Developer Community

Timeline

Community Reports

Package Size Analysis

Root Cause Analysis

Attempted Workarounds

Workaround 1: Disable Unnecessary Features

Workaround 2: Switch to Blink Rendering Engine

`ConvertHtmlString` Return Type