ScreenshotNeo

BlogGuides

What Is a Cookie Banner?

A cookie banner explains cookies and manages consent choices. Learn what it does, when it may be required, and how to test it.

By the ScreenshotNeo team1 October 20269 min read

A cookie banner is a website message or interface that explains the site’s use of cookies or similar tracking technologies and, where required, lets visitors manage consent choices. It is the interface a visitor sees; a cookie is the small data file or other storage technology behind the scenes.

Whether a banner is required depends on the technologies a site uses, their purposes, available exemptions, and the law that applies in the relevant jurisdiction. A banner by itself does not prove that a site is compliant.

A cookie is a small text file that a website can place on a visitor’s device. The UK Information Commissioner’s Office (ICO) says cookies can let a website recognise a device and store information about preferences or previous actions. Websites also use related storage and access technologies, such as local storage or tracking pixels, so regulatory guidance often uses broader wording than “cookies.”

Cookies may be set by the site you are visiting (first-party cookies) or by another service embedded in that site (third-party cookies). They can support functions such as keeping items in a shopping cart, remembering a language, measuring visits, personalising content, or advertising. The purpose matters when deciding whether consent is needed.

A banner gives visitors information and a way to record choices. Common controls include:

  • Accept all: permits all optional purposes described by the site.
  • Reject or refuse: declines optional purposes where the site offers that choice.
  • Customize or manage preferences: opens purpose-specific controls.
  • More information: links to a cookie notice or privacy information.

The ICO says consent requests should be specific to their purpose. A useful preference panel therefore describes categories in understandable language, explains what each category does, and avoids bundling unrelated purposes into one vague choice.

The Irish Data Protection Commission notes that a banner, interstitial, or pop-up is a common way to provide notice and manage preferences. The banner is not the cookie itself, and its presence does not show whether the underlying scripts waited for consent or whether a recorded choice is honoured.

Why do websites ask me to accept cookies?

Websites ask because some storage and access operations need permission under the rules that apply to the site and visitor. A site may also use a banner to explain technologies that are exempt from consent but still require information.

Typical reasons include:

  • Keeping you signed in or maintaining a shopping cart.
  • Remembering settings such as language or display preferences.
  • Measuring how pages are used.
  • Supporting advertising, profiling, or cross-site measurement.
  • Loading embedded services such as video, maps, chat, or social widgets.

Do not assume that every cookie requires consent. Regulators distinguish between technologies and purposes, and exemptions may apply. The ICO’s UK PECR guidance says organisations must explain what cookies do and why, and obtain consent where the rules require it.

No. The answer depends on what the website stores or accesses, why it does so, which exemptions apply, and the jurisdiction involved. The Irish Data Protection Commission’s FAQ specifically explains that banners are common but are not automatically required for every site.

For example, a strictly necessary session cookie may fall within an exemption in one legal framework, while analytics or advertising technologies may require consent. A site serving visitors in several regions may need a consent design that accounts for more than one set of rules. Get advice for your own technologies and locations before relying on a generic pattern.

The French CNIL describes a requirement to inform users and obtain consent before non-exempt cookies or trackers are stored or read. That is French regulatory guidance, not a complete statement of the law everywhere.

Use these practical checks when reviewing a banner:

  1. Clear notice: state that cookies or similar technologies are used and link to details.
  2. Purpose information: explain purposes such as necessary operation, analytics, personalisation, or advertising.
  3. Meaningful choices: provide accept, refuse, or equivalent controls when consent is required.
  4. Granularity: let a person choose by purpose instead of forcing one blanket decision.
  5. No pre-ticked opt-ins: the EDPB Cookie Banner Taskforce report says participating authorities considered pre-ticked opt-in boxes invalid consent.
  6. Accessible controls: make buttons usable with a keyboard, readable by assistive technology, and understandable on mobile.
  7. Choice persistence: record the decision and provide a way to change it later.
  8. Non-disruptive design: avoid covering essential content or using confusing visual emphasis.

The EDPB report says a vast majority of participating authorities considered a banner with an accept button but no refuse or not-consent option on any layer inconsistent with valid consent. Present this as the report’s account of authorities’ views; interface rules can differ by country.

What happens when I click “Accept”?

Usually, the consent manager records your choice and enables the scripts or storage categories covered by that choice. The exact sequence varies. Some sites set a preference cookie first, then load analytics or advertising scripts. Others send the decision to a consent-management service.

Clicking “Accept” is not automatically required to use every website. A site should explain what happens if you refuse optional purposes, and essential functions should continue where possible. Seeing a banner also does not prove that scripts are blocked before consent or that the site will respect a later withdrawal.

For a basic review, use a private browser window and clear existing site data so an earlier choice does not hide the banner.

  1. Open the page in a private window with browser extensions disabled.
  2. Record which controls appear before making a choice.
  3. Open developer tools and inspect the Network and Application or Storage panels.
  4. Reload without interacting and check whether optional requests or storage occur before consent.
  5. Choose refuse, reload, and check whether optional requests remain blocked.
  6. Choose customize, enable one purpose, and verify that only the related technology loads.
  7. Look for a persistent settings link so the choice can be changed later.

