Alternatives
Moving off WeasyPrint
A Python library with its own layout engine, written for paged media rather than adapted from a browser. It implements CSS Paged Media properly and is actively maintained — a better-engineered answer to this problem than most.
Why teams move
- It runs in your process. Rendering a long report is CPU-bound work inside the application handling the request, so document generation and request latency share a budget.
- It is Python-only. A second service in Go or Node cannot call it without you first wrapping it in a service of your own.
- Designs live in HTML and CSS that somebody has to maintain, and the people who care most about how an invoice looks are usually not the people comfortable editing that CSS.
- Sitting between a browser and a typesetter, it supports much of CSS but not all of it, and finding the edge is a per-document discovery.
Side by side
Three properties that do not change week to week. No price columns and no feature checkmarks — those go stale quietly, and a comparison that misstates the other tool is worse than none.
| WeasyPrint | pdfs.build | |
|---|---|---|
| What you author | HTML and CSS, against a real paged-media implementation. | A design with a schema, edited in plain English. |
| What decides page breaks | CSS Paged Media — genuinely implemented, not emulated. | The design states them, so the answer is readable without running it. |
| As the data grows | Handled correctly. The engine is yours to host, upgrade and tune. | Handled correctly, and hosted. The trade is control for operations. |
The checkable parts
Claims worth verifying rather than taking on trust — each links to its source, checked September 2026.
-
Uses its own layout engine, not WebKit or Gecko; written in Python, requires 3.10+.
WeasyPrint documentation ↗ -
Does not execute JavaScript — documents are rendered from HTML and CSS as given.
WeasyPrint documentation ↗
What is different here
Reachable from any stack
An HTTPS endpoint answers the same way from Go, Node, Ruby, PHP or a workflow tool. Nothing has to be wrapped to be shared.
Rendering leaves your process
A hundred-page report does not compete with your web workers for CPU, and render throughput scales independently of the app serving your users.
Editable without touching CSS
Templates are changed through an assistant that reads and writes the template, its schema and its sample data — so a layout change does not have to become a pull request.
When to stay with WeasyPrint
It is often the right answer. If any of these describe you, this is not a migration worth making.
- You are Python end to end, rendering volume is modest, and in-process is a feature rather than a constraint.
- You want no third-party service in the document path at all — an actively maintained library you control is the stronger position.
- Your team is comfortable in CSS Paged Media and already has the layouts working.
What moving involves
- 1 The closest migration of the three. The paged-media concepts carry over directly — running headers, page breaks and margin boxes all have counterparts.
- 2 The context dictionary you render templates with becomes the JSON payload, usually one-to-one.
- 3 Worth keeping WeasyPrint for anything already working. These are not mutually exclusive, and there is no prize for a single renderer.
The API reference covers authentication, the render call and error handling; the template gallery has designs to start from rather than a blank page.
Other migrations
Render one and compare
Free tier includes 2 templates and 50 watermarked PDF renders per month. No credit card required.
Start building free