How to Convert HTML to PDF in C# for .NET 10 Using IronPDF

iTextSharp – The “Free” Library That Really Isn’t

Back in 2009, iTextSharp was promoted as a free and open-source PDF library. At the time, it was distributed under the LGPL license, which seemed like a reasonable choice for developers. However, by 2012, the licensing terms changed to AGPL. Under the AGPL, developers faced a difficult choice: either open-source their entire application or pay for a commercial license.

Fast forward to 2025, and a commercial iText license can cost thousands of dollars — often around $2,500 per server. This has created what many developers call the “AGPL trap”: use iTextSharp and either release your full source code or pay a significant licensing fee.

On top of the licensing issues, iText doesn’t provide native HTML-to-PDF conversion out of the box. There is no simple RenderHtml(html) method. Instead, developers have to rely on additional components such as XMLWorker or the pdfHTML add-on, which bring their own dependencies and further licensing complexity.

This combination of restrictive licensing and missing built-in HTML-to-PDF support is why many teams avoid iTextSharp today.

iTextSharp isn’t alone. QuestPDF was another trap: heavily promoted online as “the best C# PDF library,” but it doesn’t support HTML to PDF at all. Developers spent days trying to force it into workflows it simply wasn’t designed for.

QuestPDF – The Library That Doesn’t Do What You Think

QuestPDF is often promoted online, especially in Reddit communities, as one of the best PDF libraries for C#. However, there’s an important limitation that isn’t always obvious: QuestPDF has no HTML-to-PDF support at all.

Instead of rendering HTML, QuestPDF requires developers to construct documents programmatically using its fluent API. For example, you define pages, containers, and text blocks directly in C# code. While powerful for certain use cases, it feels more like manually laying out documents — almost like building PDFs “the hard way” rather than simply converting existing HTML.

Licensing is another consideration. The so-called “community license” is AGPL, which forces you to either open-source your entire project or purchase a commercial license. Commercial pricing ranges roughly from $699 to $7,999, which can feel steep for a library that doesn’t include HTML-to-PDF rendering out of the box.

Because of these limitations, QuestPDF may not be the right solution for developers specifically looking for simple and reliable HTML-to-PDF conversion in .NET.

The wkhtmltopdf Disaster (2016-2024)

Using WkHtmlToPdf in production was notoriously painful. Every wrapper around it seemed to follow the same frustrating pattern:

1. Copy a mysterious binary onto the server.

2. Hope the right native dependencies were installed.

3. Watch it crash unpredictably in production.

Even when you had a wrapper in place, reliability was far from guaranteed. Developers frequently encountered errors such as:

• “Unable to load DLL 'wkhtmltox'”

• “Access violation at address 0x00000000”

• “The application has stopped working”

• “Qt: Could not initialize OLE (error 80010106)”

These failures often required manual intervention. In some cases, teams even resorted to restarting the application pool just to get the process working again — a fragile and unsustainable solution.

This instability, combined with the awkward deployment process, made WkHtmlToPdf a risky choice for serious production workloads.

In 2024, wkhtmltopdf was finally abandoned. Every C# PDF library built on it became instant technical debt:

• TuesPechkin - Last updated 2015, multi-threading claims were fiction

• Rotativa - MVC-only, still shipping dead binaries in 2025

• DinkToPdf - The ".NET Core compatible" fork that wasn't really

• Haukcode.DinkToPdf - A variant of a dead variant

• NReco.PdfGenerator - Charging $150+ for wrapping abandoned software

• OpenHtmlToPdf - Name implies it's different, it's not

Developers attempting HTML to PDF C# using wkhtmltopdf wrappers had to constantly manage file permissions, relative URLs, and binary dependencies. Generating PDF documents for entire web pages was unstable, and page breaks inside HTML elements were unpredictable.

The "Just Use Chrome" Nightmare

Then came the browser automation crowd. "Just use Puppeteer!" they said. Even though PuppeteerSharp and Playwright can technically generate PDFs, they aren’t real C# PDF libraries. They require heavy browser binaries, complex deployment, and lack compliance features like PDF/A or PDF/UA.

Here's what that actually looked like:

// PuppeteerSharp - The "Simple" Solution That Wasn't
public class PuppeteerNightmare
{
    private Browser _browser;