These checks are technical observations, not a legal compliance determination. Test the regions, devices, and consent modes your service actually supports.

Capture a page without banners for documentation

A screenshot can document how a banner appears, but automated captures often encounter consent dialogs, newsletter popups, chat widgets, bot checks, or pages that fail to load. A browser script gives you control; an API can handle the setup for repeatable captures.

Browser automation approach

With Playwright, load the page, dismiss the banner according to the site’s own controls, then capture the result. Selectors differ by consent platform, so keep them configurable.

import { chromium } from 'playwright';

const browser = await chromium.launch();
const page = await browser.newPage({ viewport: { width: 1440, height: 900 } });
await page.goto('https://example.com', { waitUntil: 'networkidle' });

const reject = page.getByRole('button', { name: /reject|refuse|decline/i }).first();
if (await reject.isVisible().catch(() => false)) {
  await reject.click();
}

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

For production use, add timeouts, retries, a stable selector list for the consent systems you encounter, and a fallback when no banner is present. Never assume that a button labelled “Reject” has the same effect in every jurisdiction or site implementation.

Or skip the browser setup

ScreenshotNeo provides a website screenshot API and MCP server. One GET request returns a PNG, JPEG, WebP, or PDF. Before capture, it accepts the cookie or consent banner like a visitor and removes more than 60 known consent platforms, newsletter popups, and chat widgets; each step can be turned off.

Only clean shots are billed. Bot checks or CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, and the response identifies the result with X-Page-Verdict and X-Billed headers. The MCP server exposes take_screenshot, get_page_info, and capture_pdf for Claude, Cursor, and other MCP clients.

See the ScreenshotNeo documentation for all options.

cURL

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

Python

import requests

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

Node.js

const q = new URLSearchParams({
  access_key: 'YOUR_API_KEY',
  url: 'https://example.com'
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`HTTP ${res.status}`);
const data = Buffer.from(await res.arrayBuffer());
await import('node:fs/promises').then(fs => fs.writeFile('shot.webp', data));

ScreenshotNeo includes full-page capture with lazy images loaded, CSS-selector element capture, dark mode, device presets and custom viewports, retina scale, custom CSS and JavaScript, click actions, hide selectors, waits, request and resource blocking, headers, cookies, user agents, authorization, timezone, geolocation, transparent backgrounds, resizing, configurable caching, signed links, asynchronous jobs with signed webhooks, bulk capture for up to 100 URLs per call, a usage API, and an OpenAPI specification. Parameter names used by other screenshot APIs also work, which can simplify migration.

Plans include 1,000 free shots per month with no card; paid plans start at $5 for 3,000 shots. Yearly billing gives two months free, and every feature is available on every plan. Create a free ScreenshotNeo account.

Problem Likely cause Fix
The banner does not appear A previous consent cookie or cached state exists. Use a private context, clear site storage, and test a fresh profile.
Optional scripts load before a choice Consent is recorded visually but blocking is not implemented. Inspect network requests before interaction and review the consent manager configuration.
Reject is missing The site exposes only an accept control or hides refusal on another layer. Check every layer and region; compare the design with applicable guidance.
Automation times out The page is slow, blocked, or waiting for a resource that never finishes. Set explicit navigation and selector timeouts, wait for a meaningful selector, and capture diagnostics.
A screenshot contains a popup The popup appears after the initial load or uses a different selector. Wait briefly, dismiss known selectors, or use ScreenshotNeo’s popup and consent cleanup.
The page is blank Bot protection, a JavaScript error, or a failed third-party dependency. Check the page verdict and response headers, retry with a realistic viewport, and inspect logs.

Performance, reliability, and cost considerations

  • Performance: full-page shots and lazy-image loading take longer than a viewport capture. Use a selector capture when you only need the consent component.
  • Reliability: wait for a selector or network idle instead of sleeping for an arbitrary fixed time. Record the URL, viewport, consent state, and timestamp with each artifact.
  • Caching: cache stable pages with a TTL you choose; bypass or shorten the TTL when validating a newly changed banner.
  • Cost: batch related URLs where appropriate and avoid recapturing unchanged pages. ScreenshotNeo does not bill cache hits or failed page classes listed in its response verdict.
  • Privacy: use test accounts and avoid placing personal data in URLs, cookies, or custom headers used for captures.

Frequently asked questions

No. A banner is an interface for notice and choices. A privacy or cookie notice provides longer explanations about data use, purposes, providers, retention, and rights.

Can I refuse cookies and still use a site?

Often you can continue with essential functions, but optional features may be unavailable. The result depends on the site and the technologies it uses.

It removes local records but may not update a server-side consent log or every linked service. Use the site’s privacy settings when available.

No single worldwide rule applies. Requirements vary with technology, purpose, exemptions, and jurisdiction.

No. Compliance depends on the underlying collection, blocking, information, consent, and withdrawal practices.

Primary guidance