Die Wahl einer C#-Bibliothek zur Umwandlung von HTML in PDF im Jahr 2026 läuft auf eine Entscheidung hinaus: Welcher Rendering-Engine passt zu den Dokumenten, die Sie tatsächlich erstellen. Unter .NET 10 teilt sich das Feld in drei Gruppen. Browserbasierte Engines (Chromium über PuppeteerSharp, Dramatikeroder ein eingebettetes Build) rendern moderne CSS und JavaScriptgenau. Programmbibliotheken (iText, PdfSharp) erzeugen PDFs aus benutzerdefinierten Parsern und tauschen die Treue zur modernen Webdarstellung gegen einen kleinen Fußabdruck. Layout-Tools, die direkt mit Code arbeiten (QuestPDF), umgehen HTML vollständig. Dieser Vergleich behandelt jede Option mit funktionierendem C#-Code, einer Bewertungsmatrix, ursprünglichen Benchmarks und den Lizenzbedingungen, die bestimmen, was Sie ausliefern können.

TL;DR: die schnelle Antwort und der schnellste funktionierende Code

Für genaues Rendering aktueller CSS- und JavaScript-Elemente verwenden Sie eine browserfähige Engine. Der kostenlose Weg ist PuppeteerSharpoder Playwright, die eine Chrome-ähnliche Ausgabe liefern, aber Sie lassen einen separaten Browserprozess und eine große Binärdatei verwalten. Der kommerzielle Weg bindet Chromium in das Paket ein, sodass nichts separat installiert oder gestartet werden muss. Für einfache statische Dokumente genügt eine leichte Bibliothek wie PdfSharp. Für codebestimmte Layouts ohne HTML-Quelle ist QuestPDF der kürzeste Weg.

Der schnellste funktionierende Pfad zu einem PDF mit einer eingebettetenEngineist ein einzelner Rendering-Aufruf:

using IronPdf;

// The embedded Chromium engine ships inside the package, so no browser is launched or downloaded
var renderer = new ChromePdfRenderer();
// One synchronous call parses the HTML string and produces an in-memory PDF document
var pdf = renderer.RenderHtmlAsPdf("<h1>Invoice</h1><p>Generated from HTML.</p>");
// Write the rendered document to disk
pdf.SaveAs("output.pdf");

using IronPdf;

// The embedded Chromium engine ships inside the package, so no browser is launched or downloaded
var renderer = new ChromePdfRenderer();
// One synchronous call parses the HTML string and produces an in-memory PDF document
var pdf = renderer.RenderHtmlAsPdf("<h1>Invoice</h1><p>Generated from HTML.</p>");
// Write the rendered document to disk
pdf.SaveAs("output.pdf");

Der vollständige Vergleich, Benchmarks und Lizenzdetails folgen unten.

Schnelle Empfehlungstabelle nach Szenario

Passen Sie Ihre Einschränkung an eine Auswahl an, bevor Sie sich vertiefen.

| Falls Sie benötigen |Empfohlene Auswahl| Warum | |---|---|---| |Moderne CSS, Flexbox, Grid, Webschriften in großem Maßstab|IronPDF (eingebettetes Chromium)|Genaues Rendering, schnelle Warmläufe, kein externer Browser zur Bereitstellung| |Kostenloses browserfähiges Rendering, bereit für die Verwaltung von Betriebsprozessen|PuppeteerSharp oder Playwright|Echtes Chromium, MIT-Lizenz, schwererer Bereitstellungsfußabdruck| |Einfaches statisches HTML, kein JavaScript|PdfSharp mit HtmlRenderer|Leicht, kostenlos, auf veraltetes CSS beschränkt| |Programmatische feste Layouts, keine HTML-Quelle| QuestPDF |Fluente C#-API, sehr schnell, kein HTML-Renderer| |Keine Infrastruktur, gehostete Verarbeitung|Eine HTML-zu-PDF-API|Keine Rendering-Engine, die in Ihrer App gewartet werden muss| |Legacy-Projekt auf wkhtmltopdf|Migration zu einer Chromium-Engine|wkhtmltopdf ist archiviert, scheitert an aktuellem CSS und trägt eine kritische SSRF-CVE|

Was macht HTML zu PDF in C# schwer

Browser rendern flüssige Inhalte für Bildschirme; PDF erfordert feste Seiten, genaue Abmessungen und strikte Paginierung. Die Lücke zwischen diesen beiden Modellen ist der Punkt, an dem Bibliotheken erfolgreich oder fehlschlagen. Fünf Kriterien unterscheiden sie, und sie gelten für jedes Werkzeug, unabhängig vom Anbieter.

1. Rendering-Engine und modernes CSS: Die Engine, die HTML und CSS parst, ist der entscheidende Differenzierer. Aktuelle Vorlagen stützen sich auf CSS Flexbox für die Ausrichtung, CSS Grid für zweidimensionale Layouts, @font-face für Typografie und SVG für Vektor-Assets. Engines, die auf alten WebKit-Forks oder benutzerdefinierten Parsern basieren, neigen dazu, hier leise zu versagen und stilisierte Layouts in einen vertikalen Stapel zu zerlegen. Die korrekte Handhabung von @media print Regeln ist ebenso wichtig, wenn ein Bildschirm-Layout in ein Papier-Layout umgewandelt wird.