    public async Task Initialize()
    {
        // Step 1: Download 300MB of Chrome
        await new BrowserFetcher().DownloadAsync();
        // Customer: "Why is your app 300MB?"
        // Us: "Uh... for PDFs?"

        // Step 2: Launch Chrome with magic arguments nobody understands
        _browser = await Puppeteer.LaunchAsync(new LaunchOptions
        {
            Headless = true,
            Args = new[] 
            { 
                "--no-sandbox",
                "--disable-setuid-sandbox",
                "--disable-dev-shm-usage",
                "--disable-gpu",
                "--no-first-run",
                "--no-zygote",
                "--single-process"
            }
        });
    }

    public async Task<byte[]> GeneratePdf(string html)
    {
        // This works great until:
        // 1. Chrome auto-updates and breaks your args
        // 2. You need to generate 100 PDFs simultaneously
        // 3. You deploy to Azure Functions (spoiler: it won't work)
        // 4. A memory leak eats 5GB of RAM

        var page = await _browser.NewPageAsync();
        await page.SetContentAsync(html);

        // Wait for... something? Nobody knows the right value
        await Task.Delay(1000); 

        return await page.PdfDataAsync();
    }
}

// PuppeteerSharp - The "Simple" Solution That Wasn't
public class PuppeteerNightmare
{
    private Browser _browser;

    public async Task Initialize()
    {
        // Step 1: Download 300MB of Chrome
        await new BrowserFetcher().DownloadAsync();
        // Customer: "Why is your app 300MB?"
        // Us: "Uh... for PDFs?"

        // Step 2: Launch Chrome with magic arguments nobody understands
        _browser = await Puppeteer.LaunchAsync(new LaunchOptions
        {
            Headless = true,
            Args = new[] 
            { 
                "--no-sandbox",
                "--disable-setuid-sandbox",
                "--disable-dev-shm-usage",
                "--disable-gpu",
                "--no-first-run",
                "--no-zygote",
                "--single-process"
            }
        });
    }

    public async Task<byte[]> GeneratePdf(string html)
    {
        // This works great until:
        // 1. Chrome auto-updates and breaks your args
        // 2. You need to generate 100 PDFs simultaneously
        // 3. You deploy to Azure Functions (spoiler: it won't work)
        // 4. A memory leak eats 5GB of RAM

        var page = await _browser.NewPageAsync();
        await page.SetContentAsync(html);

        // Wait for... something? Nobody knows the right value
        await Task.Delay(1000); 

        return await page.PdfDataAsync();
    }
}

IRON VB CONVERTER ERROR developers@ironsoftware.com

In addition to the heavy Chrome dependency, developers faced challenges with dynamic content, CSS support, and print CSS for HTML to PDF conversion. Automating web pages in this way often resulted in incorrect page breaks, large memory footprints, and unpredictable PDF page sizes.

GemBox.Document – The Paragraph Counter

GemBox.Document advertises itself as free, but only for up to 20 paragraphs. The catch is that every table cell also counts as a paragraph. So, if you create something as simple as a 5×5 table, that’s already 25 paragraphs — and you’ll be required to pay for a license.

The full version of GemBox.Document costs about $680, and that’s just for basic HTML-to-PDF conversion. Because of the strict free-tier limitation and the cost of the full license, scaling projects with this library quickly becomes difficult.

SelectPdf – The “Cross-Platform” Lie

SelectPdf is often presented as a cross-platform HTML-to-PDF solution, but in reality, it only works on Windows. Developers who purchase a license — which starts at $499 — quickly discover that the library isn’t compatible with Linux or macOS.

The free version is also heavily restricted. It allows you to generate only up to five pages; starting with page six, a large “BUY A LICENSE” watermark is stamped across the output.

These limitations make SelectPdf a risky choice for developers who expect true cross-platform support or want to test the library without immediately running into paywalls.

EO.Pdf – The Legacy Baggage

EO.Pdf comes with a steep price tag of $799 for a library that has carried significant baggage over the years. Originally, it depended on Internet Explorer as its rendering engine. More recently, it switched to using Chrome, but that comes with a large 126 MB footprint. Despite claims of cross-platform support, EO.Pdf remains largely Windows-centric.

