ScreenshotRender
← Back to blog
Tutorials

How to Screenshot a Website in n8n (No Custom Node)

Robert Belt·9 min read
Updated On :
Orange minimalist illustration of an n8n workflow turning a URL into a PNG screenshot

Short answer: drop an HTTP Request node into n8n, point it at https://screenshotrender.com/api/v1/screenshot?apiKey=YOUR_API_KEY&url=https://news.ycombinator.com&fullPage=true, and you have a hosted PNG ready for the next node in under five seconds. No community node, no headless Chrome on your self hosted instance, no custom Function step.

By the end you will have a working n8n workflow that turns any URL into a hosted PNG you can pipe into Slack, Airtable, Notion, or your own database, including the JavaScript heavy and Cloudflare protected sites that break every off the shelf screenshot node.

Why is taking a screenshot in n8n harder than it should be?

There is no first party screenshot node in n8n, so most tutorials send you down one of three paths and two of them are traps. The three options are a community node, a Function step that imports Puppeteer, or an HTTP Request node calling a hosted screenshot API. Only the third works on every n8n install without ongoing maintenance.

Community nodes are the obvious choice and the slowest one to rot. The popular Puppeteer based community nodes ship a Chromium binary inside the package, and every major n8n upgrade risks a Node version mismatch that prevents the node from loading. The n8n community node installation guide is also explicit that community nodes are not supported on n8n.cloud's standard plans, which kills the option before you start for most managed users.

The Function node route is worse. Importing Puppeteer or Playwright inside a Function step needs native modules that n8n.cloud does not allow at all, and on a self hosted instance a single warm Chromium uses 300 to 500 MB of resident memory per concurrent screenshot. A $5 VPS with n8n on it runs out of RAM the first time the workflow fans out.

That leaves a hosted screenshot API behind an HTTP Request node. ScreenshotRender returns a hosted PNG URL from a single GET request, which means n8n only ever sees JSON and never touches a browser binary. It works identically on n8n.cloud, on a self hosted Docker container, and on a Raspberry Pi.

How do you screenshot a website in n8n with just an HTTP Request node?

Add an HTTP Request node, set the method to GET, and paste the full ScreenshotRender URL into the URL field. The complete request is one line you can copy:

https://screenshotrender.com/api/v1/screenshot?apiKey=YOUR_API_KEY&url=https://news.ycombinator.com&fullPage=true

Replace YOUR_API_KEY with your sr- prefixed key from the ScreenshotRender dashboard. The url parameter is the page you want to capture; if the target URL has its own query string, percent encode it per the MDN percent encoding reference or use n8n's expression {{encodeURIComponent($json.url)}}. fullPage=true captures the entire scrollable document instead of the 1280 by 720 viewport.

Set Authentication to None (the API key is in the query string), leave the body empty, and set Response Format to JSON. That is the whole node. Hit Execute and the output will be a JSON object with a data.screenshot field containing a hosted image URL valid for download.

Test the exact URL against any target site first in the interactive playground so you know the call works before you wire it into a workflow with three downstream nodes depending on it.

How do you pass the screenshot into the next n8n node?

Reference the hosted URL with the expression {{$json.data.screenshot}} in whatever node comes next. The response from ScreenshotRender is a JSON envelope with the image URL inside data.screenshot, plus the page title, description, and favicon for free, which is convenient when you are building link preview cards.

Three common downstream patterns:

  • Slack: drop a Slack node, choose Send Message, and put {{$json.data.screenshot}} in the message body. Slack auto unfurls the image.
  • Airtable: add an Airtable Update Record node, map your attachment column to [{"url": "{{$json.data.screenshot}}"}]. Airtable downloads and stores the file itself.
  • S3 or Google Drive: add a second HTTP Request node with method GET, URL set to {{$json.data.screenshot}}, and Response Format set to File. n8n attaches the binary; the S3 or Drive node uploads it. The n8n binary data docs cover the binary property names if you need them.

Skip the Chromium build, the Cloudflare fight, and the EC2 fleet.

One HTTP Request node in n8n calling ScreenshotRender returns a hosted PNG with cookie banners and ads already stripped. No community node to break on the next upgrade, no Puppeteer to maintain, no 170 MB Chromium binary on your self hosted instance.

Get an API key

How do you screenshot a JavaScript heavy or Cloudflare protected site from n8n?