2. Ausführung von JavaScriptund Render-Wartezeiten: Vieler heutige Inhalte werden clientseitig erstellt. Diagrammbibliotheken wie Chart.js und Single-Page-Frameworks wie Blazor WebAssembly konstruieren das DOM mit JavaScript, bevor die Seite fertiggestellt ist. Eine Bibliothek ohne JavaScript-Engine erzeugt leere Diagramme oder halbgeladene Seiten, was die Fähigkeit, Skripte auszuführen und auf ein Render-bereites Signal zu warten, entscheidend für dynamische Dokumente macht.

3. Bereitstellungsgewicht und Kaltstart: Werkzeuge, die einen externen headless Browser steuern, laden Hunderte von Megabytes an Binärdateien herunter, die Container-Images aufblasen und den Kaltstart verlangsamen. In serverlosen Umgebungen wie AWS Lambda oder Azure Functions, wo Speicher und Arbeitsspeicher knapp sind, kann das Containergewicht entscheiden, ob eine Bibliothek überhaupt tragbar ist.

4. Lizenz und ihre rechtliche Reichweite: Eine Lizenz diktiert mehr als nur die Kosten. Das .NET PDF-Feld erstreckt sich über freizügige Bedingungen (MIT, Apache 2.0), Copyleft-Bedingungen (AGPLv3), die die Offenlegung Ihres Quellcodes für netzwerkorientierte Apps erfordern können, umsatzgesteuerte Community-Tiers und unbefristete kommerzielle Lizenzen. Die falsche Wahl kann eine Verpflichtung schaffen, die sich erst bei einer Überprüfung zeigt.

5. Leistung und Speicher in großem Maßstab: Eine Bibliothek, die in einem Konsolentest in Ordnung ist, kann bei einer gleichzeitigen Web-API ins Stocken geraten. Einige streamen die Arbeit; andere laden das gesamte Dokument auf einmal in den Speicher und lösen Pausen bei der Müllabfuhr während Batch-Jobs aus. Kaltstart, Warmstart und pro-Render-Speicher sind drei separate Messungen, die jeweils Aufmerksamkeit benötigen.

Die Bibliotheken, jeweils mit funktionierendem Code

Zuerst kommen die kostenlosen und Open-Source-Optionen. Jeder Ausschnitt unten wurde auf .NET 10 kompiliert und ausgeführt, und die Chromium-Engines zeigen sowohl HTML-String- als auch URL-Eingaben, da sie beide unterstützen.

PuppeteerSharp

PuppeteerSharp ist eine .NET-Portierung von Googles Node.js Puppeteer, die erstmals 2017 veröffentlicht wurde. Es steuert eine headless Chromium-Instanz über das Chrome DevTools-Protokoll. Es ist ein Prozessorchestrator statt einer In-Prozess-Bibliothek: Die Anwendung lädt einen Chromium-Build mit BrowserFetcher herunter, startet den Browser, setzt den Seiteninhalt und erfasst das PDF.

using PuppeteerSharp;
using System.Threading.Tasks;

public class PuppeteerExample
{
    public async Task GeneratePdfAsync()
    {
        // Download a matching Chromium build if it is not already present (the 100-300 MB fetch)
        await new BrowserFetcher().DownloadAsync();

        // Start a headless browser process; await using disposes it to avoid orphaned processes
        await using var browser = await Puppeteer.LaunchAsync(new LaunchOptions { Headless = true });
        // Open a fresh tab to work in
        await using var page = await browser.NewPageAsync();

        // Load the HTML directly into the page instead of navigating to a URL
        await page.SetContentAsync("<h1>Invoice Report</h1><p>Rendered with PuppeteerSharp.</p>");
        // Drive Chrome's print pipeline to emit the PDF file
        await page.PdfAsync("puppeteer_output.pdf");
    }
}

using PuppeteerSharp;
using System.Threading.Tasks;

public class PuppeteerExample
{
    public async Task GeneratePdfAsync()
    {
        // Download a matching Chromium build if it is not already present (the 100-300 MB fetch)
        await new BrowserFetcher().DownloadAsync();

        // Start a headless browser process; await using disposes it to avoid orphaned processes
        await using var browser = await Puppeteer.LaunchAsync(new LaunchOptions { Headless = true });
        // Open a fresh tab to work in
        await using var page = await browser.NewPageAsync();

        // Load the HTML directly into the page instead of navigating to a URL
        await page.SetContentAsync("<h1>Invoice Report</h1><p>Rendered with PuppeteerSharp.</p>");
        // Drive Chrome's print pipeline to emit the PDF file
        await page.PdfAsync("puppeteer_output.pdf");
    }
}

Um eine Live-URL statt eines Strings zu erfassen, navigieren Sie vor dem Aufruf zu ihr:

// Navigate the tab to a live URL so the loaded page becomes the render source
await page.GoToAsync("https://example.com");
// Capture whatever is currently displayed as a PDF
await page.PdfAsync("from_url.pdf");

// Navigate the tab to a live URL so the loaded page becomes the render source
await page.GoToAsync("https://example.com");
// Capture whatever is currently displayed as a PDF
await page.PdfAsync("from_url.pdf");

Stärken:

• Das Rendering entspricht Google Chrome, mit vollständiger Flexbox-, Grid- und Webschriften-Unterstützung.
• Führt JavaScriptaus und kann auf Netzwerk-Idle warten, bevor es erfasst.
• MIT-lizenziert, sodass die kommerzielle Nutzung keine Copyleft-Verpflichtung mit sich bringt.

