How to Hide Cookie Banners in ScreenshotAPI Captures

To hide cookie banners in ScreenshotAPI.net captures, add no_cookie_banners=true to the screenshot request. The option is documented as false by default, so enable it explicitly. ScreenshotAPI.net says it removes most consent banners; check the resulting image because site-specific banners can remain. If you need to remove a particular element, use browser automation to find and hide it before taking the screenshot.

This changes what appears in the captured image. It does not record a visitor’s consent or sign in to a protected page.

1. Enable the built-in banner option

Include this query parameter in the ScreenshotAPI.net capture request:

no_cookie_banners=true

The vendor documents this option for hiding cookie consent banners before capture. Its Help page recommends block_ads=true as a separate option when ad scripts also clutter the image. Ad blocking is not required to hide cookie banners.

For example, the documented API pattern uses the v3 screenshot endpoint, a token, and the target page URL:

GET https://shot.screenshotapi.net/v3/screenshot?token=YOUR_TOKEN&url=https%3A%2F%2Fexample.com&no_cookie_banners=true

Use your API token and URL-encode the target URL and any parameter values as required. Refer to the ScreenshotAPI.net Help page and current API documentation for the endpoint and authentication details for your account.

Optional: block ads separately

If ads are another source of visual clutter, add block_ads=true too:

GET https://shot.screenshotapi.net/v3/screenshot?token=YOUR_TOKEN&url=https%3A%2F%2Fexample.com&no_cookie_banners=true&block_ads=true

These options address different things: no_cookie_banners handles consent banners, while block_ads blocks ad scripts according to ScreenshotAPI.net’s Help page. The vendor describes banner removal as applying to “most” banners, so do not assume every site will be handled.

2. Check whether the banner was actually removed

Inspect the returned capture for the specific page you care about. A successful API response does not by itself establish that a particular consent overlay disappeared. Test representative pages, especially if you capture multiple domains or rely on a consistent layout.

1. Request the page with no_cookie_banners=true.
2. Open the image and check for the banner, overlay, or layout shift it caused.
3. If it remains, identify the element’s actual CSS selector and use the browser-automation fallback below.

3. Fallback: hide a site-specific element with Puppeteer

When automatic handling misses a banner, browser automation gives you per-site control. Load the page, wait for the relevant element, hide it, then take the screenshot. The selector below is only an example: replace .cookie-banner with the selector used by the target site.

Install Puppeteer in a Node.js project with npm install puppeteer. Save this as capture.mjs and run it with node capture.mjs:

import puppeteer from 'puppeteer';

const targetUrl = 'https://example.com';
const bannerSelector = '.cookie-banner'; // Replace with the page's real selector.

const browser = await puppeteer.launch({ headless: true });
try {
  const page = await browser.newPage({
    viewport: { width: 1440, height: 1000 },
  });

  await page.goto(targetUrl, {
    waitUntil: 'networkidle2',
    timeout: 60_000,
  });

  // Hide the banner if it exists. A missing selector is not an error.
  await page.evaluate((selector) => {
    const banner = document.querySelector(selector);
    if (banner) banner.style.setProperty('display', 'none', 'important');
  }, bannerSelector);

  await page.screenshot({ path: 'capture.png', fullPage: true });
} finally {
  await browser.close();
}

The general pattern is to find the element and set its display to none before capture. ScreenshotAPI.net’s guide uses this approach and notes that the correct selector varies by site. See its cookie-banner guide.

Make the selector fallback more reliable

• Use the site’s real selector. Inspect the page’s DOM or developer tools; a generic class name may match nothing or the wrong element.
• Wait for late banners. Some consent tools appear after page load or a delay. Wait for the banner selector or for the site’s consent script to finish before hiding it.
• Account for iframes and shadow DOM. document.querySelector only searches the current document. A banner inside an iframe requires operating in that frame; content inside a shadow root requires querying the shadow root.
• Check layout after hiding. A fixed overlay may disappear while leaving a backdrop or scroll lock behind. If necessary, hide the backdrop too and restore scrolling for the capture.
• Do not treat hiding as consent. Removing an element visually does not establish that a consent choice was saved or that the site’s consent state changed.

