How to Hide Cookie Banners in Browserless Screenshots

To hide cookie banners in Browserless screenshots, first try its built-in consent blocker: set blockConsentModals=true on a supported screenshot or PDF request, or enable the option for a BrowserQL session. The option defaults to false. If the blocker misses a banner, click the site’s visible accept control or inject CSS to hide a known banner element. These approaches have different effects: clicking records the action you choose; CSS only changes what is visible in the capture.

This guide covers the Browserless REST and BrowserQL approaches, selector and CSS fallbacks, timing, troubleshooting, and a managed screenshot API alternative.

1. Try Browserless’s built-in consent blocker

For the REST screenshot endpoint, pass blockConsentModals=true as a query parameter. The documented screenshot endpoint also accepts a POST with a target URL and optional screenshot settings. See the REST launch parameters and Screenshot API documentation for the current request shape and authentication requirements.

curl -X POST \
  'https://production-sfo.browserless.io/screenshot?token=YOUR_BROWSERLESS_TOKEN&blockConsentModals=true' \
  -H 'Content-Type: application/json' \
  --data '{"url":"https://example.com"}' \
  --output screenshot.png

Replace the example endpoint and token with the Browserless endpoint and token for your account. The option is documented for BrowserQL and the REST /screenshot and /pdf APIs. For BrowserQL, set the corresponding launch or session parameter to true.

Start here when you do not need to choose a particular consent action or write site-specific selectors. The built-in blocker handles supported consent modals; a site-specific or unsupported banner may still appear.

2. Click the visible consent control when the built-in blocker misses

Some pages need an interaction to dismiss the banner. Browserless’s BrowserQL example navigates to the page, checks for a visible accept control, clicks it, waits for the page to settle, and then captures. Its example selector is generic; inspect the target page and replace it with a selector that identifies the correct action. OneTrust and Cookiebot are examples of consent platforms that may need custom handling.

mutation ScreenshotWithConsentClick {
  goto(url: "https://example.com") {
    status
  }
  click(selector: "button[id*=accept]") {
    time
  }
  waitForTimeout(time: 1000) {
    time
  }
  screenshot {
    data
  }
}

Use the BrowserQL editor or client request format your integration uses, and set blockConsentModals in the BrowserQL launch/session parameters as appropriate. The snippet illustrates the navigation, targeted click, wait, and capture sequence; adapt it to the BrowserQL operation syntax and response handling in your client. Browserless’s documented example uses a visible-selector check before clicking and networkIdle as a wait strategy. Consult its cookie consent example and BrowserQL launch parameters.

Choose selectors carefully

• Prefer a selector that names the actual accept button, such as a site-specific ID or an inspected button label selector supported by your automation layer.
• Avoid clicking the first generic button on the page: it could be “reject,” “manage settings,” or an unrelated control.
• Check that the selector is visible and unique before clicking. If the page has separate desktop and mobile banners, choose the selector for the viewport you capture.
• For banners inside an iframe, the selector must be evaluated in the relevant frame; a top-level page selector will not find it.

3. Hide a known banner with injected CSS

If you want a visual-only change and know the banner’s selector, inject a style before capture. Browserless documents addStyleTag / add_style_tag for hiding cookie banners and sticky headers. This does not accept or reject consent, save a preference, or stop the site from loading its consent manager.

/* Inject before taking the screenshot */
.cookie-banner,
#cookie-consent-banner {
  display: none !important;
}

In a Puppeteer-style setup, add the CSS after navigation and before capture:

await page.goto('https://example.com', { waitUntil: 'networkidle0' });
await page.addStyleTag({
  content: '.cookie-banner, #cookie-consent-banner { display: none !important; }'
});
await page.screenshot({ path: 'screenshot.png', fullPage: true });

This code shows the browser-side operation; it assumes you already created page in your Browserless connection. Use the CSS injection mechanism supported by your Browserless workflow. See Browserless page setup and injected styles.

4. Pick the right approach

