Gotenberg vs WeasyPrint
These two answer different questions. Gotenberg runs a real Chromium, so it renders web pages exactly: JavaScript executed, web fonts loaded, flexbox and grid intact. WeasyPrint is a pure-Python print engine with excellent paged-media CSS but no JavaScript, so it prints authored documents beautifully and cannot render a web app faithfully. Pick by what you are printing.
Gotenberg vs WeasyPrint: what each one is
Gotenberg: REST API in one Docker container, MIT license; the browser-vs-print split below is about WeasyPrint's engine, not its API. Engine: headless Chromium (plus LibreOffice for office files). Ops: you run the container: upgrades, scaling, retries. Cost: free license, your infrastructure. Best for web apps, SPAs, anything client-rendered.
WeasyPrint: pure-Python HTML/CSS to PDF engine, BSD licensed. Engine: its own print engine, no browser. Ops: a pip dependency inside your Python process. Cost: free license, your process. Best for authored print documents where paged-media CSS is the requirement and the HTML never runs script.
Gotenberg vs WeasyPrint at a glance
| Aspect | Gotenberg | WeasyPrint |
|---|---|---|
| Engine | Chromium | print engine |
| Hosting | your Docker | your Python process |
| JavaScript | executed | not executed |
| Web fonts | loaded from CSS | loaded from CSS @font-face, with API setup |
| Modern CSS | yes | partial (print CSS strong, screen CSS weak) |
| Ops burden | container lifecycle | library dependency |
| Cost basis | infra only | infra only |
| Best for | live web pages | authored documents |
The engines answer different questions: pages vs documents.
The verdict: when each one wins
Gotenberg wins: pages a browser has to render first: dashboards, invoices from your app, anything with script.
WeasyPrint wins: documents authored for print where page headers, footnotes, and running elements matter more than JavaScript.
Neither wins: teams that want neither container ops nor a Python dependency in the render path: that is the hosted route, which is what webcapture sells (same Chromium as Gotenberg, ops on us, per-document pricing at our published pricing).
How this connects
The Python migration page covers the same choice from the escape side: when to leave WeasyPrint for a browser engine. The migration hub maps the archived binary flag by flag.
Wider than this pair: the capability matrix reads eight vendors across fourteen rows, each cell sourced from the vendor's own docs.
Going deeper: the formatting guide explains what each engine class preserves and what it drops, the open-source comparison prices the free routes against hosted ones, and the webcapture product page keeps the hosted engine, prices, and quick start on one page.
Frequently asked questions
Does WeasyPrint run JavaScript?
No. WeasyPrint is a pure-Python print engine: it never executes page script, so a client-rendered page prints without the content the script would have added.
Is WeasyPrint good for web pages?
For authored documents, yes, and its paged-media CSS is excellent. For live web pages, no: flexbox, grid, and JavaScript-rendered content need a browser engine.
Can Gotenberg print office documents?
Yes. Gotenberg bundles LibreOffice alongside Chromium, so .docx, .xlsx, and .pptx conversions ride the same container.
More comparisons: Gotenberg vs Puppeteer, Gotenberg vs LibreOffice, Puppeteer vs wkhtmltopdf, webcapture vs PDFShift.
Method
Checked 2026-09-11: the WeasyPrint documentation (no JavaScript support, paged-media features) and the engines listed in the Gotenberg repository.
Render your first page in seconds
Mint a key, POST a URL, and the finished document comes back in the same response; pass ?wait=false for a job ticket with poll and download URLs. The first 50 renders a month are free, and there is no credit card. Not ready for a key? The free URL to PDF tool renders public pages without one.