HTML to PDF C# in .NET 10: A Technical Guide for .NET Developers

Notes:

• Use this pattern for enterprise applications, large-scale PDF generation, or when rendering complex HTML templates.
• Supports embedded CSS, JavaScript rendering, and custom headers.
• Logging ensures failures during HTML conversion or PDF generation are captured for diagnostics.
• All rendering options, including the JavaScript render delay, are set once in the constructor. When the class is registered as a singleton, every request shares the same renderer, so changing its options inside a request would also change them for requests that are rendering at the same time.
• Timeout on RenderingOptions is measured in seconds. A render that exceeds it fails instead of holding the request open.
• GenerateFromUrlAsync accepts only HTTPS addresses on an allow-list. Without that check, a caller could submit an internal address and the browser engine would request it from inside the network, which is a server-side request forgery (SSRF) risk.

Using this code, for example, we were able to convert this URL (https://en.wikipedia.org/wiki/Main_Page) to PDF format while maintaining the original structure and styling:

Pattern 2: Dependency Injection Configuration

// Program.cs (.NET 6+)
builder.Services.AddSingleton<IPdfGenerator, ProductionPdfGenerator>();

// Usage in controller
[ApiController]
[Route("api/[controller]")]
public class PdfController : ControllerBase
{
    private readonly IPdfGenerator _pdfGenerator;

    public PdfController(IPdfGenerator pdfGenerator)
    {
        _pdfGenerator = pdfGenerator;
    }

    [HttpPost("generate")]
    public async Task<IActionResult> GeneratePdf([FromBody] string html)
    {
        // Generate PDF from HTML string or template
        var pdfData = await _pdfGenerator.GenerateFromHtmlAsync(html);

        // Return PDF file as response
        return File(pdfData, "application/pdf", "document.pdf");
    }
}

Notes:

• Integrates PDF generation into ASP.NET Core applications via dependency injection.
• Promotes clean, testable code and centralized rendering logic.
• Ideal for rendering entire web pages, HTML snippets, or complex templates from existing HTML content.
• Eight concurrent calls through one shared ProductionPdfGenerator instance completed successfully with IronPDF v2026.10.3 on .NET 10.

Pattern 3 (Bookmarks and Table of Contents for Long Reports)

IronPDF can generate hierarchical PDF bookmarks directly from HTML headings, which makes lengthy reports, documentation and technical manuals easier to navigate. Automatic heading bookmarks were added in v2026.5.2. Table of contents generation existed before 2026, and v2026.10.1 added a configurable title (TableOfContentsTitle) and an optional title entry in the list (TableOfContentsIncludesTitleEntry) through ChromePdfRenderOptions.

using IronPdf;

var renderer = new ChromePdfRenderer();
renderer.RenderingOptions.AutoBookmarksFromHeadings = true;
renderer.RenderingOptions.AutoBookmarkMaxHeadingLevel = 3;
renderer.RenderingOptions.TableOfContents = TableOfContentsTypes.WithPageNumbers;
renderer.RenderingOptions.TableOfContentsTitle = "Contents";
renderer.RenderingOptions.CssPageRulePolicy = CssPageRulePolicy.RenderingOptionsWin;

// reportHtml contains <div id="ironpdf-toc"></div> where the table of contents should appear
var pdf = await renderer.RenderHtmlAsPdfAsync(reportHtml);

• The table of contents is inserted where the HTML contains an element with the ID ironpdf-toc.
• AutoBookmarkMaxHeadingLevel = 3 limits bookmarks to h1 through h3 and nests each level under the one above it. Every bookmark in an 11-page test report pointed to the page on which its heading was rendered.
• By default, IronPDF locates headings by searching the rendered text. IronPDF's API documentation describes this mode as fragile when headings break across pages or repeat, and recommends setting AutoBookmarkCssSelectors (for example, new[] { "h1", "h2", "h3" }) for production documents.
• CssPageRulePolicy is explained in the next section.

Page Layout Control for HTML Templates

IronPDF has expanded its HTML rendering controls with configurable CSS @page behavior, header and footer overlap detection, custom hyphenation and fixes for responsive layouts. These changes make page layout more predictable when complex HTML templates are converted to PDF.

IronPDF renders HTML headers and footers in a separate pass and places them in the page margin. When a template declares its own @page { margin: ... } rule, the body margins and the header band can disagree. CssPageRulePolicy.RenderingOptionsWin replaces the template's @page margins with the margins set in RenderingOptions, and CssPageRulePolicy.CssPageWin copies the template's margins into the rendering options instead. The default value leaves @page rules unchanged.

For headers and footers added to an existing PDF, AddHtmlHeaders and AddHtmlFooters accept a ContentOverlapBehavior value (Ignore, Warn or Throw) that reports the pages where the new header or footer would cover existing text or images.

IronPDF bundles its own Chromium build, version 109, rather than using the browser installed on the server. Version 2026.10.3 applied :has(), container queries, @layer and aspect-ratio, but not CSS nesting or color-mix(). Templates that rely on CSS features introduced after Chrome 109 should be tested before deployment.

Performance Benchmarks

Performance is critical for HTML to PDF conversion, especially in high-volume or large-scale PDF generation scenarios. This section covers rendering reliability, output size and deployment complexity.

The original version of this guide included memory and timing figures for IronPDF, PuppeteerSharp, HtmlRenderer.PdfSharp and DinkToPdf. They were removed in this update because the test method was not published and the results could not be reproduced.

Rendering Reliability Updates in 2026

IronPDF's 2026 releases introduced improvements to browser-tab reuse, rendering efficiency, timeout handling and concurrent PDF processing. According to the changelog, these updates address unexpected browser-process crashes, queue deadlocks and rendering failures in high-volume HTML-to-PDF workloads and on servers with limited CPU.

• April 2026 (v2026.4.1) Fewer internal render calls and reuse of browser tabs to reduce startup overhead.
• May 2026 (v2026.5.2) Improved tab pool stability under concurrent rendering and a fix for intermittent crashes during process teardown.
• June 2026 (v2026.6.1) A fix for IronPdfEngine queue deadlocks under concurrent load.
• July 2026 (v2026.7.2) Detection of stalled renders with clearer timeout errors, and fixes for orphaned browser processes and crashes under heavy load or constrained CPU.
• September and October 2026 (v2026.9.2, v2026.10.1) Fixes for intermittent crashes when PDF documents are accessed or disposed concurrently.

These items are fixes reported in the changelog, not measured performance gains. Teams that need throughput figures should benchmark their own templates and control the following conditions.

• Use the same HTML input, page count and assets for every library.
• Record the library version, .NET version, operating system and hardware.
• Report the first renders, which include browser start-up, separately from warm renders.
• Measure the peak memory of the whole process, including any browser child processes.
• Run at the concurrency level expected in production.

PDF Output Compression and Linearization

IronPDF also provides PDF output optimization through in-memory compression and linearization APIs, which are useful for document-heavy web applications and cloud workflows where writing temporary files is restricted.

byte[] compressed = pdf.CompressPdfToBytes(null, false, CompressionMode.FastMemory);
byte[] linearized = pdf.LinearizePdfToBytes(LinearizationMode.InMemory);

CompressionMode.FastMemory performs no disk I/O but does not resample images. On a text-heavy 11-page test report, it reduced the file from 77,116 bytes to 64,339 bytes. Image downsampling and JPEG quality settings require AdvancedCompressionOptions, which is passed to CompressAndSaveAs and writes the result to a file. Linearized output allows a browser to display the first page before the whole file has downloaded. The second argument of CompressPdfToBytes removes the structure tree when set to true, which also removes the accessibility tags described under Recommendations.

Deployment Complexity

Takeaways:

• For production HTML to PDF conversion, libraries with low memory usage, fast generation times, and thread safety are preferred.
• Deployment simplicity is equally important: IronPDF scores best for quick integration in .NET Core, .NET 6+, and .NET 10 projects.

Docker, Linux and Cloud Deployment

The 2026 releases add AMD64 and ARM64 support for the IronPdfEngine Docker image, compatibility with current Linux distributions and fixes for Azure App Service.

The 60% reduction applies to the IronPdfEngine Docker image, not to the IronPdf NuGet package. The full IronPdf package bundles Chromium binaries for each supported platform, and a .NET 10 console application built on Windows with v2026.10.3 produced 603 MB of build output. Applications that need a smaller footprint can install IronPdf.Slim and send rendering to an IronPdfEngine container, as IronPDF's documentation recommends. The client package and the container must use the same version.

Security Considerations

Generating PDF documents from HTML carries potential security risks, especially when using abandoned libraries like wkhtmltopdf.

Key Vulnerabilities

• Local file disclosure (CVE-2020-21365, directory traversal) via crafted HTML.
• SSRF attacks (CVE-2022-35583) through injected iframes that point at internal addresses.
• XSS vectors from unsafe HTML or JavaScript.
• Unpatched flaws in discontinued libraries.

Best Practices

• Sanitize HTML input to remove unsafe scripts.
• Disable JavaScript unless necessary.
• Use sandboxed renderers with timeouts to prevent infinite loops.
• Avoid Process.Start() methods and abandoned libraries.
• Validate external resources for security compliance. HTML sanitization removes scripts, but it does not stop the renderer from requesting the image, stylesheet and font URLs that remain in the markup. Restrict those URLs to approved hosts, validate any URL passed to RenderUrlAsPdf, and block outbound traffic from the PDF service to internal address ranges.

The following example uses the open-source HtmlSanitizer package (namespace Ganss.Xss), which is installed alongside IronPdf with dotnet add package HtmlSanitizer.

using Ganss.Xss;
using IronPdf;

public class SecurePdfGenerator
{
    private static readonly HashSet<string> AllowedResourceHosts =
        new(StringComparer.OrdinalIgnoreCase) { "cdn.example.com" };

    public async Task<byte[]> GenerateSecurePdf(string untrustedHtml)
    {
        var sanitizer = new HtmlSanitizer();

        // Drop any resource URL that is not HTTPS on an approved host (SSRF protection)
        sanitizer.FilterUrl += (sender, e) =>
        {
            if (!Uri.TryCreate(e.OriginalUrl, UriKind.Absolute, out var uri)
                || uri.Scheme != Uri.UriSchemeHttps
                || !AllowedResourceHosts.Contains(uri.Host))
            {
                e.SanitizedUrl = null;
            }
        };

        var sanitizedHtml = sanitizer.Sanitize(untrustedHtml);

        var renderer = new ChromePdfRenderer
        {
            RenderingOptions =
            {
                EnableJavaScript = false,
                Timeout = 30,
                PaperSize = IronPdf.Rendering.PdfPaperSize.A4
            }
        };

        var pdf = await renderer.RenderHtmlAsPdfAsync(sanitizedHtml);
        return pdf.BinaryData;
    }
}

• HtmlSanitizer removes scripts, iframes, <link> elements, event handlers and javascript: links.
• The FilterUrl handler removes every resource URL that is not HTTPS on an approved host. It removed an image that pointed at a cloud metadata address (169.254.169.254) and a CSS background URL that pointed at a private IP address, and it kept an image from the approved CDN.
• Timeout is measured in seconds, so 30 stops a render after 30 seconds.
• RenderHtmlAsPdfAsync returns a PdfDocument, so the method returns its BinaryData to match the byte[] signature.
• Application-level filtering should be combined with network controls, because the DNS records of an approved host can change after the URL has been checked.

Keeping the PDF Library Patched

Version 2026.10.3 updates its SixLabors.ImageSharp dependency to resolve CVE-2026-106110 through CVE-2026-106118 on .NET 6 and later (ImageSharp 4.1.3 on .NET 8 and later, 3.2.0 on .NET 6 and 7). Earlier 2026 releases strengthened the IronPdfEngine Docker image, where v2026.4.1 removed unnecessary packages and resolved 4 high-severity CVEs and more than 1,400 other security scan findings. Version 2026.8.1 added configurable AES-128 and AES-256 PDF encryption through PdfSecuritySettings.EncryptionType.

Two further points apply to most projects.

• The ImageSharp fix arrives as a transitive dependency. Projects that target .NET 8 audit only direct dependencies by default, so transitive advisories do not appear in the build output. Adding <NuGetAuditMode>all</NuGetAuditMode> to the project file, or running dotnet list package --vulnerable --include-transitive, reports them.
• The default encryption algorithm remains 128-bit RC4 for backward compatibility, and IronPDF's API documentation describes RC4 as cryptographically weak. AES should be set explicitly when a document is password-protected.

pdf.SecuritySettings.EncryptionType = IronPdf.Security.PdfEncryptionType.Aes_256;
pdf.SecuritySettings.UserPassword = "open-password";
pdf.SecuritySettings.OwnerPassword = "owner-password";

A document saved with these settings by v2026.10.3 used AES-256 encryption (security handler revision 6) and could not be opened without the user password.

Recommendations

Selecting the right HTML to PDF library in C# depends on your project's scope, scale, and security requirements. Below are tailored recommendations for different scenarios.

1. For Enterprise Applications

Primary Recommendation: IronPDF

• Fully cross-platform and supports .NET Framework, .NET Core, and .NET 10.
• Consistent monthly updates with security patches, most recently the ImageSharp vulnerability fixes in v2026.10.3.
• Supports PDF/A archival formats and the PDF/UA-1 and PDF/UA-2 accessibility standards, essential for archival, compliance and public-sector reports.
• Handles complex templates, CSS styling, and JavaScript execution.
• Provides professional support and extensive documentation, reducing developer overhead.

Accessible PDF output. PDF/UA-2 (ISO 14289-2) support was added in v2025.12.2. During 2026, releases improved the tagging of headings, paragraphs and form fields, added PdfDocument.SetImageAltText for setting alternative text on images in existing PDFs (v2026.9.2), and preserved accessibility metadata when PDFs are merged or pages are copied (v2026.9.2 and v2026.10.1). RenderHtmlAsPdfUA renders HTML directly to PDF/UA, and SaveAsPdfUA accepts a PdfUAVersions value to select PDF/UA-1 or PDF/UA-2.

Accessible output still depends on the source document. The HTML needs a logical heading order, alternative text for images, labelled form fields and a declared language, and the resulting PDF should be checked with a validator such as PAC or veraPDF before publication.

Use Case: Generating large-scale PDF files, entire web pages, or creating PDF files from HTML templates.

2. For Proof of Concepts or Testing

Recommended Library: PuppeteerSharp

• Excellent Chrome-based rendering, supporting modern HTML, CSS, and JavaScript.
• Good for dynamic web content or interactive HTML pages.
• Be mindful of memory usage and deployment complexity in serverless environments.

Use Case: Quick prototypes or experimental PDF generation.

3. For Simple Documents or Lightweight Tasks

Recommended Library: HtmlRenderer.PdfSharp

• Lightweight and easy to integrate.
• Supports basic HTML snippets and CSS2 styling.
• Not suitable for complex templates or large-scale PDF generation.

Use Case: Single-page HTML documents, simple reports, or internal tools with minimal CSS and JavaScript requirements.

4. Libraries to Avoid in Production

• All wkhtmltopdf-based libraries (DinkToPdf, Rotativa, NReco.PdfGenerator): Unpatched security vulnerabilities.
• Process.Start() approaches: Injection risks.
• Abandoned projects: No security updates, no modern web support.

5. Migration Strategy for Deprecated Libraries

// Legacy code using wkhtmltopdf-based library
public byte[] OldMethod(string html)
{
    var converter = new SomeWkHtmlToPdfWrapper();
    return converter.Convert(html);
}

// Migration to supported library
public async Task<byte[]> NewMethod(string html)
{
    var renderer = new ChromePdfRenderer();
    var pdf = await renderer.RenderHtmlAsPdfAsync(html);
    return pdf.BinaryData;
}

Conclusion

C# HTML to PDF conversion in 2026 requires careful library selection to balance performance, security, and maintainability. While many libraries exist, only a few meet modern .NET requirements for reliable PDF generation.

Key Takeaways

1. Choose actively maintained libraries Monthly updates, security patches, and .NET 10 support are essential. IronPDF is the most reliable for production environments. Pin the package version and review the changelog before each upgrade.
2. Avoid deprecated or abandoned solutions wkhtmltopdf-based libraries have security flaws and lack modern CSS/JS support. Process.Start() methods carry injection risks.
3. Match the library to your use case Enterprise PDF generation: IronPDF. Prototypes / PoCs: PuppeteerSharp. Simple documents: HtmlRenderer.PdfSharp.
4. Support complex HTML content Ensure libraries handle CSS3, JavaScript, page breaks, custom headers, and HTML templates. For long documents, also check bookmark and table of contents generation, and test any CSS feature that is newer than the library's bundled browser engine.
5. Invest in maintainable workflows Dependency injection and well-maintained renderers simplify scalable PDF generation. Migrating from deprecated libraries reduces long-term security and maintenance risks.
6. Plan for accessible output PDF/UA support, image alternative text and preserved tags matter for public-sector and regulated documents, but they still require well-structured HTML and validation.

Final Thought:

Choosing the right library is more than PDF quality, it ensures security, cross-platform support, and maintainability. For generating PDF documents from HTML pages or templates, a commercial, actively maintained solution like IronPDF is the most reliable approach. Try IronPDF's free trial to explore its powerful features for yourself, and check out its extensive documentation to learn more.