Technically, the HtmlToPdf.ConvertHtml(html, pdfStream) method works, but given the cost and limitations, EO.Pdf isn’t considered a cost-effective solution for handling modern HTML features.

HiQPdf – The Three Page Wonder

HiQPdf promotes itself as having a free version, but the reality is quite limiting: you can only generate up to three pages. As soon as you reach page four, a large watermark is applied across the document.

If you want to remove the limitation, you’ll need to purchase a commercial license, which starts at around $595.

In practice, this makes the free version useful only for very small documents. Anything larger quickly runs into the page limit, pushing developers toward a paid upgrade.

Spire.PDF – When Images Aren’t Really PDFs

Spire.PDF advertises HTML-to-PDF conversion, but in practice it often “converts” HTML by simply taking a screenshot. The result is a large PDF — sometimes 10 MB — where the text is not selectable. Users frequently ask, “Why can’t I search the PDF?” The answer is simple: because it’s effectively just an image embedded in the PDF, not real text.

The method LoadFromHTML takes several boolean parameters, but their purpose is unclear, and the official documentation provides little guidance. In many cases, the only way to get clarification is to contact sales.

This approach makes Spire.PDF problematic for anyone who needs searchable, copyable, or properly structured PDFs.

ABCpdf – The Licensing Maze

ABCpdf advertises a “free license,” but in reality, it must be registered, is time-limited, and adds watermarks. The full version relies on either the Gecko engine (an outdated version of Firefox) or Trident (Internet Explorer). Remarkably, even in 2025, Internet Explorer is still offered as an option for rendering.

When using ABCpdf, adding HTML content means you are constrained to these older rendering engines. For example, calling AddImageHtml(html) will render using either IE or the outdated Firefox engine, depending on your choice.

ExpertPdf – The Expert at Being Expensive

ExpertPdf comes with a hefty price tag, ranging from $550 to $1,200. And what do you get for that cost? Essentially a wrapper around an old version of Chrome, along with documentation that hasn’t been updated since 2018.

Winnovative – Innovation Stopped in 2016

Winnovative’s HTML-to-PDF converter is still based on a WebKit engine from 2016. Despite its name, the library hasn’t kept up with modern web standards. Pricing ranges from $750 to $1,600 for technology that dates back to when Obama was president.

The converter does not support CSS Grid or modern JavaScript features. While it can produce PDFs, it’s clearly outdated compared to current HTML-to-PDF solutions.

PDFmyURL – Not Even a Library

PDFmyURL is not a true C# library; it’s essentially just an API wrapper. When you use it, you’re paying to process your documents on someone else’s server, which can be a concern if your documents are sensitive. The minimum cost is $39 per month.

Functionally, using PDFmyURL in C# means making HTTP requests to their web service — you’re not working with a local library. For example, you send a URL to their API endpoint and receive a PDF in response. While it can generate PDFs, it isn’t a standalone C# PDF library, but rather a web service that requires network access.

GrabzIt – Screenshots, Not PDFs

GrabzIt was originally designed for taking website screenshots. PDF generation is more of an afterthought rather than a core feature. The service charges per capture, and it does not provide a true C# HTML-to-PDF solution.

PDF Duo .NET – The Mystery Library

PDF Duo .NET claims to work without any extra DLLs. In reality, it’s largely unknown and unused by the developer community. Documentation is virtually nonexistent, and the support forum has only a handful of posts, all dating back to 2019.

Even when these libraries technically worked, they introduced practical limitations:

• Most free versions are heavily constrained (page limits, watermarking, restricted features).

• Licensing often hides extra costs or restrictive clauses.

• Engines are outdated (IE, old Chrome, WebKit 2016) and fail with modern HTML/CSS.

• Cross-platform support is either misleading or incomplete.

• Deployment at scale requires workarounds and extra debugging.

In short, commercial libraries often look appealing on paper but create technical debt in production, forcing teams to either spend significant money or eventually switch to a library like IronPDF that "just works."

HtmlRenderer.PdfSharp – Welcome to 2005

HtmlRenderer.PdfSharp supports only very old CSS — basically what existed when George W. Bush was president. Modern CSS features like flexbox, grid layouts, or border-radius are not supported. Any attempt to use them will fail.

