Render PDFs from any app.
No browser on the client.
Run CobaltPDF once as a PDF rendering service, then call it from anywhere. Your web app, mobile backend, or serverless function installs only CobaltPDF.Requests — a ~50 KB package of plain JSON models with no Chromium and no engine — and POSTs a request. The service does the rendering and streams back a PDF.
Every app that needs a PDF bundles the full engine and a headless browser. Your slim web API or Lambda balloons by hundreds of MB, cold-starts slow down, and you maintain Chromium system libraries in places they don't belong.
One service owns the engine. Every client ships a ~50 KB models package, builds a
PdfRequest, and POSTs JSON. No browser, no native libraries, no bloat — and you
scale rendering independently of the apps that consume it.
One service. Many lightweight clients.
The client never touches a browser — it just speaks JSON over HTTP.
- Builds a
PdfRequest - No Chromium
- No engine
PdfRequest as JSON
-
request.ExecuteAsync(engine) - Warm browser pool
- Chromium or WebKit engine
PdfRequest
renders on a service backed by CobaltPDF (Chromium) or CobaltPDF.WebKit — clients
never need to know which engine is on the other end.
From client call to PDF.
Build a request
The client creates a PdfRequest — a URL or HTML plus any options (margins, header/footer,
watermark, encryption, cookies). Object initializer or the fluent PdfRequest.ForUrl(...).Build() builder.
POST it as JSON
Send the request to your service over HTTP. It's a plain JSON body, so any language can call the service — C#, TypeScript, Python, anything that speaks HTTP.
Render & return
The service calls request.ExecuteAsync(engine), which maps every property onto the
fluent API, renders with the warm pool, and returns the PDF — as raw bytes or a JSON PdfResponse.
The whole thing, end to end.
# Client app — web API, mobile backend, worker, Lambda
dotnet add package CobaltPDF.Requests
# Rendering service — CobaltPDF.Requests is included automatically
dotnet add package CobaltPDF # or: CobaltPDF.WebKit
using CobaltPdf.Requests;
using System.Net.Http.Json;
// fluent builder (1.6.0+) or an object initializer
var request = PdfRequest.ForUrl("https://myapp.com/invoice/42")
.WithPaperFormat("A4")
.WithHeader("<div>My Company</div>")
.WithMetadata(m => m.Title = "Invoice #42")
.Build();
var resp = await http.PostAsJsonAsync(
"https://pdf-service/api/pdf", request);
resp.EnsureSuccessStatusCode();
byte[] pdf = await resp.Content.ReadAsByteArrayAsync();
await File.WriteAllBytesAsync("invoice.pdf", pdf);
using CobaltPdf;
using CobaltPdf.Requests;
builder.Services.AddCobaltPdf(o =>
CloudEnvironment.ConfigureForDocker(o));
var app = builder.Build();
await CobaltEngine.PreWarmAsync();
// ExecuteAsync maps the request onto the fluent API
app.MapPost("/api/pdf", async (
PdfRequest request,
CobaltEngine renderer,
CancellationToken ct) =>
{
var pdf = await request.ExecuteAsync(renderer, ct);
return Results.File(pdf.BinaryData, "application/pdf");
});
app.Run();
Made for these jobs.
Centralised PDF rendering
Many apps need PDFs; one team owns and scales the rendering service instead of every app shipping a browser.
Slim clients & serverless
Keep web APIs, Lambdas, and mobile backends tiny and fast-starting — no Chromium, no native libraries.
Polyglot stacks
Front-ends and services in TypeScript, Python, Go or anything else call the same JSON endpoint.
Independent scaling
Rendering is CPU- and memory-heavy; scale the service on its own metrics, separate from your apps.
Stand up a PDF service in an afternoon.
The package is free and the model is tiny. Deploy the service on Docker, Azure, or AWS, point your clients at it, and you're done.