HTML to PDF for .NET. Chromium precision or WebKit performance.
CobaltPDF renders with Chromium for pixel-perfect fidelity, while CobaltPDF.WebKit renders with WebKit for a fraction of the memory. Two .NET libraries sharing one fluent C# API.
dotnet add package CobaltPdf
dotnet add package CobaltPdf.WebKit
* Free evaluation mode runs without a license key for as long as you need. Output is watermarked until a license is activated.
using CobaltPdf;
// Render a URL to PDF
await new CobaltEngine()
.RenderUrlAsPdfAsync("https://example.com")
.SaveAsAsync("website.pdf");
// Render an HTML string to PDF
await new CobaltEngine()
.RenderHtmlAsPdfAsync("<h1>Hello, World!</h1>")
.SaveAsAsync("hello.pdf");
// Render a local HTML file to PDF
await new CobaltEngine()
.RenderHtmlFileAsPdfAsync("invoice.html")
.SaveAsAsync("invoice.pdf");Pick the engine that
fits the job.
CobaltPDF and CobaltPDF.WebKit are two separate libraries that share the same fluent API, the same options, and the same license key. Use one, the other, or both side by side.
CobaltPDF
The full Chromium rendering stack. Every modern CSS feature, every JavaScript API — pixel-perfect to what you see in Chrome.
- Full HTML5 / CSS3 / Flexbox / Grid / web fonts
- Modern JavaScript — React, Vue, Angular, SPAs
- Warm browser pool for high-concurrency workloads
- Windows, Linux, Docker, Azure & AWS in production
dotnet add package CobaltPdf
CobaltPDF.WebKit
A lean WebKit-based renderer with the same fluent API at a fraction of the memory cost. Built for Linux containers and high-volume pipelines.
- Modern HTML5 & CSS3 — Flexbox, Grid, transforms
- Identical fluent API — a drop-in code swap
- Self-provisioning Linux bundle — no Docker, no apt
- The modern replacement for wkhtmltopdf
Linux-native engine. Runs in production on Linux x64/arm64 — Azure App Service, AKS, ECS/Fargate, any Ubuntu or Alpine container. Develop on Windows via WSL2 or Docker Desktop.
dotnet add package CobaltPdf.WebKit
* Measured across 10 warm renders of three public pages (example.com, Wikipedia, Hacker News): steady RSS ~14 MB (WebKit) vs ~310 MB (Chromium); warm-mean render 2.5 s vs 5.7 s. See the WebKit edition docs for methodology.
Same document.
A fraction of the RAM.
CobaltPDF.WebKit is engineered for density. On the same warm-render benchmark, the WebKit engine idles at ~14 MB steady RSS where Chromium holds ~310 MB — so the same host serves far more renderers.
- 57% faster warm-mean render times
- Built-in memory metrics on every render
- Same fluent code — just swap the
usingstatement - Same pooling, AES-256 encryption, watermarks & metadata
Switch engines in
one line of code.
Every fluent method, every option, every behaviour is shared between the two libraries. The only thing that changes is the using statement.
Drop-in compatible
Swap CobaltPdf for CobaltPdf.WebKit — same CobaltEngine type, same fluent methods. The rest of your code is unchanged.
Same fluent chains
.WithPaperFormat(), .WithHeader(), .WithWatermark(), .WithEncryption() — every fluent method works identically in both libraries.
Shared licensing
One license key, validated by both libraries. Existing CobaltPDF customers can adopt the WebKit edition at no extra cost.
One request model, either engine
CobaltPDF.Requests works with both libraries — the same serialized PdfRequest executes against a Chromium or WebKit rendering service.
using CobaltPdf;
var pdf = await new CobaltEngine()
.WithPaperFormat("A4")
.WithMargins(new MarginOptions(15, MarginUnit.Millimeters))
.WithHeader("<b>Q3 Report</b>")
.WithEncryption(new PdfEncryptionOptions
{
UserPassword = "user123",
OwnerPassword = "owner456"
})
.RenderUrlAsPdfAsync(reportUrl);
// Pixel-perfect Chromium renderingNo cold-start.
Just fast.
Spawning a new browser process for every PDF is expensive — often costing over a second before rendering even begins. Both CobaltPDF libraries keep a pool of warm renderer instances ready to go, so every request skips the cold-start tax entirely.
- Configurable pool with min/max renderer count
- Renderers recycled after N renders — no memory leaks
- Thread-safe: concurrent renders from one instance
-
Optional
PreWarmAsync()to eliminate first-request latency
A complete PDF toolkit.
In both libraries.
Everything you need to generate, secure, split, and customize PDFs — and it all works the same way in CobaltPDF and CobaltPDF.WebKit.
Full HTML5, CSS3, Flexbox, Grid, custom web fonts, and JavaScript — rendered by a real browser engine, Chromium or WebKit. @media print rules honored.
Dynamic HTML headers and footers with page number tokens, dates, and fully custom templates.
Inject cookies, localStorage, sessionStorage, and HTTP headers — render authenticated pages effortlessly.
AES-256 encryption with user/owner passwords and permission controls (print, copy, modify) — in both libraries.
Embed title, author, subject, keywords, and creator directly into the document properties.
Execute JS before capture — trigger lazy loaders, manipulate the DOM, or set application state.
Network idle, CSS selector, JS expression, fixed delay, or manual cobaltNotifyRender().
One-line setup for Docker, Azure App Service, AWS ECS/Fargate, Lambda, and bare-metal Linux — no manual browser flags.
Deploy as a standalone HTTP service with CobaltPDF.Requests — one request model that works with both engines.
Text or HTML watermarks with opacity, rotation, and position — or rasterize them into the page so they can't be deleted in a PDF editor.
Pull out single pages or page ranges, split any PDF into one file per page, or merge documents back together — works on any PDF, even ones CobaltPDF didn't create.
Flatten a watermark into the page pixels with .WithRasterize() — no selectable text, no deletable object.
Load fonts from disk before rendering so PDFs display correctly on servers without those fonts installed.
A fluent API that
reads like prose.
Every option chains. Every method has a sensible default. No XML config, no boilerplate, no ceremony — just clean, readable code that renders exactly what you mean, in either library.
var pdf = await new CobaltEngine()
.WithPaperFormat("A4")
.WithMargins(new MarginOptions(15, MarginUnit.Millimeters))
.WithHeader("<b>Q3 Report</b>")
.WithFooter("Page <span class='pageNumber'/>")
.WithEncryption(new PdfEncryptionOptions { UserPassword = "user123", OwnerPassword = "owner456" })
.WithMetadata(m => {
m.Title = "Q3 Financial Report";
m.Author = "Finance Team";
})
.RenderUrlAsPdfAsync(reportUrl);
await blobStorage.UploadAsync(pdf.BinaryData);Pick the engine that
matches your workload.
Most teams pick one and stay there. A few mix both. Either way, your license covers it.
Choose CobaltPDF (Chromium)
- Branded reports, dashboards, marketing PDFs
- Bleeding-edge CSS and modern JavaScript frameworks
- Pages that must match Chrome pixel for pixel
- Production on Windows servers or IIS (also runs on Linux)
- You're already on CobaltPDF — nothing changes
Choose CobaltPDF.WebKit
- Thousands of invoices, receipts, or statements per hour
- Memory on Lambda / Fargate / App Service hurts your bill
- Production on Linux containers — Docker, Kubernetes, serverless
- You're replacing wkhtmltopdf with a maintained, modern engine
- Windows devs welcome — develop via WSL2 or Docker Desktop
Why developers choose CobaltPDF
A side-by-side look at what matters in production.
| Feature | CobaltPDF | PuppeteerSharp | wkhtmltopdf | iTextSharp |
|---|---|---|---|---|
| Modern CSS support | ✓ | ✓ | ✗ | ✗ |
| Choice of engine (Chromium or lightweight WebKit) | ✓ | ✗ | ✗ | ✗ |
| Browser pool (no cold-start) | ✓ | ✗ | ✗ | ✗ |
| Fluent .NET API | ✓ | Partial | ✗ | Partial |
| Engine bundled via NuGet | ✓ | ✗ | ✗ | ✗ |
| Cookie & auth injection | ✓ | ✓ | Limited | ✗ |
| PDF encryption (AES-256) | ✓ | ✗ | Limited | ✓ |
| Split, extract & merge pages | ✓ | ✗ | ✗ | ✓ |
| Cloud environment presets | ✓ | ✗ | ✗ | ✗ |
| Microservice support | ✓ | ✗ | ✗ | ✗ |
| Actively maintained | ✓ | ✓ | ✗ archived | ✓ |
Two libraries, one license —
the obvious questions.
Do I need to buy two licenses to use both libraries?
No. One CobaltPDF license key activates both libraries. CobaltPDF and CobaltPDF.WebKit are separate NuGet packages, but they validate the same product key. Existing customers can install CobaltPdf.WebKit today with their current key, and renewals cover both automatically.
If WebKit uses a fraction of the memory, why would I ever use Chromium?
Two reasons. First, fidelity — Chromium is the engine behind Chrome and Edge, so anything that looks right in Chrome renders identically. WebKit covers the modern web well, but bleeding-edge CSS and complex JavaScript-driven UIs are safest on Chromium. Second, native Windows production — if your servers run Windows or IIS, choose CobaltPDF (Chromium). The WebKit edition's production target is Linux.
Does CobaltPDF.WebKit run on Windows?
For development, yes — on Windows it renders through WSL2 or Docker Desktop automatically, with no extra configuration. For production, the WebKit engine targets Linux (which is where most modern .NET workloads deploy anyway — Docker, Kubernetes, Linux App Service, ECS/Fargate). If you need native Windows production, use CobaltPdf (Chromium). One license covers either path.
Can I use both libraries in the same project?
Yes. Install both NuGet packages side by side and route each render to whichever engine fits — fidelity-critical work to Chromium, high-volume work to WebKit. The fluent API is identical, so the only difference is which using namespace you import. And because CobaltPDF.Requests works with both libraries, the same serialized PdfRequest can execute against either rendering service.
Will my existing CobaltPDF code break if I switch to WebKit?
No. CobaltPDF.WebKit is a drop-in, API-compatible library — the same CobaltEngine type, the same fluent methods, the same options. Change one using statement and recompile. The only differences you may see are in rendering output for bleeding-edge web features.
Which engine should I start with?
If you're not sure, start with CobaltPDF (Chromium) — it handles everything and runs natively on Windows and Linux. If you later find memory cost is your bottleneck on Linux, swap one using statement for WebKit and you're done. Both run free in evaluation mode, so you can benchmark them on your own documents before buying.
Start rendering PDFs
in minutes.
Both libraries run free, unlimited, in evaluation mode — watermarked output until you activate. One key unlocks both.