To lay out content, you must rely on old-school table-based layouts, similar to how web pages were built in 1999. Modern HTML frameworks or libraries, such as Bootstrap, will not work, and JavaScript is completely unsupported.

If you try to render modern HTML, the library may crash or produce incorrect results, making it unsuitable for contemporary web-to-PDF conversion needs.

PdfSharp– The Library Everyone Confuses

PdfSharp is a solid library for creating PDFs programmatically. However, it does not convert HTML to PDF. If you want HTML-to-PDF functionality, you need to use an additional library like HtmlRenderer.PdfSharp. The problem is that HtmlRenderer.PdfSharp hasn’t been updated since 2019, so it may be outdated or unreliable.

With PdfSharp, you’re primarily drawing shapes, text, and graphics manually. For example, you can create a new PDF document, add pages, and draw strings or shapes on them, but this is very different from rendering HTML content into a PDF.

HTMLDOC – From the Dot-Com Era

HTMLDOC is GPL-licensed, which makes it “viral” in terms of licensing. The last meaningful update to the library was in 2001, so it hasn’t kept up with modern standards. It doesn’t handle CSS properly, and it only works via the command line. The documentation even still references Netscape.

To generate a PDF, you run a command like htmldoc --webpage -f output.pdf input.html. In other words, using HTMLDOC today is very much a throwback to the late 1990s.

While these “free” libraries might look appealing for html to pdf conversion in small projects, they often fail when handling:

• Full web content: Dynamic HTML pages, modern CSS, JavaScript snippets.

• PDF compliance: No PDF/A, PDF/UA, or accessibility support.

• File permissions and form fields: Limited or nonexistent.

• Cross-platform deployment: Some only work on Windows or rely on Internet Explorer engines.

Trying to render entire web pages with these tools often results in partial HTML content, broken layouts, or PDFs that are essentially screenshots rather than searchable, structured documents. Developers quickly realize that “free” comes with the hidden cost of hours wasted debugging, manual workarounds, and inconsistent outputs—all for a library that was supposed to make their life easier.

IronPDF was built specifically to solve these problems, offering robust methods to generate PDF documents from HTML files, strings, or dynamic web content, with proper CSS support, page break handling, and seamless integration into .NET applications.

Gotenberg – The Microservice Nightmare

Gotenberg promotes itself as easy to use with the tagline: “Just run a Docker container!” But in reality, using it in production often requires much more: Docker, Kubernetes, service discovery, load balancing, and network policies.

What started as a simple C# HTML-to-PDF task can quickly turn into a distributed systems problem. You need to ensure Gotenberg is running, that the network is working correctly, and that Docker containers remain stable. The added operational complexity makes it a heavy dependency for what is supposed to be a straightforward PDF conversion.

WebView2 Control – The Windows-Only Trap

Microsoft’s WebView2 control initially sounds appealing, but it comes with significant limitations: it only works on Windows, requires the Edge WebView2 Runtime, doesn’t function on servers without a desktop environment, and can have security sandbox issues.

Libraries like Westwind.WebView.HtmlToPdf that wrap WebView2 inherit the same limitations, along with additional dependencies.

Chrome Headless – The Process.Start Horror

Some developers actually try to generate PDFs in production by running Chrome in headless mode using Process.Start("chrome", "--headless --print-to-pdf").

This approach comes with several serious problems:

• Command injection vulnerabilities

• Chrome auto-updates can break everything unexpectedly

• No built-in error handling

• Temporary files scattered across the system

• Requires Chrome to be installed on the server

Overall, relying on direct Process.Start for Chrome headless PDF generation is considered risky and fragile for production environments.

Selenium WebDriver – Testing Tool, Not a PDF Generator

Selenium is designed for testing, not for generating PDFs. Using it for PDF generation is like using a bulldozer to crack an egg.

While you can navigate a browser instance to HTML content using something like ChromeDriver and driver.Navigate().GoToUrl("data:text/html," + html), Selenium cannot generate PDFs directly. To do anything resembling PDF output, you need to use the Chrome DevTools Protocol, which adds complexity and often leads to memory leaks.

The Selenium.WebDriver.ChromeDriver package simply provides the Chrome driver for Selenium — it is not a PDF generation solution.

