Django HTML to PDF: Convert a Django Template to a Real PDF

Django deliberately leaves PDF generation to you, so the question is never "which Django feature" but "which rendering engine". There are really three families. The first is WeasyPrint, usually wired in with django-weasyprint: it reads your HTML and CSS and produces a print-quality PDF entirely in Python, with no browser involved. The second is the ReportLab family, where xhtml2pdf converts a limited subset of HTML on top of ReportLab, and ReportLab itself lets you draw the document in code. The third is a headless browser, either one you run yourself with Playwright, or a hosted rendering API, which is the only route that runs your JavaScript and matches a real browser exactly.

The line that matters runs between "a browser renders it" and "a library renders it". A library like WeasyPrint is fast, free and has no browser to babysit, but it will never run the JavaScript that draws a Chart.js graph, and its CSS support, while good, is a subset of what Chromium does. A browser runs everything your users see, at the cost of being a browser: memory, cold starts and scaling. Picking the right option is mostly about whether your document depends on JavaScript and how close to the on-screen page it has to look.

For a server-rendered invoice, statement or report, WeasyPrint is hard to beat on price and simplicity. You render the template to a string and hand it over, and you get clean PDF bytes back with real, selectable text.

from django.template.loader import render_to_string
from weasyprint import HTML

html = render_to_string("invoices/invoice.html", {"invoice": invoice})
pdf = HTML(string=html, base_url=request.build_absolute_uri()).write_pdf()
return HttpResponse(pdf, content_type="application/pdf")

Two things trip people up. Pass base_url so WeasyPrint can resolve your static CSS, images and fonts, and remember that its layout comes from print CSS, so use the @page rule for margins and page size. The hard limit is JavaScript: WeasyPrint has no JavaScript engine, so a page that builds a chart, a table or a map in the browser will render blank or half-formed. The official advice is to render that data to static HTML or SVG on the server first, or move to a headless-Chrome pipeline. If your documents are pure server-side HTML and CSS, none of that applies and WeasyPrint is the right call. As of its February 2026 release it needs Python 3.10 or newer, plus the Pango and Cairo system libraries on every machine that runs it.

When the page has JavaScript, or you simply want the PDF to look exactly like the page in Chrome, let a real browser do the work. You do not have to change how Django builds the page. Render the template to a string as usual, then post that HTML to the render endpoint, or point it at a live route in your app and let it load the page, run the JavaScript and wait for the charts.

from django.template.loader import render_to_string
import requests

html = render_to_string("invoices/invoice.html", {"invoice": invoice})

resp = requests.post(
    "https://api.sitepdf.com/v1/render",
    headers={"Authorization": f"Bearer {settings.SITEPDF_KEY}"},
    data={"html": html, "format": "Letter", "archive": "true"},
)
pdf_url = resp.json()["pdf_url"]

Because a current browser does the layout, your CSS grid, web fonts, background colors and JavaScript-drawn charts all render the way they do on screen, and the text stays real and searchable. There is no Pango, Cairo or Chromium to install in your image and no browser process eating memory inside your Django workers. The same call works from Celery for background jobs and from a management command for batch runs. Our HTML to PDF in Python guide shows the plain requests version outside Django, and the PDF generator API page lists every parameter, including margins, page size, headers and the wait signal for charts.

A generated invoice, a signed quote or a compliance report leaves your app and nothing verifiable stays behind. Add archive=true to the render call and Sitepdf also stores a timestamped, immutable snapshot of exactly what it rendered, retrievable by id later, so you can prove what a given document said on a given date. That provenance is often the reason to render server side at all. The website archiving page explains how the record works, and the Laravel HTML to PDF page walks the same trade offs for the other big server framework. Renders are transient by default; leave archiving off and we return the PDF and store nothing.