n8n HTML to PDF: generate PDFs in your workflows

24 July 2026

n8n has no built-in HTML to PDF node, but you have four working options: a community node, a self-hosted Gotenberg container, a vendor-specific node, or (most robust) the built-in HTTP Request node calling an HTML to PDF API. The HTTP Request route works on both n8n Cloud and self-hosted instances, needs no node installation, and takes about five minutes; the importable workflow JSON is below.

If you searched for an "n8n html to pdf node," you've probably already opened the nodes panel and found nothing. You're not missing it. PDF generation simply isn't in n8n's core node set, and the community's answers are scattered across forum threads, single-vendor templates, and GitHub repos of varying health.

This guide compares all four routes honestly: what each one requires, where each one breaks, and which n8n plans each works on. You'll leave with a working workflow that accepts HTML via webhook, renders a PDF, and drops it wherever your automation needs it.

Key TakeawaysThere is no built-in n8n HTML to PDF node. The four working routes are community nodes, self-hosted Gotenberg, vendor nodes, and the HTTP Request node calling a PDF API.The HTTP Request route is the most portable: it works on n8n Cloud and self-hosted alike, with no node installation and no container to run.Unverified community nodes only install on self-hosted n8n (n8n Cloud runs verified ones only), and at least one popular option wraps wkhtmltopdf, an engine archived since 2023 with unpatched CVEs.Gotenberg is the best fully-self-hosted option, at the cost of running and updating one more Docker container.An importable workflow JSON (Webhook → HTTP Request → binary PDF) is included below; paste it into n8n and add your API key.

Is there an n8n HTML to PDF node?

No. n8n ships no core node for HTML to PDF conversion. Your options are installing a community node (verified ones on n8n Cloud, any of them self-hosted), running a conversion service like Gotenberg alongside n8n, or using the built-in HTTP Request node to call an HTML to PDF API, which works on every n8n plan without installing anything.

That last sentence explains why this guide leads with the HTTP Request approach. Everything else comes with a deployment precondition; the HTTP Request node is already in your palette.

The pattern is simple: your workflow assembles HTML (from a template, a form submission, a database row), one HTTP Request node POSTs it to a rendering API, and the response comes back as a binary PDF file that any downstream node can use.

The workflow, step by step

  1. Webhook node (or any trigger): receives the data, for example an order that needs an invoice.
  2. HTTP Request node: sends the HTML to the API and receives the PDF.
  3. Output node: Google Drive, Gmail attachment, S3, or a Respond to Webhook node that returns the PDF to the caller.

Configuring the HTTP Request node

Using Transformy's HTML to PDF API as the example (any API with a JSON-in, PDF-out contract works the same way):

  • Method: POST
  • URL: https://api.transformy.io/v1/pdf/chrome
  • Authentication: Generic Credential Type → Header Auth. Name: Authorization, value: Bearer YOUR_API_KEY.
  • Body: JSON, for example:
{
  "html": "{{ $json.invoiceHtml }}",
  "page_size": "A4",
  "margin": "20mm 15mm",
  "footer": { "html": "<span style=\"font-size:9px\">Page {{page}} of {{pages}}</span>" }
}
  • Response format: File. This is the step most forum threads stumble on: without it, n8n treats the PDF bytes as text and the file corrupts. With it, the PDF lands in the item's binary data, ready for any attachment or upload field.

The rendering happens on real headless Chromium, so CSS, webfonts, and page-break rules behave the way they do in a browser; the HTML to PDF API docs list every parameter, including URL mode for converting live pages.

Importable workflow JSON

Paste this into n8n (Workflow menu → Import from Clipboard), then set your API key in the HTTP Request node's credentials:

{
  "name": "HTML to PDF via API",
  "nodes": [
    {
      "parameters": { "httpMethod": "POST", "path": "html-to-pdf", "responseMode": "responseNode" },
      "name": "Webhook",
      "type": "n8n-nodes-base.webhook",
      "typeVersion": 2,
      "position": [0, 0]
    },
    {
      "parameters": {
        "method": "POST",
        "url": "https://api.transformy.io/v1/pdf/chrome",
        "sendHeaders": true,
        "headerParameters": { "parameters": [ { "name": "Content-Type", "value": "application/json" } ] },
        "sendBody": true,
        "specifyBody": "json",
        "jsonBody": "={{ JSON.stringify({ html: $json.body.html, page_size: 'A4' }) }}",
        "options": { "response": { "response": { "responseFormat": "file" } } }
      },
      "name": "Render PDF",
      "type": "n8n-nodes-base.httpRequest",
      "typeVersion": 4.2,
      "position": [220, 0]
    },
    {
      "parameters": { "respondWith": "binary" },
      "name": "Respond with PDF",
      "type": "n8n-nodes-base.respondToWebhook",
      "typeVersion": 1.1,
      "position": [440, 0]
    }
  ],
  "connections": {
    "Webhook": { "main": [[ { "node": "Render PDF", "type": "main", "index": 0 } ]] },
    "Render PDF": { "main": [[ { "node": "Respond with PDF", "type": "main", "index": 0 } ]] }
  }
}