Add a wait parameter in milliseconds for single page apps, and use the Hobby plan or higher for Stealth Mode on Cloudflare protected sites. For a React or Vue dashboard that hydrates after the initial paint, the call becomes:

https://screenshotrender.com/api/v1/screenshot?apiKey=YOUR_API_KEY&url=https://news.ycombinator.com&fullPage=true&wait=2000

The 2000 ms wait is what most SPAs need to finish painting after network idle, because they swap content based on user state or feature flags that networkidle0 alone never sees. You can also pass a timeout value if you want to cap the whole request at, say, 15 seconds so a slow page does not stall the workflow.

Cloudflare is a different problem. Vanilla headless Chromium gets a 403 or a JavaScript challenge on most Cloudflare protected pages because of bot fingerprints, missing plugin arrays, and the standard Puppeteer launch flags the Cloudflare Turnstile documentation describes. ScreenshotRender bundles Stealth Mode on the Hobby plan and above (see the pricing page for the breakdown), so Cloudflare, DataDome, and similar challenges are handled without you setting any flags in the HTTP Request node.

Cookie banners, GDPR consent popups, ad overlays, and chat widgets are removed automatically on every plan including the free one. That is one less thing to script around inside your n8n workflow.

When does this approach fail?

Three scenarios where the HTTP Request plus hosted API path breaks down or needs a workaround:

  • Internal URLs not reachable from the public internet. A hosted screenshot service cannot render http://localhost, http://10.0.0.5, or your VPC internal dashboards. For internal screenshotting you need a self hosted headless browser inside the same network, which is exactly the operational tax this article is trying to help you skip everywhere else.
  • High frequency Schedule Trigger workflows. The free plan is rate limited to 40 requests per minute and the Hobby plan to 60. If your Schedule Trigger fans out to hundreds of URLs every minute, throttle the fan out with a Loop Over Items node and a Wait, or upgrade to a plan with a higher per minute cap.
  • Sensitive pages behind authentication. ScreenshotRender's public API takes a URL, not a cookie jar or a logged in session. If the page you want to screenshot requires login, generate a signed share URL on the source app first and screenshot that, or self host the browser.

Everything else, including the 90 percent of cases where you want a PNG of a public marketing page, blog post, dashboard embed, or product page, the HTTP Request node path is the right answer.

Common questions about screenshots in n8n

Do I need a paid n8n plan to use this?

No. The HTTP Request node is a core node available on every n8n.cloud tier and on every self hosted install (n8n is open source and free to self host). ScreenshotRender also has a free tier of 100 screenshots per month with no credit card required, so the screenshot half of the workflow costs nothing while you decide if it solves your problem.

Can I use this with self hosted n8n?

Yes, and it is the cleanest way to do screenshots on a self hosted instance. Because n8n only makes an HTTP call, there are no native dependencies to install, no Chromium binary to keep current, and no extra RAM headroom needed. The same workflow runs identically on a Raspberry Pi, a Docker container, and a Kubernetes pod.

How do I store the screenshot in S3 or Google Drive?

Chain a second HTTP Request node after the ScreenshotRender call. Set its URL to {{$json.data.screenshot}}, method GET, and Response Format to File. n8n attaches the binary as a property; the S3 or Google Drive node uploads that binary directly. No intermediate Function node, no buffer gymnastics.

Can I schedule a screenshot every day in n8n?

Yes. Wire a Schedule Trigger node (set to whatever cron expression you need) into the HTTP Request node calling ScreenshotRender, then into the destination node. A daily snapshot of a homepage, a competitor's pricing page, or a marketing landing is one workflow with three nodes and zero code.

What is the cheapest way to add screenshots to n8n?

Self host n8n (free, open source) and use ScreenshotRender's free plan. 100 screenshots per month, ad and cookie banner removal enabled by default, full page capture supported, no credit card required. If you need Stealth Mode for Cloudflare or a higher per minute cap, the Hobby plan is $10 per month billed annually with 2,000 screenshots included.

The honest verdict: if your n8n workflow needs a screenshot and you do not already maintain a headless browser somewhere, an HTTP Request node calling a hosted API is the cheapest, fastest, and most upgrade safe option. The time saved on community node breakage and Chromium memory tuning alone usually pays for the API tier inside the first month.

Keep reading