Driving a real browser from n8n: Browserless and Playwright when HTTP Request isn't enough

The HTTP Request node and Firecrawl cover most web-retrieval needs in n8n: they fetch a page and pull content from it, sometimes already cleaned into Markdown. But both share a limitation: neither clicks anything, fills in a form, or keeps a session logged in. As soon as a scenario requires logging into a dashboard, stepping through a multi-stage form, or capturing an exact visual render (screenshot, PDF), you need a real browser that actually executes the page — not a plain HTTP client reading its raw HTML. This guide covers both ways to do that from n8n: Browserless, a hosted browser driven over HTTP, and Playwright, as a self-hosted community node for finer control.

When a real browser becomes necessary

Three families of use cases go beyond what a plain HTTP client can do:

• Content behind a session-based login: a vendor dashboard, a client portal, a CRM with no exposed API. You need to log in, keep the session cookies, and then navigate like a real user.
• Sequential interactions: ticking a filter, clicking "load more," waiting for an XHR request to finish before reading the result. Our n8n scraping guide covers reading an already-rendered page well, but not the chain of actions that precedes it.
• Exact visual rendering: generating a screenshot of a page for a report, or a PDF that faithfully matches an HTML/CSS layout — a different need from generating a PDF from structured data, where n8n composes the document rather than a browser rendering it.

If your need is limited to reading static or JavaScript-rendered public content with no interaction, Firecrawl stays simpler and cheaper: reserve the headless browser for the cases above.

Option 1 — Browserless, a hosted browser driven over HTTP

Browserless exposes a hosted Chrome infrastructure, callable directly from n8n's HTTP Request node: nothing to install, no binaries to manage, works the same on n8n Cloud and self-hosted. It's the integration officially documented by n8n, and the simplest entry point to start with.

The principle: your credential stores the Browserless token (see our credential security guide), and a POST call to one of the REST endpoints triggers the action you want.

POST https://production-sfo.browserless.io/content?token=YOUR_TOKEN
Content-Type: application/json

{
  "url": "https://example.com/dashboard",
  "waitForSelector": { "selector": "#data-loaded", "timeout": 8000 }
}

The /content endpoint returns the final HTML after JavaScript execution and after waiting for the given selector — exactly what a plain HTTP Request can't do. The /screenshot and /pdf endpoints work on the same principle for visual renders. For more complex scenarios (login, sequential clicks), Browserless also offers BrowserQL, a query language that describes a whole sequence of actions in a single call instead of chaining separate HTTP requests.

Option 2 — Playwright as a community node, for full control on self-hosted

On a self-hosted instance, a Playwright community node (such as n8n-nodes-playwright) goes further: a "Run Custom Script" operator runs full Playwright code in a sandboxed environment, with access to the whole API — navigation, form filling, popup handling, fine-grained network waits.

It's a powerful option, but it comes with a cost: roughly 1 GB of disk space for the browser binaries downloaded at install time, and above all a structural limit worth knowing — n8n Cloud only accepts verified community nodes, and no Playwright node holds that badge today. This option therefore only exists on an instance you administer yourself.

const browser = await playwright.chromium.launch();
const page = await browser.newPage();
await page.goto('https://example.com/login');
await page.fill('#email', $('Credentials').item.json.email);
await page.fill('#password', $('Credentials').item.json.password);
await page.click('button[type="submit"]');
await page.waitForSelector('#dashboard');
const content = await page.textContent('#data');
await browser.close();
return [{ json: { content } }];

Keeping a session logged in without logging in on every run

Logging in on every run is slow and raises the odds of tripping an anti-bot detector or an account lockout for repeated logins. The right practice, with Browserless as with Playwright, is to save the session state (Playwright's storageState: cookies and local storage) after a first successful login, then re-inject it at the start of every following run. Treat that state as a secret — stored the same way as an API token, never in a plain workflow variable — and refresh it with a fresh full login whenever it expires or a call fails unexpectedly.

Anti-bot detection isn't theoretical

A browser driven by automation isn't invisible by default: it leaves traces distinct from a browser used by a human. A landmark study by Vastel, Laperdrix, Rudametkin and Rouvoy, “FP-Scanner: The Privacy Implications of Browser Fingerprint Inconsistencies”, presented at USENIX Security, shows how fingerprint inconsistencies — the webdriver flag, missing plugins, canvas rendering behavior — reliably tell an automated browser apart from a regular one. Hosted services like Browserless apply stealth countermeasures to reduce these signals, but none are guaranteed against a site that specifically invests in detecting them. Two habits matter: always check for an official API before reaching for a headless browser, and respect the target site's terms of use — the same principles covered in the legal section of our scraping guide.

Fragile selectors: why AI remains a good safety net

Whether you drive Browserless or Playwright, the most common breaking point stays the same as in classic scraping: a CSS or XPath selector that breaks at the slightest redesign of the target page. A study by Leotta, Stocco, Ricca and Tonella, “Using Multi-Locators to Increase the Robustness of Web Test Cases”, shows that combining several locator strategies cuts the number of broken selectors by roughly 30% compared to the best single strategy tested. Without reimplementing such a system, the principle still carries over into n8n: instead of extracting a field with one rigid selector, feed the raw HTML returned by Browserless or Playwright to an LLM with structured output — see our structured extraction guide — which identifies the data by semantic context and tolerates layout changes far better than a fixed selector.

Making it production-grade: errors, pacing and cost

A headless browser is slower and more expensive than a plain HTTP call — expect several seconds per run, against a few hundred milliseconds for Firecrawl or a REST API. Three settings avoid unpleasant surprises in production:

• Explicit timeouts on every selector or navigation wait, with a dedicated Error Workflow that captures login or rendering failures instead of letting the run crash silently.
• Controlled pacing, especially on authenticated scenarios: a Wait node between two runs limits the risk of triggering a rate limit or a security alert on the target site.
• Systematically closing the browser (browser.close()) at the end of the script, including on error, to avoid piling up ghost Chrome instances that eat up your server's memory — a classic trap covered in our n8n out-of-memory guide.

Going further

Content extracted by a headless browser — internal documentation, product pages, competitor content — becomes valuable once indexed and queryable. The Pack Assistant RAG (€119) ships the four ingestion, chunking and vector-search workflows to turn that content into a knowledge base a chatbot can query, and the Bundle FlowKit Complet (€269) bundles it with the Pack Inbox IA (€79) and the Pack Conformité & Audit (€149) to cover collection, triage and traceability end to end.