Why Does a Cookie Consent Banner Appear in My Screenshot After I Accepted It?

A cookie consent banner in a screenshot does not necessarily mean your earlier choice was ignored. The screenshot may use a different browser profile or session, the consent record may have expired or been cleared, privacy settings may block the consent management platform (CMP), site rules may vary by page or location, or the capture may happen before the banner is dismissed.

To find the cause, check the browser context first, then the site’s consent storage, browser privacy and cleanup settings, site configuration, and the screenshot timing. The exact behavior depends on the website’s CMP and how the screenshot was produced.

1. Why an accepted banner can appear again

Consent is usually remembered in browser-side or CMP-managed state. That state has an implementation-specific lifetime and may not be available in every context.

Possible cause	What it means	What to check
Different browser profile or session	A fresh, isolated, or automated browser context may not have the preference saved in the profile where you accepted.	Confirm which profile and context produced the screenshot.
Expired or cleared consent	The preference may expire, or browser settings and extensions may clear cookies and other site data.	Inspect the site’s current consent record and cleanup rules.
Blocked CMP script or storage	Privacy controls may prevent a CMP resource from loading or restrict storage that it relies on.	Check browser protections, extensions, and console or network errors.
Site configuration differs	Rules can depend on the domain, URL, geography, or whether the page is embedded.	Compare the affected page and context with the page where you accepted.
Capture happens too soon	The screenshot may be taken before the page finishes loading or before the consent control is clicked.	Check the automation sequence and wait conditions.

For example, Cookiebot documents a CookieConsent cookie that stores preferences until it expires; after expiry, the banner is shown again. Other CMPs may use different cookie names, local storage, profile rules, or lifetimes. Treat that cookie name as a vendor-specific example, not a universal key. Cookiebot support describes its own behavior.

Site configuration also matters. HubSpot’s troubleshooting guidance includes tracking code, domain and URL rules, geographic targeting, banner settings, page styling conflicts, and iframe cookie restrictions as possible factors. These are avenues to investigate, not a diagnosis of an unspecified website. HubSpot’s consent documentation covers its product.

2. Diagnose the browser and consent state

1. Identify the capture context. Record the browser, profile, session, and whether the screenshot tool starts a new or isolated context. Compare that with the context where you accepted the banner. A private window can deliberately show a first-visit banner because it has separate site state.
2. Inspect the site’s storage. In browser developer tools, inspect cookies and local storage for the site. Look for the CMP’s documented consent record and whether it has expired. Do not assume every CMP uses the same storage key or storage type.
3. Review privacy and cleanup behavior. Check settings that clear site data on exit, tracking protection, and extensions that block scripts or remove cookies. Osano describes restrictions affecting resources and consent persistence for its CMP in some browser configurations; that account is specific to Osano and should not be generalized to every browser or CMP. See Osano’s documentation.
4. Ask the site owner to verify configuration. Confirm the intended CMP loads on the page, the domain and URL rules include it, geographic targeting matches, and an iframe is not preventing the preference from being read or written.
5. Use the CMP’s own inspection or reset procedure. Avoid deleting guessed storage keys or applying another vendor’s reset instructions. For instance, consentmanager documents service-specific profile behavior and a debug-only reset route; its behavior is not a general CMP rule. See consentmanager’s documentation.

Consent integrations can have their own signals too. Microsoft Clarity documents a developer-tools check for Clarity’s consent status and says site owners are responsible for communicating consent changes to Clarity. That check applies to Clarity; it is not a universal way to inspect CMP state. Refer to Microsoft Learn’s Clarity consent guidance.

3. Make automated screenshots wait for dismissal

When the screenshot is automated, make the order explicit: navigate, wait for the page and banner to become available, identify and click the correct control if present, confirm it is gone, and only then capture. Selectors depend on the banner framework and site markup. A generic “accept” selector can miss the real button or click an unintended control.

Browserless provides an example of waiting for the page to settle, checking for a visible consent button, clicking it when found, and then capturing. Adapt the selector to the specific site rather than assuming one selector works everywhere: Browserless guidance.

// Pseudocode: adapt navigation, selector, and wait APIs to your browser library.
await page.goto(targetUrl);
await page.waitForLoadState('domcontentloaded');
const accept = page.locator('YOUR_SITE_SPECIFIC_ACCEPT_SELECTOR');
if (await accept.isVisible()) {
  await accept.click();
  await accept.waitFor({ state: 'hidden' });
}
await page.screenshot({ path: 'page.png', fullPage: true });