Einschränkungen:

• Ein erster Lauf lädt einen 100 MB bis 300 MB großen Chromium-Build herunter.
• Jede Browserinstanz verbraucht erheblich Speicher, sodass für gleichzeitige Stapelverarbeitungen ein Browserpool erforderlich ist.
• Kein eingebautes PDF/A oder PDF/UA-Output.

License: MIT. Wählen Sie es, wenn Sie kostenlose Chrome-Genauigkeit wünschen und das Team den Betriebsaufwand bewältigen kann. Für einen fokussierten Vergleich dieser Abwägung siehe den PuppeteerSharp vs IronPDFVergleich.

Dramatikerfor .NET

Playwright wird von Microsoft als plattformübergreifendes Automatisierungs-Framework für Chromium, WebKit und Firefox gepflegt. Teams nutzen es für HTML zu PDF über Page.PdfAsync, obwohl die PDF-Erzeugung nur mit Chromium funktioniert. Das Setup holt Browser-Binärdateien durch einen einmaligen Installationsschritt.

using Microsoft.Playwright;
using System.Threading.Tasks;

public class PlaywrightExample
{
    public async Task GeneratePdfAsync()
    {
        // Create the Dramatikerdriver that manages the installed browser binaries
        using var playwright = await Playwright.CreateAsync();
        // PDF output is Chromium-only, so launch the Chromium build specifically
        await using var browser = await playwright.Chromium.LaunchAsync();
        // Open a new page (tab) to render into
        var page = await browser.NewPageAsync();

        // Set the HTML content in place rather than navigating to a URL
        await page.SetContentAsync("<html><body><h1>Sales Dashboard</h1></body></html>");
        // Emit the PDF with an explicit A4 page format
        await page.PdfAsync(new PagePdfOptions { Path = "playwright_output.pdf", Format = "A4" });
    }
}

using Microsoft.Playwright;
using System.Threading.Tasks;

public class PlaywrightExample
{
    public async Task GeneratePdfAsync()
    {
        // Create the Dramatikerdriver that manages the installed browser binaries
        using var playwright = await Playwright.CreateAsync();
        // PDF output is Chromium-only, so launch the Chromium build specifically
        await using var browser = await playwright.Chromium.LaunchAsync();
        // Open a new page (tab) to render into
        var page = await browser.NewPageAsync();

        // Set the HTML content in place rather than navigating to a URL
        await page.SetContentAsync("<html><body><h1>Sales Dashboard</h1></body></html>");
        // Emit the PDF with an explicit A4 page format
        await page.PdfAsync(new PagePdfOptions { Path = "playwright_output.pdf", Format = "A4" });
    }
}

Vor dem ersten Lauf installieren Sie den Browser mit pwsh bin/Debug/net10.0/playwright.ps1 install chromium (oder rufen Sie den entsprechenden Installations-Einstiegspunkt im Code auf).

Für eine Live-URL navigieren Sie zuerst zur Seite:

// Load a live URL so its rendered DOM becomes the PDF source
await page.GotoAsync("https://example.com");
// Export the loaded page as an A4 PDF
await page.PdfAsync(new PagePdfOptions { Path = "from_url.pdf", Format = "A4" });

// Load a live URL so its rendered DOM becomes the PDF source
await page.GotoAsync("https://example.com");
// Export the loaded page as an A4 PDF
await page.PdfAsync(new PagePdfOptions { Path = "from_url.pdf", Format = "A4" });

Wo es glänzt:

• Unterstützt von Microsoft mit einem aktiven Release-Zyklus.
• Geringe Erstellungsverzögerung, sobald der Browser startet.
• Rendert moderne Webstandards und clientseitiges JavaScriptgenau.

Der Haken:

• Gleicher schwerer Binärdatei-Fußabdruck und Browserverwaltung wie bei PuppeteerSharp.
• Der Speicherbedarf steigt, ohne sorgfältige Behandlung der Browser-Kontexte.
• Der PDF-Ausgang ist ein Nebenprodukt von Chromes Druckpipeline, daher fehlen Dokumentmanipulationsfunktionen.

License: MIT. Ideal, wenn ein Projekt bereits Dramatikerfür Tests verwendet und kostenloses Rendering daneben haben möchte.

wkhtmltopdf (via DinkToPdf)

Über ein Jahrzehnt lang war wkhtmltopdf das Standardwerkzeug für HTML zu PDF. In .NET wird es normalerweise über DinkToPdf genutzt, einem C#-Wrapper über die native libwkhtmltox-Bibliothek. Die Wrapper-API ist sauber, aber das zugrunde liegendeEngineist das Problem.

using DinkToPdf;

public class DinkToPdfExample
{
    public void GeneratePdf()
    {
        // SynchronizedConverter serializes calls into the non-thread-safe native libwkhtmltox library
        var converter = new SynchronizedConverter(new PdfTools());

        // Describe the document: global page settings plus one or more HTML content objects
        var doc = new HtmlToPdfDocument
        {
            // Set the paper size and the output file path for the whole document
            GlobalSettings = { PaperSize = PaperKind.A4, Out = "legacy_output.pdf" },
            // Each object is a chunk of HTML to render into the PDF
            Objects = { new ObjectSettings { HtmlContent = "<h1>Legacy Report</h1>" } }
        };

        // Hand the descriptor to the native engine, which writes the file defined in Out
        converter.Convert(doc);
    }
}