4. Keep consent banners separate from login cookies

A consent banner is a page element; an authentication cookie can establish a user session. Hiding a banner does not grant access to a protected page. ScreenshotAPI.net’s Help page says custom cookies can be supplied to simulate a session, but the required cookie depends on how that site implements authentication. Only use cookies you are authorized to use, and follow the current API documentation for the cookie parameter format.

5. Troubleshooting

Symptom	Likely cause	What to do
The banner is still in the image	The automatic option did not catch that site’s implementation, or the banner appeared after the capture point.	Confirm the parameter is spelled no_cookie_banners=true. Inspect the image, then use a real site-specific selector and wait for the banner before hiding it.
The selector fallback changes nothing	The sample selector does not match the page, or the element is inside an iframe or shadow root.	Inspect the DOM and replace .cookie-banner. Query the relevant frame or shadow root when needed.
The overlay disappears but a dim backdrop remains	The backdrop is a separate element from the banner.	Identify and hide the backdrop element as well. Check the captured page for scroll locking or other remaining layout effects.
The page shows a login screen	The capture lacks a valid authenticated session.	Handle authentication separately with authorized session cookies and the API’s documented cookie options. Banner removal does not authenticate a request.
The Puppeteer script times out during navigation	The page may keep network connections open, or it may be slow to load.	Use a navigation wait condition appropriate for the page and set a suitable timeout. If network-idle waiting is unsuitable for a continuously active page, wait for a specific page element instead.
Ads remain visible	Banner removal and ad blocking are separate settings.	Try block_ads=true separately, then inspect the capture. Do not rely on ad blocking to remove consent UI.

6. Performance, reliability, and cost considerations

• Keep capture settings stable. For repeatable output, use the same URL and options and verify changes when the page’s markup or consent provider changes.
• Choose waits deliberately. Waiting for network idle can make a browser script more predictable on ordinary pages, but pages with ongoing requests may not become idle. Waiting for a specific selector can be more appropriate when the banner is the relevant condition.
• Plan for service limits. ScreenshotAPI.net Help reports plan-dependent rate limits of 20–80 requests per minute. This is a vendor-reported limit and may change; check the current Help page and your plan before sizing a capture queue.
• Account for successful renders and caching. The same Help page says failed screenshot attempts do not count toward usage limits and cached screenshots do not count; it describes caching behavior and retention separately. Confirm current billing and cache rules for your account before estimating costs.
• Validate important output. No universal success rate is established for banner removal. Check captures from the pages and consent platforms that matter to your application.

7. Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server. A GET request returns an image or PDF. For an image capture, this cURL example saves a WebP file:

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

See the ScreenshotNeo API documentation for request options. Cookie banners, popups, and chat widgets are removed before the shot; each step can be turned off. Bot checks, blank pages, and failed loads are never billed, and the response identifies the page verdict and billing status in headers. Its MCP server lets AI agents use take_screenshot, get_page_info, and capture_pdf. The free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000 shots. Every feature is on every plan.

Sign up for ScreenshotNeo’s free 1,000 screenshots per month, with no card required.

FAQ

Does no_cookie_banners=true work on every site?

No universal guarantee is documented. ScreenshotAPI.net says it removes most consent banners. Inspect the image and use a site-specific selector when needed.

Does hiding a consent banner save the visitor’s choice?

No. Hiding an element changes its appearance in the capture; it does not mean the site recorded a consent choice.

Does no_cookie_banners=true sign in to a site?

No. Authentication cookies are a separate concern. A protected page requires the appropriate authorized session mechanism.

Should I set block_ads=true too?

Only if you also want to address ad clutter. ScreenshotAPI.net documents it separately from consent-banner removal.