This is intentionally a library-neutral sequence, not runnable code for a particular automation package. Use the package’s documented navigation, locator, visibility, click, and screenshot methods. Decide whether your workflow should accept consent: in some tests, preserving the first-visit banner is the desired result.

4. Troubleshooting common symptoms

Symptom	Likely cause	Next step
Banner returns on every scheduled capture	Each run may start a clean browser context with no saved preference.	Check context reuse and consent persistence. If each run is intentionally isolated, handle the banner in the capture flow.
Banner returns after closing the browser	Site data may be cleared on exit, or the preference may have expired.	Review browser cleanup settings and the CMP’s documented expiry behavior.
Banner appears only in one browser	Browser privacy controls, extensions, or storage behavior may differ.	Compare blocked requests, storage, and protection settings in the affected browser.
Banner appears only on a particular URL or region	URL rules, domain setup, or geographic targeting may differ.	Have the site owner check CMP configuration for that exact URL and location.
Banner appears inside an embedded page	The embedded context may not be able to access the same consent state.	Check iframe behavior and the CMP’s supported embed configuration.
Automation clicks nothing or captures the banner	The selector may be wrong, the control may not yet be visible, or capture may run before the click completes.	Wait for the actual control, verify visibility, click it, and wait for dismissal before capture.
Consent appears saved but the banner remains	The stored value may be expired, invalid for the current profile, or not applicable to that page.	Use the CMP’s documented diagnostic path and check its own validation rules.

5. Or skip the browser setup

If your goal is a clean screenshot rather than testing a site’s consent behavior, ScreenshotNeo is a website screenshot API and MCP server. It accepts cookie and consent banners before capture and removes more than 60 known consent platforms, newsletter popups, and chat widgets; each step can be turned off. Bot checks and CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, and response headers report the page verdict and billing status. Its MCP server gives Claude, Cursor, and other MCP clients the take_screenshot, get_page_info, and capture_pdf tools.

Make one GET request with your API key and target URL. See the ScreenshotNeo API documentation for the options and response details.

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}`);

Cookie banners, popups, and chat widgets are removed before the shot; bot checks, blank pages, and failed loads are never billed; AI agents can take screenshots through the MCP server; and 1,000 screenshots a month are free with no card. Paid plans start at $5 for 3,000 shots. Sign up for 1,000 free screenshots a month, with no card required.

6. Performance, reliability, and cost considerations

• Wait for the condition you need. Waiting for a specific consent control and its dismissal makes the capture sequence clearer than relying on an arbitrary short delay. A site may still load content after that, so use an additional site-appropriate readiness condition when necessary.
• Use stable selectors and make dismissal conditional. Banner markup varies, and a banner may not appear on every visit. Check visibility before clicking and verify it disappears; otherwise automation can fail or capture the wrong state.
• Choose the intended test state. Reusing a profile can preserve consent between captures, while isolated contexts reproduce first-visit behavior. The right choice depends on whether the goal is a returning visitor screenshot or a first-visit screenshot.
• Account for retries carefully. A failed navigation, blocked CMP resource, or delayed banner can make a capture appear inconsistent. Log the browser context, URL, wait outcome, and whether a consent control was found so reruns can be compared.
• Understand screenshot service billing. ScreenshotNeo states that only clean shots are billed; bot checks/CAPTCHAs, blank pages, timeouts, failed loads, and cache hits are free. Its plans are Free: 1,000/month; Starter: $5 for 3,000; Growth: $15 for 15,000; Pro: $39 for 60,000; Scale: $99 for 250,000; Business: $249 for 1,000,000. Yearly billing gives two months free, and all features are on every plan. Confirm current details in its docs before integrating.

7. Frequently asked questions

Does seeing the banner prove my acceptance was not saved?

No. It can mean the screenshot used another context, the saved state expired or was cleared, a site rule differed, or capture happened before dismissal.

Is there one cookie name I can delete to reset every consent banner?

No. Storage names and reset behavior depend on the CMP and site. Use the vendor’s documentation for the specific website.

Should automated tests accept the banner?

Only if that matches the test objective. Accept it to capture a returning-visitor state; leave it visible when testing the first-visit experience.

Can I use Microsoft Clarity’s consent check for any site?

No. The documented developer-tools check is for Clarity’s own consent integration and does not inspect every CMP.