using DinkToPdf;

public class DinkToPdfExample
{
    public void GeneratePdf()
    {
        // SynchronizedConverter serializes calls into the non-thread-safe native libwkhtmltox library
        var converter = new SynchronizedConverter(new PdfTools());

        // Describe the document: global page settings plus one or more HTML content objects
        var doc = new HtmlToPdfDocument
        {
            // Set the paper size and the output file path for the whole document
            GlobalSettings = { PaperSize = PaperKind.A4, Out = "legacy_output.pdf" },
            // Each object is a chunk of HTML to render into the PDF
            Objects = { new ObjectSettings { HtmlContent = "<h1>Legacy Report</h1>" } }
        };

        // Hand the descriptor to the native engine, which writes the file defined in Out
        converter.Convert(doc);
    }
}

Dieser Code kompiliert, aber beim Ausführen auf einer sauberen Maschine wirft es System.DllNotFoundException: Unable to load DLL 'libwkhtmltox', bis die nativen Binärdateien in das Ausgabeverzeichnis kopiert werden. Dieser Schritt mit der nativen Abhängigkeit ist das erste Anzeichen für die Bereitstellungsreibung, die dieseEnginemit sich bringt.

Vorteil:

• Schneller Kaltstart, ohne modernen Browser zu initialisieren.
• Geringer Speicherbedarf, etwa 50 MB pro Rendering.

Nachteil:

• Die QtWebKit-Engine, die es liefert (ein ungefährer Snapshot von WebKit aus den Jahren 2012-2013, den Qt selbst 2015 abgekündigt und 2016 entfernt hat), kann Flexbox, Grid und modernes JavaScriptnicht rendern.
• Das wkhtmltopdf-Repository wurde am 2. Januar 2023 archiviert, und die letzte Version, 0.12.6, stammt vom Juni 2020.
• Es enthält CVE-2022-35583, einen Server-Side Request Forgery-Fehler mit einer CVSS-Bewertung von 9.8 (kritisch), der nicht gepatcht ist, weil das Projekt nicht mehr gepflegt wird.

Lizenz: DinkToPdf selbst ist MIT, aber es verlinkt die LGPLv3 wkhtmltopdf-Binärdateien, sodass die effektive Verpflichtung von wkhtmltopdf ausgeht. Geeignet für Legacy-Workflows, die auf Migration warten, wobei das Sicherheitsrisiko im Blick bleibt. Den vollständigen Migrationsüberblick siehe den wkhtmltopdf vs IronPDFVergleich.

PdfSharp and HtmlRenderer

PdfSharp ist eine weit verbreitete Open-Source-Bibliothek, aber ein häufiger Irrtum ist, dass sie HTML eigenständig konvertiert. Nein. PdfSharp bietet eine low-level, koordinatenbasierte Zeichen-API. Um HTML zu konvertieren, kombinieren Sie es mit der Community-Bridge HtmlRenderer.PdfSharp, die HTML parst und PdfSharp-Zeichenbefehle erzeugt.

using PdfSharp;
using TheArtOfDev.HtmlRenderer.PdfSharp;

public class PdfSharpExample
{
    public void GeneratePdf()
    {
        string html = "<h1>Simple Title</h1><p>Statically rendered text.</p>";

        // The HtmlRenderer bridge parses the HTML and emits PdfSharp drawing commands onto an A4 page
        var pdf = PdfGenerator.GeneratePdf(html, PageSize.A4);
        // Persist the resulting PdfSharp document to disk
        pdf.Save("simple_document.pdf");
    }
}

using PdfSharp;
using TheArtOfDev.HtmlRenderer.PdfSharp;

public class PdfSharpExample
{
    public void GeneratePdf()
    {
        string html = "<h1>Simple Title</h1><p>Statically rendered text.</p>";

        // The HtmlRenderer bridge parses the HTML and emits PdfSharp drawing commands onto an A4 page
        var pdf = PdfGenerator.GeneratePdf(html, PageSize.A4);
        // Persist the resulting PdfSharp document to disk
        pdf.Save("simple_document.pdf");
    }
}

Zwei Einrichtungspunkte sind unter .NET 10 von Bedeutung. Die Bridge erwartet die Windows-1252-Codepage, die in modernen .NET-Versionen standardmäßig fehlt, daher registrieren Sie sie einmalig beim Start mit Encoding.RegisterProvider(CodePagesEncodingProvider.Instance). Das Kombinieren der Bridge mit einem neueren PdfSharp 6.x-Paket bricht auch zur Laufzeit mit MissingMethodException, daher lassen Sie HtmlRenderer sein eigenes kompatibles PdfSharp ziehen, anstatt die neueste festzulegen.

Was funktioniert:

• Genuin permissive MIT-Lizenz ohne Umsatzlimits.
• Leicht, ohne native Binärdateien oder Browser-Abruf.
• Rein C#, daher ist die Bereitstellung über Betriebssysteme hinweg unkompliziert.

Was scheitert:

• Die HTML-Bridge ist auf etwa HTML 4.01 und CSS Level 2 beschränkt und hat Ende 2025 ein einziges Set von Releases gesehen, nach neun Jahren ohne Aktivität.
• Keine JavaScript-Ausführung überhaupt.
• Druckregeln wie page-break-inside: avoid werden nicht unterstützt, sodass Tabellenzeilen über Seiten hinweg verteilt werden.

