Generate a PDF from HTML in n8n: there is no native node, and the three paths that actually work

27 August 2026 · tested on n8n Cloud and self-hosted

n8n has no built-in way to turn HTML into a PDF. The Convert to File node handles JSON, CSV, text, XML, base64 and iCal — none of which involves rendering a page. There is no rendering engine in n8n, which is why every answer you find points somewhere else.

This page lays out the three real options, with the trade-off of each one stated plainly, and the importable workflow for the fastest of them. We sell one of the three, and we say which — but the other two are here properly, because a comparison that hides the free option is not worth reading.

The three paths

Path 1 — Gotenberg, self-hosted

Gotenberg wraps Chromium and LibreOffice in a container with an HTTP interface. It is genuinely free and genuinely good, and if you already run infrastructure it is the honest first choice.

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

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

What it costs you is not the licence, it is the operation: keeping the container up, patching it, giving it memory, and discovering on a Sunday that a font is missing inside it. If that is work you already do for other things, the marginal cost is close to zero and you should stop reading here.

Path 2 — Community node

Several vendors ship community nodes for this. They install cleanly and give you a dedicated node in the editor, which is pleasant.

We looked at what people actually use. Across 382 published workflows in the n8n template library that produce a document or an image, there are 3,650 node instances and not one community node — every single one uses the built-in HTTP Request. That is not an argument that community nodes are bad. It is evidence about where the shared, portable workflows end up.

Path 3 — HTTP Request to a rendering API

This is the path that works everywhere, needs no installation, and survives being exported and shared: the node is built into n8n, so anyone who imports your workflow can run it.

Configuring the node

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

The response carries a URL to the finished file, which you pass straight into a Google Drive, S3, email or Slack node.

{
  "template": "<h1>Invoice {{ $json.number }}</h1>",
  "data": { "number": "2026-014" },
  "format": "A4"
}

The four things that break, and that no forum thread explains

Getting a PDF out is the easy half. These are where people get stuck after the first success.

1. Page breaks

A table that spills across pages will cut a row in half unless you tell it not to. This is plain CSS and it works in any Chromium-based renderer:

tr, .keep-together { break-inside: avoid; }
.new-page { break-before: page; }
thead { display: table-header-group; }   /* repeats the header on every page */

That last line is the one people miss. Without it, a five-page invoice has column headers only on page one.

2. Fonts that vanish on the server

Your layout is perfect locally and wrong in the PDF, because the rendering machine does not have your font. Do not link to a font CDN either — that makes every render wait on the network, and the wait counts against the timeout.

Embed the font as a data URI:

@font-face {
  font-family: 'Inter';
  src: url(data:font/woff2;base64,d09GMgABAAAAA…) format('woff2');
}

3. Margins, headers and footers

Set @page { margin: 0 } and control the spacing inside your own body padding. Mixing the API's margin option with CSS margins is how you get a document that looks right in the browser and wrong in the file.

4. Returning the PDF from a Webhook

This is the one the forums answer badly. If your workflow is triggered by a Webhook and you want to return the file itself, you need a Respond to Webhook node set to Binary, fed by an HTTP Request node that downloaded the file with Response Format: File. Returning the JSON with the URL is usually better — it is smaller, it does not hold the connection open, and the caller can fetch the file when convenient.

Which one should you pick

If you run your own infrastructure and enjoy it: Gotenberg. It is free, it is good, and the operational cost is real but already paid.

If you are on n8n Cloud: the community node is not available to you, so it is Gotenberg on a server you manage, or an API.

If you want the workflow to be importable by other people without them installing anything: HTTP Request, which is why every shared workflow in the library ends up there.

Questions people ask

Related guides

• PDF generation in n8n: every method that works
• HTML to PDF with the HTTP Request node
• Generating invoice PDFs from an API