PDF generation in n8n: every method that works, and what each one costs you

27 August 2026 · five methods, tested · updated when they change

n8n cannot render a PDF on its own. There is no rendering engine inside it — the Convert to File node produces JSON, CSV, text, XML, base64 and iCal, and none of those involve drawing a page. Every working approach therefore brings the rendering from somewhere else, and the five ways of doing that differ enormously in what they cost you.

This page covers all five, including the free ones that compete with us. We sell one of them; it is marked. If your case fits a free method better, use the free method — you will find that out here rather than after a month of paying for something you did not need.

The five methods at a glance

1. Google Docs or Slides as a template

Make a document with placeholders, copy it per run, replace the text, export as PDF. Entirely inside the Google nodes, no extra service, no cost.

Use it when the document is mostly prose with a few variables — a letter, a simple statement, a one-page summary — and nobody will ask for a design change next quarter.

Where it stops. Precise tables, repeating headers across pages, exact fonts, page numbering, anything that has to match a brand: the Docs API was not built for layout control, and each of those turns into a fight. Teams usually start here, ship, and move when someone asks for a proper invoice.

2. Gotenberg, self-hosted

Gotenberg wraps Chromium and LibreOffice behind an HTTP interface. Free, open source, and genuinely good — this is the honest first choice if you already run infrastructure.

docker run --rm -p 3000:3000 gotenberg/gotenberg:8

From n8n, an HTTP Request node posting multipart/form-data to /forms/chromium/convert/html, with your HTML as a file field named index.html.

What it costs is not the licence, it is the operation. Roughly a gigabyte of image, a container to patch, memory to allocate, and the Sunday you discover a font is missing inside it. If you already run containers with monitoring and backups, that marginal cost is near zero and you should stop reading. If this would be the only container you run, you have just adopted a small server to avoid a small bill.

3. Code node with a JavaScript library

Libraries like pdf-lib or pdfmake build a PDF programmatically, without a browser. On self-hosted n8n you can allow external modules and call them from a Code node.

Use it when the document is generated rather than designed — a label, a barcode sheet, a fixed-format report where you place elements by coordinate.

Where it stops. There is no browser, so there is no CSS. You are positioning elements, not styling a page, and a designer cannot help you. On n8n Cloud it is not available at all, because you cannot enable external modules.

4. Community node

Several vendors publish dedicated nodes. They install cleanly and give you a proper node in the editor.

We counted what people actually ship. Across 382 workflows in the public n8n template library that produce a document or an image, there are 3,650 node instances and zero community nodes. Every one uses the built-in HTTP Request. That is not a verdict on quality — it is what happens when a workflow has to survive being exported and imported by someone else.

5. HTTP Request to a rendering API what we sell

The node ships with n8n, so it runs on Cloud and self-hosted, and anyone can import your workflow and use it without installing anything. You post the HTML and the data, you get a file back.

• Method: POST · URL: https://emitforge.com/v1/pdf
• Authentication: Generic Credential Type → Header Auth, Name Authorization, Value Bearer YOUR_KEY
• Body: JSON, with template and data

The response carries a signed URL, which goes straight into a Drive, S3, Gmail or Slack node. Full detail in the HTTP Request guide.

What it costs is money and a dependency on someone else's uptime. There are many vendors; we are one of them, we are new, and we say so further down.

Which one fits your case

What breaks in every method, and how to fix it

These apply whichever renderer you pick, because they are properties of print layout rather than of any product.

Table headers vanish after page one

thead { display: table-header-group; }

Chromium then repeats the header on every page. Almost nobody sets this, and it is the single most common complaint about generated invoices.

Rows get cut in half at the page break

tr, .keep-together { break-inside: avoid; }
.new-page { break-before: page; }

The font is wrong on the server

The rendering machine does not have your local fonts. Linking a font CDN is worse than it looks: every render then waits on the network, and that wait counts against whatever timeout your method has. Embed as a data URI and the problem disappears permanently.

Margins fight each other

Set @page { margin: 0 } and control spacing with your own body padding. Mixing a renderer's margin option with CSS margins produces a file that looks right in the browser and wrong on paper.

Returning the file from a Webhook

Use a Respond to Webhook node in Binary mode, fed by an HTTP Request with Response Format: File. Or return the JSON with the URL, which is usually better: smaller response, no held-open connection, and the caller fetches the file when it suits them.

Questions

Related guides

• Generate PDF from HTML in n8n: the three paths
• HTML to PDF with the HTTP Request node
• Generating invoice PDFs from an API