How to Take a Website Screenshot from a Form Submission with n8n

To take a website screenshot when someone submits an n8n form, connect an n8n Form Trigger to an HTTP Request node that calls a screenshot API, then route the returned image to a storage or delivery step:

Create a form with a website URL field using the Form Trigger.
Send the submitted URL from that node to a screenshot API with an HTTP Request node.
Handle the response as binary image data or base64, depending on your destination.
Save or deliver the image in a downstream node.

This guide uses Browserless for the do-it-yourself API example because its documentation covers both screenshot requests and an n8n HTTP Request integration. The workflow is an implementation outline composed from those documented pieces, not a prebuilt or tested workflow. Check the current n8n editor for the exact field names and expression mapping in your workflow.

1. Create the n8n form

Add a Form Trigger node. Add a required field for the target website URL, for example with the field label url. The trigger generates the form page and starts the workflow when a visitor submits it; its submitted values become the input item for subsequent nodes.

Use a clear label such as “Website URL” and provide a URL example as placeholder text. Decide what the form submitter should see after submitting: n8n’s form documentation describes configurable submission ending behavior. If the screenshot should be returned immediately, plan the response and downstream delivery path deliberately; a storage node alone does not show the image to the submitter.

During development, use the Form Trigger’s Test URL and execute the node or workflow. Submit a sample URL so the editor receives the actual incoming item. This lets you inspect the submitted field and build the HTTP Request expression against the data your form produces.

2. Call the screenshot API with HTTP Request

Add an HTTP Request node after the Form Trigger. Browserless’s screenshot API accepts a POST request with the target URL and screenshot options, authenticates with an API token, and returns image data in a supported format. Its n8n integration guide demonstrates using the HTTP Request node and storing the token as a credential.

Configure the request