License: PdfSharp MIT, HtmlRenderer BSD-3-Clause. Die richtige Wahl für einfache statische Dokumente ohne komplexes Layout. Für eine funktionsspezifische Aufschlüsselung siehe den PdfSharp vs IronPDFVergleich.

QuestPDF

QuestPDF geht einen anderen Weg: Es verwirft HTML und definiert Layouts in C# über eine fluente API. Für Daten, die als Objekte und nicht als Markup entstehen, entfällt der Schritt, HTML zu generieren, nur um es zurück zu parsen.

using QuestPDF.Fluent;
using QuestPDF.Helpers;
using QuestPDF.Infrastructure;

public class QuestPdfExample
{
    public void GeneratePdf()
    {
        // The revenue-gated license tier must be declared before any document is built
        QuestPDF.Settings.License = LicenseType.Community;

        // Compose the layout in C# through the fluent API; no HTML anywhere
        var document = Document.Create(container =>
        {
            container.Page(page =>
            {
                // Define the physical page size and margins
                page.Size(PageSizes.A4);
                page.Margin(2, Unit.Centimetre);
                // Place content into named page regions (header and body)
                page.Header().Text("Programmatic Invoice").FontSize(24);
                page.Content().Text("This document is generated without HTML.");
            });
        });

        // Run the layout engine and write the composed document to a file
        document.GeneratePdf("fluent_layout.pdf");
    }
}

using QuestPDF.Fluent;
using QuestPDF.Helpers;
using QuestPDF.Infrastructure;

public class QuestPdfExample
{
    public void GeneratePdf()
    {
        // The revenue-gated license tier must be declared before any document is built
        QuestPDF.Settings.License = LicenseType.Community;

        // Compose the layout in C# through the fluent API; no HTML anywhere
        var document = Document.Create(container =>
        {
            container.Page(page =>
            {
                // Define the physical page size and margins
                page.Size(PageSizes.A4);
                page.Margin(2, Unit.Centimetre);
                // Place content into named page regions (header and body)
                page.Header().Text("Programmatic Invoice").FontSize(24);
                page.Content().Text("This document is generated without HTML.");
            });
        });

        // Run the layout engine and write the composed document to a file
        document.GeneratePdf("fluent_layout.pdf");
    }
}

Starke Punkte:

• Sehr schnell, da es DOM-Parsung und Browser-Layout überspringt.
• Vorhersehbarer, linearer Speicher, der für hochdurchsatzbare Batch-Jobs geeignet ist.
• Eine Begleit-App bietet Live-Vorschau und Hot-Reload während des Designs.

Schwache Punkte:

• Es ist eine Layout-Engine, kein HTML-Renderer, daher kann es keine URL oder vorhandene HTML-Vorlage konvertieren.
• Bestehende HTML- oder Razor-Dokumente müssten vollständig in die fluente API umgeschrieben werden.
• Die Lizenz wechselte von MIT zu einem umsatzgesteuerten Modell.

Lizenz: Community-Lizenz (kostenlos für Unternehmen unter 1.000.000 US-Dollar Jahresumsatz) oder ein kostenpflichtiges Professional und Enterprise Tier. Passt zu codebestimmten, festen Layout-Dokumenten, die von strukturierten Daten angetrieben werden. Für den Gegensatz zwischen HTML und fluenten Layouts siehe den QuestPDF vs IronPDFVergleich.

iText (pdfHTML)

iText 7 und 8 sind bekannt für die programmatische Manipulation von PDFs, und das pdfHTML-Add-On konvertiert HTML. Im Gegensatz zu den Chromium-Werkzeugen verwendet pdfHTML einen benutzerdefinierten Parser, der HTML-Tags in iText-Objekte mappt, anstatt einen Browser auszuführen.

using iText.Html2pdf;
using System.IO;

public class iTextExample
{
    public void GeneratePdf()
    {
        string html = "<h1>Report</h1><p>Converted with pdfHTML.</p>";

        // Open the destination stream; using ensures the file handle is released after writing
        using var dest = File.Create("output.pdf");
        // pdfHTML maps the HTML tags to iText objects and writes them to the stream (no browser involved)
        HtmlConverter.ConvertToPdf(html, dest);
    }
}

using iText.Html2pdf;
using System.IO;

public class iTextExample
{
    public void GeneratePdf()
    {
        string html = "<h1>Report</h1><p>Converted with pdfHTML.</p>";

        // Open the destination stream; using ensures the file handle is released after writing
        using var dest = File.Create("output.pdf");
        // pdfHTML maps the HTML tags to iText objects and writes them to the stream (no browser involved)
        HtmlConverter.ConvertToPdf(html, dest);
    }
}

Bei einem neuen Projekt scheitert es, bis Sie das itext7.bouncy-castle-adapter-Paket hinzufügen, das iText für seinen Kryptografiepfad benötigt. Diese zusätzliche Abhängigkeit wird leicht übersehen und erzeugt ohne sie einen undurchsichtigen Fehler.

Vorteile:

• Tiefe PDF-Manipulation, Signatur und Schwärzung im gesamten iText-Ökosystem.
• Erzeugt PDF/A und PDF/UA aus semantischem HTML, was für Compliance-Arbeiten geeignet ist.
• Schnelle Startzeit, da es keinen Browser startet.

Nachteile:

• Keine Skriptausführung, daher wird dynamischer Inhalt nicht gerendert.
• CSS3-Features wie Grid werden nicht unterstützt und scheitern still.
• Die AGPLv3-Lizenz erfordert eine kommerzielle Lizenz für geschlossene Anwendungen, und große Dateien werden vollständig gepuffert anstatt gestreamt.

License: AGPLv3 or Commercial. Wählen Sie es für umfangreiche PDF-Manipulation und Compliance-Workflows mit kontrolliertem, statischem HTML. Für die Lizenz- und Manipulationsdetails siehe den Vergleich iText 7 vs IronPDF.

IronPDF

IronPDF bindet eine Chromium-Engine in sein NuGet-Paket ein und stellt es über eine C#-API zur Verfügung, sodass nichts extern gestartet oder gepoolt werden muss. Es liegt zwischen den kostenlosen Browsertools und den programmatischen Bibliotheken und tauscht eine Lizenzkosten gegen Rendertreue ohne den zu verwaltenden Browser.

using IronPdf;
using System.Threading.Tasks;

public class IronPdfExample
{
    public async Task GeneratePdfAsync()
    {
        // Create the in-process Chromium renderer (no external browser to launch)
        var renderer = new ChromePdfRenderer();
        // Turn on the JavaScriptengine so client-side chart scripts execute before capture
        renderer.RenderingOptions.EnableJavaScript = true;
        // Wait 500 ms after load to let JavaScript-built content settle before rendering
        renderer.RenderingOptions.WaitFor.RenderDelay(500);

        // Render the HTML string asynchronously into an in-memory PDF
        var pdf = await renderer.RenderHtmlAsPdfAsync("<h1>Quarterly Report</h1><div class='chart'></div>");
        // Save the finished PDF to disk
        pdf.SaveAs("report.pdf");
    }
}

using IronPdf;
using System.Threading.Tasks;

public class IronPdfExample
{
    public async Task GeneratePdfAsync()
    {
        // Create the in-process Chromium renderer (no external browser to launch)
        var renderer = new ChromePdfRenderer();
        // Turn on the JavaScriptengine so client-side chart scripts execute before capture
        renderer.RenderingOptions.EnableJavaScript = true;
        // Wait 500 ms after load to let JavaScript-built content settle before rendering
        renderer.RenderingOptions.WaitFor.RenderDelay(500);

        // Render the HTML string asynchronously into an in-memory PDF
        var pdf = await renderer.RenderHtmlAsPdfAsync("<h1>Quarterly Report</h1><div class='chart'></div>");
        // Save the finished PDF to disk
        pdf.SaveAs("report.pdf");
    }
}

Der gleiche Renderer konvertiert eine URL in PDF mit einem einzigen Aufruf:

// RenderUrlAsPdf fetches and renders the live page in one call, no navigation step needed
var fromUrl = new ChromePdfRenderer().RenderUrlAsPdf("https://example.com");
// Write the captured page to disk
fromUrl.SaveAs("from_url.pdf");

// RenderUrlAsPdf fetches and renders the live page in one call, no navigation step needed
var fromUrl = new ChromePdfRenderer().RenderUrlAsPdf("https://example.com");
// Write the captured page to disk
fromUrl.SaveAs("from_url.pdf");

Es rendert auch Razor und MVC Ansichten zu PDF und konvertiert HTML-Dateien direkt. Die vollständige Funktionsübersicht finden Sie im HTML zu PDF Tutorial.

Vorteile:

• Browsergrad-Rendering, das Grid, Flexbox und clientseitige Skripte handhabt.
• Bereitstellung ohne externe ausführbare Dateien oder Browser-Pooling.
• Generiert PDF/A und wendet digitale Signaturen an, was es von den Test-Frameworks trennt.

Nachteile:

• Eine kommerzielle Lizenz ist erforderlich, mit keiner kostenlosen Produktionstufe.
• Nach einer frischen Bereitstellung trägt das Öffnungs-Rendering eine einmalige Initialisierungskosten, dann setzen sich spätere Renderings in einen schnellen, warmen Pfad ein.

Lizenz: kommerziell, unbefristet. Nutzen Sie es dort, wo aktuelle CSS in großem Maßstab wichtig ist und die Prioritäten die Reduzierung des Betriebsaufwands bei gleichbleibend hoher Treue sind.

Vollständige Vergleichstabelle

Eine Zeile pro Bibliothek, mit der Lizenzspalte, die enthalten ist, weil sie direkt die Entscheidung zwischen kostenlos und bezahlt vorantreibt.

| Bibliothek |Engine| JavaScript| Modernes CSS|Bereitstellungsgewicht| Lizenz| Am besten geeignet für | |---|---|---|---|---|---|---| |IronPDF| Eingebettetes Chromium | Ja | Voll |Leicht (NuGet)| Kommerziell |Moderne CSS in großem Maßstab| | PuppeteerSharp|Externes Chromium| Ja | Voll |Schwer (Binär-Download)| MIT |Kostenloses Browser-Rendering| | Dramatiker|Externes Chromium| Ja | Voll |Schwer (Binär-Download)| MIT |Moderne kostenlose Rendering| | wkhtmltopdf |Altes QtWebKit| Beschränkt |Schwach|Mittel (native Bibliotheken)|LGPLv3 (Wrapper MIT)|Alte Workflows| |PdfSharp + HtmlRenderer|Benutzerdefinierte Zeichnung|Nein| Beschränkt |Leicht|MIT / BSD-3|Einfaches statisches HTML| | QuestPDF |Programmatisch| Nicht anwendbar | Nicht anwendbar |Leicht|Community / Bezahlt|Code-definierte Layouts| | iText pdfHTML| Benutzerdefinierter Parser|Nein| Beschränkt | Medium|AGPLv3 / Kommerziell| PDF-Manipulation|

