Blazor HTML to PDF: Convert a Component or HTML to a Real PDF

Before you pick a library, look at how your app is hosted, because it rules options in or out. A Blazor WebAssembly app runs entirely in the user's browser, which means there is no server process to run a .NET PDF engine like IronPDF or Syncfusion. Those are server-side libraries, so from a WebAssembly app your only realistic choices are a purely client-side approach or a call out to an API. A Blazor Server app, by contrast, executes on your server, so you can run any server-side library there. This single fact is why so many Blazor PDF questions have contradictory answers online: the right tool depends on a hosting detail the question usually leaves out.

The other divide is the same one every stack faces: does a real browser render the document, or does a library draw it. QuestPDF and PDFsharp draw it in code, so they produce clean vector PDFs but never accept your HTML or CSS. IronPDF, Syncfusion and PuppeteerSharp drive a Chromium engine, so they render your actual markup with full CSS and JavaScript. A hosted API is the browser route without the browser: you send HTML, it renders in managed Chromium, and it works identically whether your app is Server or WebAssembly.

It is worth being clear about QuestPDF, because it is popular and frequently suggested for this. QuestPDF does not convert HTML to PDF, and that is a deliberate design decision, not a missing feature. It gives you a fluent C# API to compose a document from rows, columns, tables and text, and for a structured invoice or report that you are content to lay out in code it is fast, has no browser overhead, and is free under its revenue threshold. PDFsharp and MigraDoc work the same way at a lower level. The trade is that none of them reuse your Razor markup or CSS: if you already have a nicely styled component, you are rebuilding it in a different language. When the document is genuinely code-shaped and small, that is fine. When it should look like a page your users already see, it is a lot of duplicated effort that drifts out of sync.

To get a PDF that matches your Blazor UI, a browser has to render it. The Chromium libraries (IronPDF, Syncfusion) do this on the server and are a good fit if you are licensed and hosting Blazor Server. The lighter route, and the only one that also works from WebAssembly, is to render your component to an HTML string and post it to an API. On the server you can produce that HTML with the built-in HtmlRenderer, or simply point the API at a live route in your app.

using System.Net.Http.Headers;

var form = new Dictionary<string, string>
{
    ["url"] = "https://app.example.com/invoices/8842",
    ["format"] = "Letter",
    ["archive"] = "true",
};

var http = new HttpClient();
http.DefaultRequestHeaders.Authorization =
    new AuthenticationHeaderValue("Bearer", Environment.GetEnvironmentVariable("SITEPDF_KEY"));

var resp = await http.PostAsync(
    "https://api.sitepdf.com/v1/render", new FormUrlEncodedContent(form));
var doc = await resp.Content.ReadFromJsonAsync<RenderResult>();

The browser does the layout, so your CSS, web fonts, background colors and any JavaScript charts render exactly as they do on screen, and the PDF text stays selectable and searchable. Nothing runs a Chromium engine inside your own process, which keeps a WebAssembly app viable and a Server app light. Our HTML to PDF in C# guide covers the same call from a plain .NET server with the library options, and the PDF generator API page lists every parameter.

A generated invoice, contract or statement leaves your Blazor app and nothing verifiable stays with you. Add archive=true to the render call and Sitepdf also stores a timestamped, immutable snapshot of exactly what it rendered, retrievable by id later, so you can prove what a document said on a given date. For finance and compliance work that provenance is often the whole point of rendering server side. The website archiving page explains how the record works, and if you are weighing running your own headless Chromium instead, the Puppeteer alternative page runs that trade off honestly. Renders are transient by default; leave archiving off and we return the PDF and store nothing.