These experimental projects demonstrate why attempting html to pdf conversion using abandoned or experimental tools is often more trouble than it’s worth:

• Gotenberg: Requires Docker and orchestration for something that should be a simple pdf conversion task. Managing entire web pages and html files becomes a distributed systems problem.

• WebView2: Windows-only, dependent on desktop environments, and not suitable for server-side pdf generation.

• Chrome Headless via Process.Start: Introduces security risks, temp files, and platform dependencies.

• Selenium WebDriver: Designed for browser automation, not creating PDF documents. Developers often waste time trying to treat a testing tool as a pdf converter.

Attempting to render HTML elements, manipulate PDF documents, or generate PDF files with these libraries often results in failed deployments, broken layouts, or unsearchable PDFs. IronPDF was designed to eliminate these headaches, offering robust methods to convert HTML to PDF, handle dynamic content, and provide full CSS support across all platforms.

PeachPDF – Vaporware

PeachPDF is described as “in development for community use,” but in reality, it doesn’t really exist yet. Checking the GitHub repository shows only three commits, with the last one made eight months ago. The PDF library ecosystem already has many established options, and there’s little need for more half-finished projects like this.

Playwright – Microsoft’s Browser Automation

Playwright is essentially Microsoft’s version of Puppeteer. It shares many of the same challenges. For example, it requires browser binaries, which adds significant overhead. Deployment can be complex, and it isn’t really a PDF library — HTML-to-PDF conversion is not its primary focus.

Using Playwright typically involves managing an additional 300MB or more of Chromium browser binaries, which adds further complexity to any project.

Syncfusion PDF Library – The Suite Tax

If you want HTML-to-PDF functionality with Syncfusion, you effectively have to purchase their entire suite of products. The minimum cost is $995 per developer. On Linux, this also adds 147MB of additional files just to get a single feature. In other words, if you only wanted one feature, you end up buying access to 70.

Aspose.PDF – Enterprise Pricing for Everyone

Aspose.PDF starts at $1,199 and can go up to $11,997. For small teams or individual developers, this pricing can be prohibitive. The documentation is extensive but assumes a high level of expertise, making it difficult for newcomers to quickly get started.

Even simple tasks can require navigating a complex API. For example, creating a new document and adding a page involves multiple steps, which can feel unnecessarily complicated compared to more straightforward libraries.

These emerging solutions are often marketed as easy “HTML to PDF C# converters,” but in reality, they require complex setup, manual work, or expensive suite purchases. They promise cross-platform compatibility, robust PDF generation, or full CSS support, but testing in real-world .NET applications shows gaps:

• Browser binaries must be downloaded and managed manually.

• PDF generation fails for dynamic content or modern HTML elements.

• CSS and JavaScript rendering is often incomplete.

• Documentation is minimal or outdated.

Developers who try to adopt these libraries often spend days troubleshooting, only to revert to well-established solutions like IronPDF, which provide robust method calls and handle rendering entire web pages reliably.

Looking for better alternatives? Check our comparison with Aspose.PDF or see why developers switch to IronPDF.

1. It Just Works™

IronPDF provides a straightforward and reliable way to generate PDFs. There are no external binaries to copy, no Chrome installation required, no platform-specific code to worry about, and no extra “prayers” needed for it to work.

Using IronPDF, you simply create a ChromePdfRenderer, pass in your HTML, and get back a PDF. That’s it — it actually works, as expected, without any complex setup or dependencies.

using IronPdf;

public class WhatPdfGenerationShouldBe
{
    public async Task<byte[]> GeneratePdf(string html)
    {
        var renderer = new ChromePdfRenderer();
        var pdf = await renderer.RenderHtmlAsPdfAsync(html);
        return pdf.BinaryData;
    }
}

using IronPdf;

public class WhatPdfGenerationShouldBe
{
    public async Task<byte[]> GeneratePdf(string html)
    {
        var renderer = new ChromePdfRenderer();
        var pdf = await renderer.RenderHtmlAsPdfAsync(html);
        return pdf.BinaryData;
    }
}

IRON VB CONVERTER ERROR developers@ironsoftware.com