Überprüfen Sie jede Zelle gegen die aktuelle Version jeder Bibliothek, bevor Sie sie integrieren, da sich Lizenz- und Engine-Unterstützung ändern.

Kostenlos vs. Bezahlt: wann jede die richtige Wahl ist

Werkzeuge, die "kostenlos" sind, können im .NET PDF-Feld betriebliche und rechtliche Kosten verbergen, also die Benennung der Fälle, in denen ein kostenloses Werkzeug die richtige Wahl ist, ist der ehrliche Ausgangspunkt.

Eine kostenlose Open-Source-Bibliothek ist wirklich genug für einfache, statische Dokumente, geringes Volumen oder ein Team mit der Kapazität, externe Prozesse zu verwalten. Ein textlastiger Beleg ohne komplizierte Styling rendert gut mit MIT-lizenziertem PdfSharp. Wo ein Team bereits Dramatikerfür Tests nutzt und die Containerisierung gelöst hat, ist die Wiederverwendung für gelegentliche PDF-Jobs effizient.

Kostenlose Software bedeutet nicht eine kostenlose Implementierung. Der versteckte Kostenpunkt von Open-Source headless Browsern zeigt sich in Wartungsstunden: der Browser-Lebenszyklus wird gepoolt, damit der Server unter Last nicht abstürzt, das Konfigurieren von Linux-Freigabe-Bibliotheksabhängigkeiten über Container-Images hinweg, und die Infrastrukturkosten schwerer Browser-Prozesse zu absorbieren. Für triviale statische Dokumente ist eine bezahlte Browser-Engine übertrieben, und eine leichte kostenlose Bibliothek ist die bessere Wahl.

Eine kommerzielle Chromium-Bibliothek wird gerechtfertigt, wenn die Arbeit akkurate CSS3 in großem Maßstab, zugänglichen PDF/UA-Ausgang und Bereitstellungseinfachheit über Beschaffungskosten verlangt. Kommerzielle Lizenzierung entfernt auch die Copyleft-Exposition. Das Hinzufügen einer AGPLv3-Bibliothek wie iText zu einer SaaS-Plattform kann das Unternehmen verpflichten, seinen Quellcode freizugeben, es sei denn, es wird eine kommerzielle Lizenz erworben. Der wahre Vergleich ist die Gesamtkosten des Besitzes: Betriebszeit und rechtliches Risiko auf der einen Seite, Lizenzgebühren auf der anderen.

Benchmarks

Jede Zahl unten entstammt einem praktischen Durchlauf auf einer einzigen Maschine, also behandeln Sie sie als richtungsweisend. Das Testdokument ist eine 30-zeilige Rechnung mit CSS Grid im Kopf und einem Inline-JavaScript-Balkendiagramm. Die Tests wurden auf einem Standard-Windows-Arbeitsplatz unter .NET 10 durchgeführt. Jede warme Zahl ist der Durchschnitt aus acht Rendervorgängen nach dem ersten, und der Spitzenwert ist der Spitzenwert des Arbeitssatzes des .NET-Prozesses plus aller Browser-Kindprozesse, die es gestartet hat.

| Bibliothek |Kaltstart (pro Prozess)|Warmerender (Durchschnitt von 8)|Spitzenspeicher| |---|---|---|---| |IronPDF|345 ms|202 ms|406 MB| | PuppeteerSharp|746 ms|204 ms|611 MB| | Dramatiker|588 ms|132 ms|515 MB| |wkhtmltopdf, iText, PdfSharp| sub-second | not comparable |50 bis 120 MB|

Einmal warm, rendern die drei Browser-Engines das gleiche Dokument in ungefähr 130 bis 200 ms, wobei Dramatikerin diesem Durchlauf am schnellsten ist und IronPDFund PuppeteerSharpdicht dahinter. Beim Kaltstart lief die eingebetteteEnginehier am schnellsten, weil sie In-Prozess läuft, ohne dass ein separater Browser gestartet werden muss, obwohl das allererste Rendern nach einer brandneuen Bereitstellung eine einmalige Initialisierungskosten absorbiert, die spätere Prozessstarts überspringen. Die alten und benutzerdefinierten Parserwerkzeuge (wkhtmltopdf, iText, PdfSharp) starten in weniger als einer Sekunde und verwenden den wenigsten Speicher, aber dieser Vorteil ist für das Testdokument zweitrangig, da sie sein Grid-Layout oder sein JavaScript-Diagramm nicht korrekt rendern können. wkhtmltopdf konnte ohne seine nativen Binärdateien überhaupt nicht laufen.

Die Treue-Lücke zeigt sich in der Ausgabe. Die Browser-Engine rendert den CSS Grid-Kopf, die gestaltete Tabelle und das JavaScript-Balkendiagramm:

Das gleiche Dokument durch PdfSharp mit HtmlRenderer lässt den Grid-Kopf, die Tabellenkopfgestaltung und das JavaScript-Diagramm weg:

Welche sollten Sie verwenden?

Ein kurzes Urteil für jedes gängige Szenario:

• CSS-Frameworks und One-Page-Ausgabe: nur ein browserfähiger Renderer hält mit.
• Einfaches statisches HTML oder Textquittungen: PdfSharp und ein kleiner kostenloser Stack decken es ab.
• Programmatische, datengesteuerte Layouts ohne Markup: QuestPDF gelangt am schnellsten dahin.
• Kostenloses Browser-Rendering mit Betriebskapazität: PuppeteerSharpoder Playwright.
• Keine Infrastruktur: Eine gehostete HTML-zu-PDF-API.
• Legacy-migration von wkhtmltopdf: wechseln Sie zu einer eingebettetenEnginefür Sicherheit und CSS-Unterstützung.

Wenn schwere CSS-Framework-Ausgabe mit einem Bedarf an geringem Betriebsaufwand zusammentrifft, ist IronPDFdie eingebettete Option, die Sie zuerst wählen sollten, während die kostenlosen Browser-Tools die richtige Wahl für Teams bleiben, die den Betrieb um einen headless Browser herum selbst durchführen können.

Bereitstellungsüberlegungen

Der größte Reibungspunkt in der .NET-Dokumentenerzeugung ist die Lücke zwischen einer Bibliothek, die auf einem Windows-Laptop funktioniert, und einer, die in einem Linux-Container fehlschlägt. Die Auswahl einer Bibliothek bedeutet, vorherzusehen, wo sie verschickt wird.

In Docker benötigen orchestrierte Browser wie PuppeteerSharpund Dramatikerein Basis-Image mit den Abhängigkeiten des Linux-Chromium, einschließlich libnss3, libatk-bridge2.0-0 und libgbm1. Microsoft veröffentlicht Dramatiker.NET-Images unter mcr.microsoft.com/playwright/dotnet (zum Beispiel ein v1.NN.0-noble tag), um diese zu decken, und diese Bilder laufen in der Nähe eines Gigabyte. Eingebettete Engines umgehen die Aufblähung, indem sie Architektur-abhängige NuGet-Pakete verschicken, wie IronPdf.Linux, die die nativen Binärdateien bündeln und ein Standard-aspnet Basis-Image ohne manuelle apt-get Schritte funktionsfähig halten.

AWS Lambda stellt eine andere Wand auf. Es setzt ein hartes Limit von 250 MB für das entpackte Bereitstellungspaket durch, wobei allein ein headless Chromium-Build 150 MB bis 300 MB groß ist. Das macht eine Standard-ZIP-Bereitstellung von PuppeteerSharpoder Dramatikerunpraktisch und drängt Teams auf containerbasierte Lambda, das bis zu 10 GB erlaubt, jedoch zu Lasten eines schlechteren Kaltstarts.

Azure App Service fügt seine eigenen Einschränkungen auf beiden Betriebssystemen hinzu. Der Windows App Service-Sandbox blockiert die meisten User32- und GDI32-Aufrufe und bricht damit GDI-abhängige Rendering-Pfade. Die Bereitstellung von DinkToPdf auf dem Linux App Service bedeutet das Kopieren von unmanaged .so Dateien in das Ausgabeverzeichnis und das Installieren von Abhängigkeiten wie libfontconfig1 und libxrender1; eine fehlende erscheint als eine undurchsichtige System.DllNotFoundException. Dies sind dieselben nativen Abhängigkeits- und Sandkastenprobleme, die der Verifizierungslauf reproduziert hat.

Schlussfolgerung und Empfehlung

Das C# HTML zu PDF-Feld auf .NET 10 belohnt die Anpassung des Werkzeugs an das Dokument. Eine komplette Browser-Engine bildet die Basis für CSS-Frameworks und responsive Layouts und JavaScript-getriebene Seiten, und die Aufteilung zwischen kostenlos und kommerziell ist wirklich eine Aufteilung zwischen Betreibsanstrengung und Lizenzkosten. Programmatische Bibliotheken bleiben effizient für feste, statische Layouts, und QuestPDF ist der schnellste Weg, wenn die Eingabe strukturierte Daten und kein Markup ist. wkhtmltopdf gehört nur in Migrationspläne, angesichts seiner archiviertenEngineund des ungepatchten SSRF-Fehlers. Für Teams, die genaues Rendering ohne viel Betriebskosten möchten, ist IronPDFdie Standard-Option mit URL-zu-PDF, Razor-Ansicht-Rendering, PDF/A-Ausgabe und digitale Signaturen verfügbar von der gleichen API, während PuppeteerSharpund Dramatikerstarke kostenlose Optionen bleiben, wenn das Browser-Lifecycle etwas ist, das das Team selbst in die Hand nehmen kann.

Probieren Sie es mit Ihrem eigenen HTML aus

Wenn genaues Rendering mit geringen Versandkosten zu Ihrem Projekt passt, können Sie eine kostenlose IronPDF-Testversion starten und diese gleiche Testrechnung gegen Ihre eigenen Vorlagen ausführen, bevor Sie sich festlegen.IronPDFwird von Iron Software entwickelt, dessen .NET-Bibliotheken auch OCR, Barcodes, Word und Excel abdecken.

Danke fürs Lesen. Unabhängig davon, auf welche Bibliothek Sie sich einlassen, passen Sie sie an das Dokument an, das vor Ihnen liegt.