Web Automation in n8n: HTML Node, Puppeteer and Playwright Compared

For simple web scraping without JavaScript rendering, n8n's built-in HTML Node with CSS selectors is sufficient. For portals that load content only via JavaScript, you additionally need a real browser in the background, which n8n does not provide. In practice, n8n users typically solve this via a self-hosted browserless or Playwright container, which they control via the HTTP Request Node, instead of running Puppeteer or Playwright directly in the Code Node. Status: August 2026.

What can the built-in HTML Node do?

According to the official documentation, the HTML Node covers three tasks: extract HTML content from a source using CSS selectors, create an HTML template from workflow data, or convert content into an HTML table. When extracting, you select the desired elements using CSS selectors and specify whether attribute values, HTML content, plain text, or form values are returned. The "Return Array" option determines whether multiple hits are output as an array or as a single consolidated string; additionally, "Trim Values" and "Clean Up Text" are available for cleaning the extracted values.

Why is the HTML Node insufficient for many modern websites?

The HTML Node processes only HTML sources that you pass to it as a JSON property or binary file; it does not provide its own browser or JavaScript execution. For a classically server-side rendered page, that is sufficient because the HTTP Request Node loads the finished HTML code via a REST call and the HTML Node can evaluate it directly. However, if a page constructs its content in the browser via JavaScript, the pure HTTP call only provides an empty skeleton, and the HTML Node has nothing to evaluate.

How do n8n users integrate Playwright or Puppeteer in practice?

A recurring pattern has been established in the n8n community: instead of running Playwright directly in the Code Node, a self-hosted browserless container with Playwright runs in the background, which n8n accesses via the HTTP Request Node. A thoroughly documented example in the n8n forum uses endpoints like "/content", "/screenshot", and "/pdf" for this, secured via a header auth credential with its own token. This approach cleanly separates browser automation, which requires significant memory, from the actual n8n workflow, which only processes HTTP responses.

Is there a ready-made Playwright Node for n8n?

n8n does not offer an official, ready-made Playwright Node. In a n8n forum thread about local Playwright use without a paid service, it becomes clear that users typically help themselves in this case, either with their own custom node based on Playwright or with the browserless HTTP route. Anyone who regularly needs screenshots, PDFs, or content from JavaScript-heavy pages can hardly avoid running their own browser service, whether as a custom node or as an HTTP call.

Frequently Asked Questions about Web Scraping in n8n

Can the HTML Node read JavaScript-heavy pages directly?

No. The HTML Node only evaluates the HTML source it receives as JSON or binary data; it does not execute JavaScript itself. For pages with dynamically loaded content, you need a real browser first, such as via a self-hosted browserless or Playwright service.

Do I absolutely need a paid service for web scraping in n8n?

No. Solutions documented in the community rely on a self-hosted browserless or Playwright container that you operate via Docker and control via the HTTP Request Node. Running costs are then limited to your own server infrastructure, such as within the scope of an existing n8n installation.

What does the "Return Array" option do in the HTML Node?

It specifies whether multiple matches found via CSS selector are returned as an array with multiple entries or merged into a single consolidated string. For lists from which you later want to process individual elements, the array variant is usually the more practical choice.

What should you pay attention to with selector-based scraping?

Selector-based scraping with CSS selectors regularly breaks in practice as soon as the target page changes its layout or class names. Community reports on Puppeteer and Playwright workflows confirm this pattern repeatedly, which is why a productive scraping workflow should plan for some maintenance rather than running unchanged once it is set up.