With IronPDF, HTML to PDF conversion happens in just a few lines. You can generate PDF files from an HTML files, HTML string, or dynamically rendered web pages without worrying about relative URLs, file permissions, or missing CSS support. Whether you’re rendering entire web pages, HTML snippets, or HTML code with images, it all works reliably.

Need more examples? Check our HTML to PDF conversion tutorial or see real-world code samples.

2. Legal Compliance That Others Can't Match

IronPDF is the only library that fully supports:

• Section 508 (US Accessibility Standards)

• PDF/A (ISO 19005 for archival)

• PDF/UA (ISO 14289 for accessibility)

As a member of the PDF Association, we don't just meet standards - we exceed them. This is why government agencies trust us:

public class ComplianceThatMatters
{
    public async Task<byte[]> GenerateCompliantPdf(string html)
    {
        var renderer = new ChromePdfRenderer();

        // Full Section 508 compliance
        renderer.RenderingOptions.CreatePdfA = true;

        // Better accessibility than Chrome itself
        var pdf = await renderer.RenderHtmlAsPdfAsync(html);

        // Add proper tags for screen readers
        pdf.AddAccessibilityTags();

        // This is why NASA, Tesla, and the US Government use IronPDF
        return pdf.BinaryData;
    }
}

public class ComplianceThatMatters
{
    public async Task<byte[]> GenerateCompliantPdf(string html)
    {
        var renderer = new ChromePdfRenderer();

        // Full Section 508 compliance
        renderer.RenderingOptions.CreatePdfA = true;

        // Better accessibility than Chrome itself
        var pdf = await renderer.RenderHtmlAsPdfAsync(html);

        // Add proper tags for screen readers
        pdf.AddAccessibilityTags();

        // This is why NASA, Tesla, and the US Government use IronPDF
        return pdf.BinaryData;
    }
}

IRON VB CONVERTER ERROR developers@ironsoftware.com

This means PDF documents created from HTML pages meet strict standards for form fields, file permissions, and accessibility — something PDF converter libraries and HTML renderer tools often fail at.

Struggling with other libraries? See direct comparisons:

• IronPDF vs iTextSharp
• IronPDF vs wkhtmltopdf
• IronPDF vs SelectPdf
• IronPDF vs Spire.PDF

This isn't marketing fluff. Puppeteer and Playwright literally cannot generate PDF/A or PDF/UA compliant documents. They use Chrome's print-to-PDF, which lacks these capabilities. When the White House needs accessible PDFs, they don't use free libraries - they use IronPDF.

3. Built for Modern Development

Our high-level API allows developers to generate PDF documents from dynamic content with just a few lines:

public class AiGeneratedExample
{
    public async Task<byte[]> GenerateInvoiceWithAI(Invoice invoice)
    {
        var renderer = new ChromePdfRenderer
        {
            RenderingOptions =
            {
                MarginTop = 25,
                MarginBottom = 25,
                PaperOrientation = PdfPaperOrientation.Portrait,
                EnableJavaScript = true,
                CssMediaType = IronPdf.Rendering.PdfCssMediaType.Print
            }
        };

        var html = GenerateInvoiceHtml(invoice);
        var pdf = await renderer.RenderHtmlAsPdfAsync(html);

        // Add metadata
        pdf.MetaData.Author = "AI-Generated";
        pdf.MetaData.Title = $"Invoice #{invoice.Number}";

        return pdf.BinaryData;
    }
}

public class AiGeneratedExample
{
    public async Task<byte[]> GenerateInvoiceWithAI(Invoice invoice)
    {
        var renderer = new ChromePdfRenderer
        {
            RenderingOptions =
            {
                MarginTop = 25,
                MarginBottom = 25,
                PaperOrientation = PdfPaperOrientation.Portrait,
                EnableJavaScript = true,
                CssMediaType = IronPdf.Rendering.PdfCssMediaType.Print
            }
        };

        var html = GenerateInvoiceHtml(invoice);
        var pdf = await renderer.RenderHtmlAsPdfAsync(html);

        // Add metadata
        pdf.MetaData.Author = "AI-Generated";
        pdf.MetaData.Title = $"Invoice #{invoice.Number}";

        return pdf.BinaryData;
    }
}

IRON VB CONVERTER ERROR developers@ironsoftware.com