Set the method to POST and the URL to the Browserless screenshot endpoint shown in its current API documentation.
Configure authentication using the API token in n8n Credentials. Do not paste a real token into a public workflow, form, screenshot, or shared JSON export.
Set the request body to JSON and map the target URL from the Form Trigger output. In the expression editor, select the submitted URL field from the preceding node’s item rather than assuming a field path.
Add the screenshot options you need, such as image format and full-page capture. Use the option names and request structure in the current [Browserless Screenshot API documentation](https://docs.browserless.io/rest-apis/screenshot-api).
Set the HTTP Request response handling to the representation required by your next node: binary image data for file or object storage, or base64 if the next step expects a string. Browserless’s n8n guide illustrates both buffer and base64 handling.

The form item shape and expression syntax can vary with the way the form fields are configured. Submit a test item, inspect its JSON in n8n, then map the URL field visible in that item into the body. Avoid copying an assumed expression without checking it in the editor.

Choose capture extent and format

Choice	Use it when	Consider
Viewport screenshot	You need the visible browser area for a preview or review queue.	It is usually a smaller, more predictable output than a full-page capture.
Full-page screenshot	You need the page from top to bottom, such as for an audit record.	Long pages can produce large images and take longer to capture.
PNG	You need lossless output or crisp text and interface details.	Files may be larger than compressed alternatives.
JPEG	A smaller photographic preview is sufficient.	It is lossy and does not preserve transparency.
WebP	Your downstream tools support WebP and file size matters.	Confirm compatibility with the destination and consumers.

Browserless documents PNG, JPEG, and WebP responses, as well as screenshot options such as full-page capture. The response content type follows the configured format. Make sure the filename extension and storage metadata match the actual response.

3. Save or deliver the image

Add an explicit destination after the HTTP Request node. For example, connect a node for a file store or cloud-storage service, or add a notification or delivery action that links to an image already stored elsewhere. The screenshot endpoint returns image data; it does not choose or configure your destination for you.

For binary handling, confirm that the HTTP Request node places the image in the binary property expected by the destination node. For base64 handling, decode the string before writing a file if the destination expects bytes. Use a filename that avoids collisions, such as one based on the submission ID or a timestamp, and preserve the correct extension for the selected image format.

If the workflow should send the result to the person who submitted the form, add a delivery step and determine how that person can access the saved image. Do not assume that a file written to workflow execution data is a public link or a durable archive.

4. Validate input and protect the workflow

A public form that accepts arbitrary URLs can cause your workflow to fetch sites you did not intend to access. Validate the submitted value before calling the screenshot service. A sensible policy may require an absolute https:// URL and allow only approved hostnames. The appropriate validation depends on your deployment; it is a workflow design choice, not a guarantee supplied by the cited product documentation.

Reject missing or malformed URLs before the screenshot request.
If submissions should be limited to known sites, check the hostname against an allowlist.
Keep API secrets in n8n Credentials and restrict who can edit or export workflows.
Consider how you will handle repeated submissions, oversized pages, and downstream storage failures.
Do not include secret values in error notifications or logs sent to people who do not manage the workflow.

5. Test the workflow and publish it

Run the Form Trigger in test mode and submit a representative URL using its Test URL.
Inspect the incoming item and confirm the URL expression resolves to the submitted value.
Execute the HTTP Request node and confirm its status, response format, and binary or base64 output.
Run the destination node and verify the stored or delivered image can be opened.
Test a malformed URL and a site that is slow or unavailable; confirm failures do not create misleading success notifications.
When ready for live use, switch the form to its Production URL, save and publish the workflow, and submit a production test. Production submissions do not appear in the editor in the same way as test submissions.

6. Troubleshooting

Symptom	Likely cause	What to check
The API request receives an empty or invalid URL	The body expression points to the wrong field or item path.	Submit the form in test mode, inspect the trigger output, and select the actual URL field in the expression editor.
The API returns an authentication error	The token is missing, invalid, or sent using the wrong authentication configuration.	Check the current API documentation and n8n credential binding. Keep the secret in Credentials, not in the form or a shared export.
The response cannot be saved as an image	The HTTP Request response representation does not match what the destination expects.	Use binary output for byte-oriented file destinations, or base64 only when the next step expects an encoded string. Check the binary property name and file extension.
The saved image has the wrong extension or cannot be opened	The file metadata or extension does not match the requested response format, or the response is an API error body rather than an image.	Check the HTTP status, response content type, selected format, and actual output before writing the file.
The screenshot is cut off	The request is capturing only the viewport.	Enable the documented full-page option when you need the complete page; check the result for pages with unusually long or dynamically loaded content.
The workflow works in the editor but not for live submissions	The test and production form URLs or workflow state are mixed up.	Publish the workflow and use the Production URL for live submissions.
The submitter sees no screenshot	The workflow stores the image but has no configured response or delivery step.	Add an intentional form ending behavior and a destination or notification that gives the submitter access to the result.
Requests fail for some submitted sites	The page may be slow, unavailable, blocked, or malformed; some sites may also behave differently for automated browsers.	Check the API response and execution details, validate the input, and decide how the workflow should report a failed capture.

7. Performance, reliability, and cost

Full-page screenshots and large pages can increase response size and workflow processing time. Choose the smallest image format and capture extent that meet the downstream need. If the workflow handles bursts of submissions, account for API limits, n8n execution capacity, and storage throughput using the limits for your own plans and deployment; the cited documentation does not establish a universal throughput or cost figure.

Make failure behavior explicit. A screenshot request can fail even when the form submission succeeds, and a successful capture can still be followed by a storage or delivery error. Track those steps separately, avoid treating an HTTP response as proof that the final file is available, and choose a retry policy that will not create duplicate downstream files or messages.

For costs, check the pricing and usage terms of the screenshot API and your n8n hosting and storage. The sources used here do not provide a comparable end-to-end cost estimate, so calculate it from your expected submission volume, capture settings, and the plans you use.

Or skip the browser setup

Use ScreenshotNeo when you want a single HTTP call for the screenshot step instead of configuring and maintaining your own browser capture service. It returns PNG, JPEG, or WebP screenshots and PDFs, and has parameters that other screenshot APIs use, which can make switching easier. See the [ScreenshotNeo documentation](https://screenshotneo.com/docs/) for API options and the [ScreenshotNeo website](https://screenshotneo.com).

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

In the n8n HTTP Request node, make a GET request to https://api.screenshotneo.com/v1/shot, pass access_key as a credential-backed query parameter, and map the submitted URL to the url query parameter. Handle the response as binary image data and route it to your chosen destination. The command-line equivalent using Python and Node.js is:

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

ScreenshotNeo accepts cookie and consent banners before capture and removes more than 60 known consent platforms, newsletter popups, and chat widgets; each step can be turned off. Bot checks and CAPTCHAs, blank pages, timeouts, failed loads, and cache hits are not billed, with response headers indicating the page verdict and billing status. Its MCP server provides take_screenshot, get_page_info, and capture_pdf tools for AI agents. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 screenshots.

FAQ

Does n8n include a screenshot node?

This workflow uses n8n’s HTTP Request node to call a screenshot API; the cited setup does not depend on a dedicated screenshot node.

Can I send the screenshot back through the form page?

Plan the form’s submission ending behavior and add a result delivery path. A screenshot API response by itself does not determine what the submitter sees.

Can the workflow capture more than one URL?

The described form has one URL field per submission. For multiple URLs, define how the form collects them and how the workflow handles each item before configuring the request.