HTML to PDF in C# and .NET, without a paid library
The .NET options for HTML to PDF split into two camps: commercial libraries with per-developer licenses and bundled rendering engines, or free wrappers around the archived wkhtmltopdf binary that choke on CSS Grid and Flexbox. pdfkitt is the third path — real Chromium rendering behind an API, so your app makes one HttpClient call and ships no rendering engine at all.
One HttpClient call
No NuGet rendering package, no Chromium download, no license key. Send HTML, get PDF bytes back.
using var http = new HttpClient();
http.DefaultRequestHeaders.Authorization =
new AuthenticationHeaderValue("Bearer",
Environment.GetEnvironmentVariable("PDFKITT_API_KEY"));
var response = await http.PostAsJsonAsync(
"https://api.pdfkitt.dev/v1/convert",
new
{
html = "<h1>Invoice</h1>",
options = new { page_size = "A4" },
});
response.EnsureSuccessStatusCode();
await File.WriteAllBytesAsync("invoice.pdf",
await response.Content.ReadAsByteArrayAsync());Razor views become PDFs unchanged
If your invoice already exists as a Razor view, render it to a string and send it — the PDF matches what the browser shows, including CSS Grid, Flexbox, web fonts, and print CSS like @page margins.
// ASP.NET Core: render a Razor view to an HTML string first,
// then POST that string. Any view your app already serves can
// become a PDF without changing its markup.
var html = await razorRenderer.RenderViewToStringAsync(
"Invoices/Show", invoiceModel);When a local library still makes sense
If you need to manipulate existing PDFs — merge, split, sign, fill forms — a library like PdfSharp or iText is the right tool, and air-gapped environments rule out any API. For generating documents from HTML in a connected app, the API path removes the license cost, the engine updates, and the deployment weight. See the wkhtmltopdf comparison for the legacy-engine details, or jump to the API docs.
FAQ
Why not use IronPDF, Syncfusion, or Aspose?
They are solid libraries, but all three require a commercial license for production use, ship a bundled Chromium or custom engine you must keep updated, and add hundreds of megabytes to your deployment. If your only need is turning HTML into a PDF, a metered API replaces the license fee and the binary weight with one HttpClient call.
What about free options like wkhtmltopdf wrappers or HtmlRenderer.PdfSharp?
wkhtmltopdf was archived in 2023 and is frozen on a 2012-era WebKit engine - no CSS Grid, patchy Flexbox. HtmlRenderer.PdfSharp implements its own HTML subset and falls over on modern layouts. Both work for simple documents; both hit a wall on real invoice and report markup. pdfkitt renders with current Chromium.
How does this compare to running PuppeteerSharp or Playwright for .NET myself?
PuppeteerSharp and Playwright render correctly because they drive real Chromium - but that means downloading a browser at deploy time, installing its Linux dependencies in your container, and owning pooling, retries, and memory when it misbehaves. pdfkitt runs the same Chromium on our side, behind a warm pool, so your app stays a plain HTTP client.
Can I convert Razor views or Blazor components?
Yes. Render the view to an HTML string server-side - RenderViewToStringAsync in ASP.NET Core MVC, or HtmlRenderer in .NET 8+ for Blazor components - and POST the result. Whatever the markup looks like in a browser is what the PDF looks like.
Does it execute JavaScript in my HTML?
Not by default. Static HTML and CSS render as-is. If your page needs its scripts to run - client-rendered charts, SPAs - set javascript: true in the request and the page runs in sandboxed Chromium before capture, with a 30-second cap per render.
Is my HTML stored anywhere?
No. HTML is processed in memory to render the PDF and is never written to storage or logs. Only request metadata such as timing and status is recorded.
Try pdfkitt free — 1,000 PDFs/month, no credit card
Get an API key and send your first PDF in minutes.