Approach	Use it when	Effect	Watch for
blockConsentModals=true	You want built-in handling without site-specific selectors.	Browserless attempts to detect and dismiss supported consent modals.	Unsupported or site-specific banners may remain.
Click a visible control	The page requires a deliberate interaction and you know the correct button.	Activates the selected page control.	A broad selector can click the wrong action; verify the result.
Inject CSS	You only need a clean visual capture and know the banner element.	Hides the selected element in the rendered screenshot.	Does not persist a consent choice or prevent the overlay from affecting page behavior.

5. Make the capture reliable

1. Enable the built-in blocker and capture once.
2. If the banner remains, inspect the rendered page at the same viewport and identify its actual button or container selector.
3. Choose whether the task requires an actual consent interaction or only a clean image. Click the right action for the former; inject CSS for the latter.
4. Wait for dismissal and page layout to settle before capturing. A short delay or network-idle wait can help, but neither guarantees that every site has finished its relevant work.
5. Inspect the resulting screenshot. Confirm the banner is gone and that page content was not hidden or shifted unexpectedly.
6. If the image instead shows a CAPTCHA, access-denied message, or blank page, troubleshoot that separately from banner handling.

Browserless offers REST endpoints, BrowserQL, and BAP, its TypeScript/Python SDK layer over BrowserQL. Use the interface already present in your application rather than changing integration solely for this setting. See the BAP overview.

6. Troubleshooting

Symptom	Likely cause	What to change
The banner remains with the built-in option enabled.	The consent UI is unsupported, site-specific, or not recognized as a modal.	Inspect the page and use a specific visible-button click or inject CSS for the known banner container.
The click does nothing.	The selector does not match, the element is not visible yet, or it is inside an iframe.	Verify the selector against the rendered page, wait for the control, and target its frame if needed.
The wrong consent action is chosen.	A broad selector matched a reject, settings, or unrelated button.	Use an exact selector for the intended action and verify the resulting page state.
The banner disappears but page content is covered or missing.	The CSS selector is too broad or hides a shared container.	Target only the banner element, remove the rule temporarily, and inspect the page again.
A banner flashes in the image.	Capture occurred before the blocker or click completed, or the page re-rendered the banner.	Wait for the banner to disappear and the layout to settle; use a selector-based wait where possible.
The screenshot is blank or shows CAPTCHA/access denied.	This is likely a load or automation-blocking issue rather than consent UI handling.	Check navigation and response state. Browserless documents its Unblock API for automation-blocking cases; consent settings alone do not solve them.

7. Performance, reliability, and cost considerations

Built-in handling avoids maintaining selectors for supported banners. A custom click or CSS rule adds site-specific maintenance: selectors can change with a site redesign, and different locales, viewport sizes, or consent platforms may render different controls. Keep selectors narrow and review captures when target sites change.

Waiting improves the chance that the banner has been handled before capture, but long fixed delays add latency and do not guarantee success. Prefer waiting for the specific banner to disappear or the intended content to appear when your integration supports it. Network-idle is one documented example, not a universal guarantee for pages with ongoing requests.

Browserless documentation cited here does not state a cost or performance benchmark for these approaches. Check your account’s current plan and usage terms before estimating capture cost. A clean visual suppression via CSS and an actual consent click also have different behavioral implications; use the one appropriate to your capture purpose.

Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server. One GET request returns a screenshot; its capture flow removes cookie banners, popups, and chat widgets before the shot. Bot checks, blank pages, and failed loads are never billed, and response headers identify the page verdict and billing status. Its MCP server gives AI agents screenshot tools. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000. See the ScreenshotNeo API docs.

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

Sign up free for 1,000 screenshots a month, with no card.

FAQ

Does hiding a cookie banner mean the site has recorded consent?

No. CSS only changes the rendered appearance. Clicking an accept control performs the page’s action; use it only when that is the intended choice.

Does Browserless’s blocker need a selector?

No selector is needed for the built-in blockConsentModals=true option. A selector is a fallback for banners it does not handle.

Can I use the setting for a PDF?

Browserless documents the option for its REST PDF API as well as screenshot and BrowserQL flows. Check the launch-parameter documentation for the request form you use.