Consent banners

Remove the cookie banner before the shutter, not after

Every capture starts from an empty browser profile, so every capture is a first visit — and a first visit is exactly who the consent banner is built for.

block_cookie_bannersblock_banners_by_heuristicshide_selectors
curl --fail-with-body "https://api.pagecapture.dev/v1/take" \
  -H "X-Access-Key: $PAGECAPTURE_KEY" \
  -H "Content-Type: application/json" \
  --data '{"url":"https://example.com","format":"jpg","block_cookie_banners":true,"block_banners_by_heuristics":true}' \
  -o capture.jpg

Verified 2026-08-13 by running the published code against a fixture.

Configure it in the playground
What you are seeing

The same grey overlay sits across the middle of every screenshot, and the content you wanted is behind it.

Why the page does that

A capture runs in a fresh, isolated browser context. There is no stored consent to carry over, so the banner renders exactly as it does for someone who has never visited.

What it does

  • Hides the containers published by 12 consent platforms — OneTrust, Cookiebot, Quantcast, CookieYes, Osano, Termly, Usercentrics, Didomi, Iubenda, Complianz, Borlabs and two generic GDPR layouts.
  • Clicks the reject button where the platform exposes a stable one, with a 1.5 second budget per attempt — a button that is missing or slow is skipped, never fatal.
  • Runs after `styles` and before `scripts`, so a script of yours sees the page with the banner already gone.

What it does not do

  • Does not accept tracking on your behalf: where a reject control exists, that is the one it clicks.
  • Does not remove a paywall, a newsletter modal or an age gate. Those are not consent banners, and `hide_selectors` is the honest tool for them.
  • Does not promise every banner. A banner with no known rule needs `block_banners_by_heuristics`, and that pass is explicitly best effort.
The contract

Every limit on this page is the one the API enforces

These rows are read from the same parameter table that validates your request. Nothing here is transcribed, so a number cannot drift from the behaviour it describes.

ParameterTypeDefaultRangeEndpointsCache key
block_cookie_banners

Remove consent banners using known rules.

booleanfalse/v1/take, /v1/animateIn
block_banners_by_heuristics

Also try a heuristic pass for banners with no known rule.

booleanfalse/v1/take, /v1/animateIn
hide_selectors

Selectors to hide before capturing.

string[]/v1/take, /v1/animateIn
Group: BlockingValues outside a documented range are rejected before a browser opens.

How it behaves next to the rest of the request

block_banners_by_heuristics

Also try a heuristic pass for banners with no known rule.

The heuristic pass looks for a fixed or sticky element covering more than half the viewport width whose text mentions consent, clicks a reject-style button inside it when there is one, and hides it otherwise. It also releases the `overflow` and `position` locks that consent scripts leave on the document — without that, a full-page capture of a site that froze scrolling would still come back as one fold.

hide_selectors

Selectors to hide before capturing.

For a banner nothing recognises, pass its container to `hide_selectors`. Hidden elements use `visibility: hidden`, so the space stays and the rest of the page does not jump.

cache

Serve and store this capture from the cache. Cache hits are never charged.

Both blocking flags are part of the cache key. Toggling one produces a different capture and therefore a different cached entry — you never receive a banner-free image for a request that asked for the banner.

Errors this option can produce

None of them is billable. No error code in the catalog is.

Questions this raises

Does hiding the banner mean you accepted the cookies?

No. The known rules hide the container, and where the platform publishes a stable reject control that is what gets clicked — OneTrust's reject handler before its accept handler, Cookiebot's decline button. Nothing is consented to on your behalf.

Why is it off by default?

Because a website audit often needs the banner in the evidence. Removing it by default would quietly destroy the thing some customers are capturing.

The banner on my target is still there. What now?

Turn on `block_banners_by_heuristics` first. If it survives that too, pass its container in `hide_selectors` — that always wins, because it is your selector rather than our rule.