Developers can easily convert HTML into PDF format, rendering web pages with CSS support, page break inside/outside, and print CSS options. The API handles relative URLs, image files, and HTML elements, giving full control over PDF page size, custom headers, and file permissions.

4. Real OCR Integration

IronPDF supports manipulating PDF documents with OCR capabilities:

public class BeyondHtmlToPdf
{
    public async Task<string> ProcessScannedDocument(byte[] scannedPdf)
    {
        var pdf = PdfDocument.FromBytes(scannedPdf);

        // OCR the content
        var text = pdf.ExtractTextFromPage(0);

        if (string.IsNullOrWhiteSpace(text))
        {
            text = await pdf.ApplyOcr();
        }

        var structuredData = await ExtractWithAI(text);
        var combined = PdfDocument.Merge(pdf, otherPdf);

        combined.SignWithCertificate(certificate);
        return structuredData;
    }

    private async Task<string> ExtractWithAI(string text)
    {
        return await OpenAIService.Extract(text);
    }
}

public class BeyondHtmlToPdf
{
    public async Task<string> ProcessScannedDocument(byte[] scannedPdf)
    {
        var pdf = PdfDocument.FromBytes(scannedPdf);

        // OCR the content
        var text = pdf.ExtractTextFromPage(0);

        if (string.IsNullOrWhiteSpace(text))
        {
            text = await pdf.ApplyOcr();
        }

        var structuredData = await ExtractWithAI(text);
        var combined = PdfDocument.Merge(pdf, otherPdf);

        combined.SignWithCertificate(certificate);
        return structuredData;
    }

    private async Task<string> ExtractWithAI(string text)
    {
        return await OpenAIService.Extract(text);
    }
}

IRON VB CONVERTER ERROR developers@ironsoftware.com

Unlike other PDF converter tools, IronPDF allows you to generate PDF documents from scanned image files or HTML content and extract structured data automatically, streamlining PDF generation in complex .NET applications.

Learn more: Merge PDFs | Digital signatures | Extract text from PDFs

5. Deployment That Actually Works

IronPDF was designed for cross-platform HTML to PDF conversion in modern .NET applications. You can generate PDF documents from HTML content without worrying about platform dependencies, binary installations, or server configurations:

• Windows Server
• Linux distributions (Ubuntu, Debian, Alpine)
• macOS
• Docker containers
• Azure Functions
• AWS Lambda
• Kubernetes

It also supports multiple .NET targets:

• .NET Framework 4.0 and above
• .NET Core 2.0 and above
• .NET 5, 6, 7, 8, 9, and 10

Using the library is straightforward. You can simply create a renderer, call RenderHtmlAsPdfAsync with your HTML content, and get a PDF. In short: it just works everywhere.

See deployment guides: Docker deployment | Azure Functions | AWS Lambda | Linux installation

The Technical Advantages We Built In

public class ModernWebStandards
{
    public async Task<byte[]> GenerateModernPdf()
    {
        var renderer = new ChromePdfRenderer();

        var html = @"
        <style>
            .container {
                display: grid;
                grid-template-columns: repeat(auto-fit, minmax(250px, 1fr));
                gap: 2rem;
            }
            .card {
                background: linear-gradient(135deg, #667eea 0%, #764ba2 100%);
                border-radius: 15px;
                box-shadow: 0 20px 40px rgba(0,0,0,0.1);
            }
            @media print { .no-print { display: none; } }
        </style>
        <div class='container'>
            <div class='card'>Modern CSS works!</div>
        </div>";

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

public class ModernWebStandards
{
    public async Task<byte[]> GenerateModernPdf()
    {
        var renderer = new ChromePdfRenderer();

        var html = @"
        <style>
            .container {
                display: grid;
                grid-template-columns: repeat(auto-fit, minmax(250px, 1fr));
                gap: 2rem;
            }
            .card {
                background: linear-gradient(135deg, #667eea 0%, #764ba2 100%);
                border-radius: 15px;
                box-shadow: 0 20px 40px rgba(0,0,0,0.1);
            }
            @media print { .no-print { display: none; } }
        </style>
        <div class='container'>
            <div class='card'>Modern CSS works!</div>
        </div>";

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

IRON VB CONVERTER ERROR developers@ironsoftware.com