Add the Authorization header via a Header Auth credential after import (never hard-code keys in workflow JSON; exported workflows get shared). POST any { "html": "<h1>Hello</h1>" } payload to the webhook URL and a PDF comes back.

Option 2: community nodes

The n8n community has published HTML to PDF nodes, including vendor nodes (PDFMunk's, for example) and generic wrappers. Two caveats apply to all of them.

First, community nodes install on self-hosted n8n; n8n Cloud only runs nodes that have passed n8n's verification. If you're on Cloud, most of these aren't available to you at all.

Second, a community node is a dependency you're trusting with your workflow data, and its engine matters. One of the ranking options wraps wkhtmltopdf, an engine whose repository was archived in January 2023 and which carries an unpatched 9.8-severity SSRF vulnerability (CVE-2022-35583). It also requires the wkhtmltopdf binary installed on your n8n host, which rules out most managed deployments anyway. If you're evaluating anything wkhtmltopdf-shaped, our wkhtmltopdf alternatives comparison explains why migrating forward beats wrapping the old engine.

Community nodes make sense when you self-host, you've vetted the specific node, and its engine is a maintained one.

Option 3: self-hosted Gotenberg

Gotenberg is an open-source Docker service that wraps headless Chromium behind an HTTP API. Run the container next to your n8n instance, and an HTTP Request node can POST HTML to http://gotenberg:3000/forms/chromium/convert/html and get a PDF back, no API key, no per-document cost.

The tradeoff is operational: you now run, update, and scale one more container, and PDF spikes (that end-of-month invoice run) compete for the same host resources as n8n itself. For self-hosters who want everything in their own compose file, it's a solid choice; our Gotenberg alternatives page covers where it fits and where a hosted API takes over.

Getting the PDF where it needs to go

Whichever route renders the PDF, the file arrives as binary data on the workflow item. From there:

  • Google Drive node: map the binary property in the file field; done.
  • Gmail / email nodes: add the binary property as an attachment.
  • S3 or storage nodes: same binary mapping. (With Transformy you can skip this hop entirely: a storage parameter uploads the finished PDF directly to your own S3, GCS, Azure, or R2 bucket, and the workflow just gets the confirmation.)
  • Respond to Webhook: return the PDF to whatever called the workflow, as in the JSON above.
Gotcha: if a downstream node complains about missing binary data, check the HTTP Request node's response format first. "File" is not the default, and text-mode PDF bytes are the single most common failure in n8n PDF threads.

FAQ

Is there an n8n node for HTML to PDF?

Not a built-in one. You can install a community node (verified ones work on n8n Cloud too), or use the built-in HTTP Request node with a rendering API, which works everywhere with nothing installed. A self-hosted Gotenberg container also works, provided your n8n instance can reach it over the network.

How do I convert HTML to PDF on n8n Cloud?

Use the HTTP Request node. n8n Cloud doesn't run unverified community nodes and you can't install binaries, so calling an HTML to PDF API is the route that works without leaving the managed plan.

What's the cheapest way to generate PDFs in n8n?

Self-hosted Gotenberg is free software, if you're already running your own n8n and don't mind operating the container. Among hosted APIs, free tiers cover light automation: Transformy's includes 100 documents a month, which handles a daily-report workflow with room to spare. Our best HTML to PDF APIs comparison lists the free tiers side by side.

How do I email the generated PDF as an attachment?

Set the HTTP Request node's response format to File, then in your Gmail or SMTP node add an attachment and select the binary property (usually data) from the render step. No base64 conversion needed; n8n passes binary data between nodes natively.

Conclusion

Pick your n8n HTML to PDF route by deployment, not by habit:

  • n8n Cloud: HTTP Request node + an HTML to PDF API. Only route with zero installation.
  • Self-hosted, want everything local: Gotenberg container.
  • Self-hosted, found a well-maintained community node: fine, after you've checked its engine and upkeep.
  • Anything wrapping wkhtmltopdf: skip it in 2026.

The importable workflow above is the fastest path to a working PDF step: import, add a key, POST your HTML. Transformy's free tier covers 100 documents a month with no credit card, which is enough to run a real invoice or report workflow before you decide anything. Render your first workflow PDF free, and send your ugliest template through it first.