Microservice Mode

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.

Without a service

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.

With Microservice Mode

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.

How it fits together

One service. Many lightweight clients.

The client never touches a browser — it just speaks JSON over HTTP.

The request model is engine-agnostic. The same serialized PdfRequest renders on a service backed by CobaltPDF (Chromium) or CobaltPDF.WebKit — clients never need to know which engine is on the other end.
Three moving parts

From client call to PDF.

1

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.

2

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.

3

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.

Two small files

The whole thing, end to end.

Install
# 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
Client.cs — send a request
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);
Program.cs — the service
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();
The wire format is just JSON, so the client doesn't have to be .NET. Any language can POST a request — see the TypeScript and Python examples in the docs.
Reach for it when

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.