Introduction

CobaltPDF.WebKit renders HTML to PDF with WebKit instead of Chromium. It is drop-in API-compatible with CobaltPDF — the same CobaltEngine type, the same fluent methods, the same PdfDocument result. One CobaltPDF license key activates both libraries.

dotnet add package CobaltPDF.WebKit

using CobaltPdf.WebKit;                  // the only line that differs from CobaltPDF

var pdf = await new CobaltEngine()
    .WithPaperFormat("A4")
    .RenderUrlAsPdfAsync("https://example.com");
await pdf.SaveAsAsync("out.pdf");

Switching an existing CobaltPDF project is a one-line change: swap using CobaltPdf; for using CobaltPdf.WebKit; and recompile.

Why WebKit?

Memory, speed, and deployability.

On the benchmark workload — 10 warm renders of example.com, wikipedia.org/Portable_Document_Format, and news.ycombinator.com, steady RSS sampled after each render with the full subprocess tree included:

Metric	CobaltPDF (Chromium)	CobaltPDF.WebKit	Δ
Warm-mean render time	5,747 ms	2,456 ms	57% faster
Idle steady RSS	~310 MB	~14 MB	up to 96% less

And the deployment story is structurally different: instead of depending on system libraries (which Chromium needs installed via apt/yum, and which stock Azure plans cannot install), CobaltPDF.WebKit downloads a fully self-contained render bundle at first start — everything except glibc is inside. The result, validated on real Azure infrastructure:

	CobaltPDF (Chromium)	CobaltPDF.WebKit
Stock (code-only) Azure Functions Linux	❌ custom container required	✅ zip deploy works
Deployment artifact	~460 MB	~3 MB
Linux system packages	required	none
Typical peak memory	1.5–2.5 GB	0.3–1.3 GB

See Deployment for validated, step-by-step platform guides.

How it runs

• Linux (production) — renders natively in-process. The library provisions its bundle automatically; no Docker, no apt, no setup. This is the deployment target.
• Windows / macOS (development) — renders through a local Linux backend, selected automatically: WSL 2 (preferred), Docker Desktop, or an opt-in stub mode for tests. See Rendering Backends.

When to prefer the Chromium edition

WebKit is not Chromium — for the vast majority of HTML/CSS the output is visually equivalent, but if your workload depends on Chromium-specific rendering behaviour, Chrome DevTools-style debugging parity, or Windows-server production hosting, use CobaltPDF (Chromium). The shared PdfRequest wire model (CobaltPDF.Requests) lets you swap engines behind a service boundary without touching clients.