Microlink Screenshot Options for Hiding Cookie Banners and Pop-ups

Microlink can block many third-party ads, trackers, and consent-service requests before a page renders. That does not guarantee every cookie banner or pop-up disappears: a banner built into the site itself is first-party page UI. For those, use Microlink’s documented page controls to inject CSS, click a relevant control, or run a script. On dynamic pages, wait for the intended content or state before capturing.

Use the approach that matches the screenshot’s purpose. Hiding a banner with CSS changes its appearance; it does not mean the visitor accepted consent. If you need to document or audit the consent experience, leave it visible.

Choose the right Microlink option

What you see	Option	Effect
Third-party ads, trackers, or consent-service content	adblock	Blocks matching requests before rendering. Microlink documents adblock as enabled by default; a first-party banner may still appear.
A known first-party banner that should only be absent from the image	styles	Injects CSS to hide the matching element visually. It does not accept consent or change the site’s underlying behavior.
A banner with a close, dismiss, or accept control	click	Clicks the chosen selector before capture, which can change page state.
A custom interaction that styles or a click cannot express	scripts	Runs JavaScript in the page context before capture.
Content appears after the initial page load or after dismissal	waitUntil and waitForSelector	Waits for navigation readiness and then for a specific element or state to exist.

Microlink describes adblock as handling third-party requests, while first-party banner dismissal uses page-level controls. See its adblock documentation and API parameter documentation for current names and syntax.

Prepare a reliable capture

1. Inspect the page first. Identify whether the banner comes from a third-party consent service or is part of the site. Find a stable selector for the banner and, if dismissing it, the actual control.
2. Choose the intended behavior. Use adblock for matching third-party requests; use CSS to hide a visual element; use a click when you want the page’s own close or accept action to run.
3. Wait for the right state. Choose a navigation lifecycle wait appropriate to the page, then use waitForSelector for the content or state that should be in the screenshot. A fixed delay is a fallback when there is no stable selector, but can waste time or still be too short.
4. Capture and inspect the output. If the banner remains, verify the selector and whether the page uses an iframe or shadow DOM. If the main content is missing, adjust the wait condition rather than simply increasing delays indefinitely.

Microlink’s screenshot API returns captures through a REST API. The examples below show the request shape; check the current official parameter documentation for exact accepted values and response handling before integrating.

Inject CSS to hide a known banner

Use the page’s actual selector. This example illustrates the CSS rule; replace .cookie-banner with the selector you inspected. The selector is site-specific, and hiding the node does not represent consent acceptance.

// Illustrative injected CSS rule:
.cookie-banner {
  display: none !important;
}

Pass that rule through Microlink’s documented styles parameter using the encoding and request format specified in its current API docs. Avoid broad selectors such as div or [role="dialog"] unless you have verified they target only the unwanted interface; otherwise you may hide page content or accessibility dialogs too.

Dismiss a banner with a click

If the page has a close button and the screenshot should show the state after dismissal, use Microlink’s click option with the selector for that control. For a consent button, only click it when that action matches your capture objective and is appropriate for the page. Clicking an accept control changes page state; it is not equivalent to merely hiding the banner.

// Selector examples to inspect in the target page:
button[aria-label="Close"]
.cookie-banner button.dismiss

These are selector examples, not universal selectors. Consult Microlink’s parameter documentation for the precise click request syntax. If a click appears to do nothing, check that the control exists at click time, is not covered by another element, and is inside the main document rather than an iframe.

Use scripts for custom behavior

When a simple click or stylesheet is insufficient, Microlink documents a scripts option for JavaScript in the page context. Keep the script narrowly scoped: locate the specific interface, perform the required action, and avoid changing unrelated page content. Script execution can be sensitive to load timing, page framework behavior, and cross-origin boundaries; prefer a documented click or CSS rule when it fully solves the task.

Microlink’s API parameters can evolve. Confirm the current supported script format and when scripts execute in the official API documentation rather than relying on guessed query syntax.

Wait for the post-banner page state

On a single-page application or a page with asynchronous content, dismissal and readiness are separate steps. A successful click does not guarantee that the content beneath the banner has rendered. Use a navigation wait suited to the page and then wait for a stable selector that signals the content you need is present. Prefer a selector wait over an arbitrary sleep when a suitable element exists.

For example, the readiness condition might be a page heading or the main content container. Avoid waiting for a selector that disappears when the banner closes; that can cause a timeout even though the page is ready. See Microlink’s wait parameter guidance for the currently supported waitUntil, waitForSelector, and delay syntax.

When not to suppress the interface

• Consent audits or bug reports: capture the banner as shown to visitors.
• Stateful accept or reject flows: do not click a choice unless the resulting state is specifically what you need to record.
• Third-party blocking changes the page: if consent scripts or embedded content are needed for the target state, blocking them may remove more than visual clutter.
• Unclear selector ownership: inspect the page before applying a broad CSS rule or script.

Troubleshooting

Symptom	Likely cause	Fix
Banner still appears with adblock enabled	It is first-party UI, or its requests do not match blocked third-party resources.	Use a verified banner selector with styles, or use the page’s dismiss control with click.
The whole page or a large section disappears	The injected CSS selector is too broad.	Inspect the DOM and target a specific banner class or identifier.
Click does not dismiss the banner	Wrong selector, control not yet present, overlay interception, iframe, or custom event behavior.	Confirm the selector and timing; target the actual control, and check whether it is inside a frame. Use a script only if the documented interaction cannot express the needed action.
Screenshot captures a loading state	Navigation readiness did not include the delayed content.	Add a wait for a stable content selector after navigation or dismissal.
Selector wait times out	The selector is wrong, only appears in a frame, or the expected state never occurs.	Verify the selector in the intended state and use a selector that remains present once ready.
Page looks different after blocking consent requests	The blocked service may also control page behavior or embedded content.	Test the capture objective with blocking enabled and disabled; choose page-level hiding if you only need visual removal.

Performance, reliability, and cost

Blocking requests can prevent third-party resources from loading, while CSS hiding changes presentation after the page is available. Clicks and scripts depend on the page reaching the expected state. These approaches have different failure modes, so make the capture wait condition specific and keep selectors narrow. No performance benchmark is asserted here.

Microlink’s official API overview listed a free tier of 25 requests per day at the time of the research. This is a vendor plan limit and may change; verify the current plan before budgeting. The available dossier does not establish request costs for failed captures or cache hits, so check current Microlink plan and billing documentation for those details.

Or skip the browser setup

ScreenshotNeo is a screenshot API and MCP server. Its one-call API can capture a page while handling common visual clutter:

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 docs for setup and options. Cookie banners, pop-ups, and chat widgets are removed before the shot; each step can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing, and response headers say which outcome occurred. Its MCP server lets AI agents use take_screenshot, get_page_info, and capture_pdf. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 screenshots.

Sign up free for 1,000 screenshots a month, with no card required.

FAQ

Does Microlink automatically remove every cookie banner?

No. Its documented adblock handles matching third-party requests, while a first-party banner may need a page-level style or interaction.

Does CSS hiding accept consent?

No. It changes the visual display of an element; it does not represent that a visitor accepted consent.

Should I use a fixed delay or wait for a selector?

Use a selector tied to the intended content or page state when one is available. A fixed delay is less precise.

Can I use this for a consent experience screenshot?

Yes, but leave the interface visible when the purpose is to document or audit the consent experience.