How to Use Screenshot API Selectors to Hide Cookie Banners

To hide a cookie banner in a screenshot API, use the provider’s documented banner-blocking option or its custom hide-selector option to target the banner’s CSS selector before capture. If the API supports CSS injection, a rule that hides the matched element can work too. Parameter names, request methods, and timing differ by provider, so check the endpoint documentation and verify the resulting image.

A hide selector removes a matching element from the rendered capture. A capture selector does a different job: it limits the screenshot to one selected element. For example, Screenshot API documents hideSelectors for hiding elements and selector for capturing a specific element. [Screenshot API documentation]

Choose the right hiding method

1. Try a built-in banner option. Some APIs offer automatic cookie-banner handling. Its coverage and parameter name are provider-specific.
2. Use a custom hide selector. Inspect the page, identify a CSS selector matching the banner container, and pass it through the API’s documented hide-selector field.
3. Inject CSS if supported. A CSS rule targeting the banner can hide it before the screenshot is taken. Confirm when the provider applies injected CSS.
4. Wait if the banner appears late. If the consent UI is inserted after page load, use a documented wait-for-selector or wait strategy before capture.
5. Check the image. Confirm the banner is gone and the page content beneath it remains visible. A selector only works when it matches the page’s actual markup.

Do not assume that one API’s parameter names or request format work with another. For instance, Screenshot API documents hideSelectors for POST requests; Screenshotbase documents hide_selectors as an array and separately lists block_cookie_banners. [Screenshot API documentation] [Screenshotbase documentation]

Find a selector that matches the banner

1. Open the target page in a browser and inspect the consent banner.
2. Choose a stable selector for its outer container, such as a site-specific class or ID. Avoid selectors based only on fragile positional structure where possible.
3. Check that the selector matches the banner and not the page’s main content. If the banner has several child elements, hiding the outer container is usually the intended result.
4. Pass that selector using the exact field and request method documented by your screenshot provider.
5. Capture the page and inspect the result. If the banner remains, revisit the selector and the capture timing.

Consent interfaces may be added dynamically, use different markup on mobile and desktop, or change after a site redesign. Selector-based hiding is therefore page-specific; recheck it when the target site changes.

Provider-specific options

Provider	Documented control	Important detail
Screenshot API	blockCookieBanners, hideSelectors, and css	hideSelectors and custom CSS are documented for POST requests. It also documents selector for capturing a particular element and wait controls such as waitForSelector. [Documentation]
Screenshotbase	block_cookie_banners and hide_selectors	Its docs describe hide_selectors as an array of CSS selectors; matching elements are hidden using display: none and visibility: hidden. [Documentation]
ScreenshotAPI.com	blockCookieBanners and waitForSelector	The cited endpoint reference describes automatic banner handling and waiting for a CSS selector. It does not establish a custom hide-selector option for that endpoint. [Endpoint reference]
ScreenshotAPI.net	no_cookie_banners	Its resource-control docs describe this boolean as hiding or blocking banners before rendering and say its default is false. This is that vendor’s documented behavior, not a common API standard. [Resource controls]

These are examples of documented provider controls, not a universal request recipe. Check current endpoint documentation before implementing because method support and field names can vary.

Example request shape

There is no provider-neutral request that can be copied unchanged: the parameter spelling and method are not standardized. A provider-specific request should follow this pattern:

POST /provider-specific-endpoint
Content-Type: application/json

{
  "url": "https://example.com",
  "hideSelectors": [".cookie-consent-banner"]
}

This illustrates the idea only. Use the actual endpoint, authentication, body format, and field names from your provider’s documentation. For Screenshot API, for example, hideSelectors is documented as a POST option. Replace the example selector with one that matches the target page.

Use CSS injection when the API supports it

If the provider accepts CSS to apply before capture, a rule can hide a known banner:

.cookie-consent-banner {
  display: none !important;
}

Send the rule using the provider’s documented CSS field and request format. The selector above is illustrative; it will not match every site. CSS injection and hide-selector features are provider-specific, and the docs should say when they run in relation to page rendering.

Wait for asynchronously rendered consent UI

A banner that appears after JavaScript runs may not exist when the screenshot service first loads the page. If your provider supports waiting for a selector, wait for the banner to appear before hiding it or capturing the page. Alternatively, use a documented navigation or network-idle wait strategy when appropriate. Screenshot API and ScreenshotAPI.com document selector-based wait controls. [Screenshot API documentation] [ScreenshotAPI.com endpoint reference]

Waiting for a banner that never appears can waste time or cause a timeout, so use a selector and timeout suited to the target site. If the provider’s built-in banner handling already covers the page, custom waiting may not be needed.

Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server. Its clean-shot processing accepts cookie and consent banners like a visitor and removes more than 60 known consent platforms, newsletter popups, and chat widgets before capture; each step can be turned off. Only clean shots are billed: bot checks, CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, and the response reports the page verdict and billing status in headers. AI agents can use its MCP tools to take screenshots, get page information, and capture PDFs.

One GET request returns the screenshot. See the ScreenshotNeo API documentation for options and setup.

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

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}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await Bun.write('shot.webp', res);

Cookie banners, popups, and chat widgets are removed before the shot. Bot checks, blank pages, and failed loads are never billed. An MCP server lets AI agents take screenshots. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000. Sign up for 1,000 free screenshots a month—no card required.

Troubleshooting

Symptom	Likely cause	What to do
The banner is still visible	The selector does not match the live banner, or it appears after the hide step.	Inspect the rendered page, correct the selector, and use a documented wait control if the banner is inserted asynchronously.
The whole page or wrong content disappears	The selector is too broad or matches a shared container.	Use a more specific banner-container selector and verify it does not match the main page wrapper.
The API rejects the parameter	Wrong field spelling, wrong data type, or unsupported HTTP method.	Check the provider’s endpoint docs. For example, one API may use hideSelectors while another uses hide_selectors; some controls may be POST-only.
Banner handling works on desktop but not mobile	The site may render a different consent component at a narrow viewport.	Inspect the mobile layout and add the appropriate selector if the API supports multiple selectors.
The banner flashes or is captured before it is hidden	Capture timing and consent rendering are out of sequence.	Use a supported wait-for-selector or CSS injection mechanism, and confirm when the provider applies it.
A wait request times out	The selector never appears on that page or region.	Verify the selector in the browser, check whether consent is suppressed for that visit, and shorten or remove the wait when it is optional.

Performance, reliability, and cost

• Keep selectors narrow. A precise selector is easier to validate and less likely to remove unrelated content.
• Use waits only when needed. Waiting for a late banner can make capture more reliable, but an unnecessary wait adds latency and may time out.
• Revalidate after site changes. Selector hiding depends on the target DOM, which can change during redesigns or consent-tool updates.
• Check billing semantics. Providers define billing differently. Read the response and pricing documentation for the service you use; do not infer billing behavior from a successful HTTP response alone.

FAQ

Can I use a capture selector to hide a cookie banner?

No. A capture selector selects the element to include in the screenshot; a hide selector targets an element to remove. Check for separate options in the provider’s docs.

Is there one standard parameter for hiding cookie banners?

No. Documented examples include hideSelectors, hide_selectors, and provider-specific automatic banner flags.

Will a custom selector work on every website?

No. It must match the target site’s rendered markup, and that markup can differ by device or change over time.

Does hiding a banner change the site’s consent state?

Visual hiding removes content from the capture; it does not itself establish that consent was granted. Follow the site’s and your organization’s requirements for consent handling.