ScreenshotAPI Capture Options for Blocking Ads and Tracking Scripts

To keep ads and consent banners out of a ScreenshotAPI capture, set block_ads=true and no_cookie_banners=true. Add block_tracking=true when you also want to suppress known analytics and tracking requests. These options have separate jobs: ad requests, tracking requests, and consent overlays are not the same thing. They default to false, so those resources are allowed unless you opt in to blocking them.

This guide covers ScreenshotAPI’s documented request options for cleaning captures. Blocking resources changes the page environment, so use the narrowest controls that produce the image you need. The source documentation describes common ad networks, known tracking domains, and “most” cookie banners; it does not promise that every ad or consent implementation will be caught. See the ScreenshotAPI parameter documentation and its help page for the current parameter details.

1. Choose what to block

Start with the page element or request you want removed, then consider whether the page depends on it. For an ad-free presentation or visual comparison, block ads. For a privacy-oriented or less tracking-dependent render, block tracking too. If a consent overlay is the problem, enable the cookie-banner option. These controls are not a universal page-cleaning switch.

Option	What it targets	Documented default	Use it when	Possible tradeoff
`block_ads`	Requests to common ad networks before rendering	`false`	Ad content obstructs a report, presentation, documentation image, or visual comparison.	Ads will not appear as they might for a visitor.
`block_tracking`	Known tracking domains and analytics services during rendering	`false`	You want tracking suppression, fewer tracking-driven differences, or fewer tracking requests.	Tracking-dependent behavior may not run as it would in a visitor’s environment.
`no_cookie_banners`	Cookie and consent pop-ups	`false`	A consent overlay covers the page. ScreenshotAPI’s help page recommends pairing it with `block_ads=true` for common banner and ad clutter.	Consent UI is intentionally absent from the capture; coverage is not guaranteed for every custom implementation.
`block_chat_widgets`	Chat widget scripts and requests	`false`	A support bubble obscures content or is irrelevant to the capture.	The chat feature will not appear or function in the captured page.
`block_js`	JavaScript execution	`false`	The desired page is static and does not need script-rendered content.	Scripts may provide layout, content, or functionality; blocking them can produce an incomplete or broken render.
`block_specific_requests`	Selected URLs, file paths, or patterns	Empty string	One known endpoint, script, or domain is the problem and broad blocking removes too much.	A pattern that is too broad can block needed content; one that is too narrow may miss variants.

ScreenshotAPI also documents controls for stylesheets, images, media, fonts, text tracks, Fetch API requests, and EventSource connections. Their documented defaults are false. Blocking a resource class removes what it supplies: stylesheets can remove styling, images and media remove visual content, and Fetch or EventSource blocking can remove data or live updates. Enable these only when those resources are not needed for the intended screenshot.

2. Make the basic request

For a capture with common ads and cookie overlays suppressed, send both options as true. Add block_tracking only if tracking suppression is also part of the goal. The exact endpoint, authentication parameters, and output handling depend on your ScreenshotAPI account and current API documentation; the examples below show the option values to include in a request.

cURL

curl -G "https://shot.screenshotapi.net/screenshot" \
  --data-urlencode "token=YOUR_SCREENSHOTAPI_TOKEN" \
  --data-urlencode "url=https://example.com" \
  --data-urlencode "block_ads=true" \
  --data-urlencode "no_cookie_banners=true" \
  --data-urlencode "block_tracking=true" \
  -o capture.png

Python

import requests

params = {
    "token": "YOUR_SCREENSHOTAPI_TOKEN",
    "url": "https://example.com",
    "block_ads": "true",
    "no_cookie_banners": "true",
    "block_tracking": "true",
}
response = requests.get(
    "https://shot.screenshotapi.net/screenshot",
    params=params,
    timeout=90,
)
response.raise_for_status()
with open("capture.png", "wb") as image_file:
    image_file.write(response.content)

Node.js

const params = new URLSearchParams({
  token: 'YOUR_SCREENSHOTAPI_TOKEN',
  url: 'https://example.com',
  block_ads: 'true',
  no_cookie_banners: 'true',
  block_tracking: 'true',
});

const response = await fetch(
  `https://shot.screenshotapi.net/screenshot?${params}`
);
if (!response.ok) {
  throw new Error(`Screenshot request failed: ${response.status} ${response.statusText}`);
}
const image = Buffer.from(await response.arrayBuffer());
await import('node:fs/promises').then(({ writeFile }) => writeFile('capture.png', image));

Use the authentication format and endpoint shown in your account’s current documentation if they differ. Treat tokens as secrets: keep them out of source control and avoid logging full request URLs if they contain credentials.

3. Tune blocking without losing page content

Define the intended screenshot. Decide whether it should represent an ad-free content view or the page as a visitor might encounter it. Leave blocking off for resources that belong in a faithful visitor-environment capture.
Start with the narrowest relevant pair. For ad clutter plus a consent overlay, try block_ads=true and no_cookie_banners=true. Do not assume either one handles the other’s target.
Add tracking suppression only for a reason. Set block_tracking=true when analytics or tracking requests themselves should be excluded. It is not required to remove ads or consent UI.
Handle chat separately. Enable block_chat_widgets=true if a floating support control is what obscures the page.
Use targeted request blocking for a single culprit. If one endpoint or script causes trouble, use block_specific_requests with the documented URL, path, or pattern syntax rather than disabling all JavaScript or an entire resource class. The docs say patterns may be separated by commas, spaces, or newlines; check the live parameter documentation for accepted matching syntax.
Inspect the result and relax settings as needed. If content disappears, remove the newest or broadest block first. Keep JavaScript enabled unless the required capture is demonstrably static.

Do not represent a screenshot with blocked resources as a universal record of what every visitor saw. It reflects the configured rendering environment. For reproducible comparisons, keep the same blocking choices across runs and record them alongside the capture.

4. Understand the edge cases

Custom consent dialogs: the documentation says the cookie-banner control handles most banners, not every custom or newly changed dialog. A site-specific overlay may remain.
Ad-supported content: a site may rely on ad scripts for layout or adjacent content. Blocking those requests can change spacing or leave placeholders.
Tracking coupled to application behavior: the documented control targets known trackers and analytics. A page may have other scripts that are not tracking services, and those should not be assumed blocked.
JavaScript-rendered pages: block_js may prevent a single-page app or lazy-rendered section from appearing. Prefer a targeted request rule when possible.
Dynamic requests: blocking Fetch or EventSource can remove data loaded after the initial HTML response. A screenshot may then show a shell, stale state, or empty region.
Resource dependencies: fonts, stylesheets, images, and media each affect visual fidelity. A page can load successfully yet look materially different when one of these classes is blocked.

5. Performance, reliability, and cost considerations

Blocking requests can reduce the work required to load a page, particularly when third-party resources would otherwise be fetched. Actual timing depends on the target site and the resources involved; the reviewed documentation does not provide an independent benchmark, so do not assume a specific speed improvement. Blocking can also make captures less variable when known trackers are responsible for changing content, but it does not guarantee identical results across runs.

For reliable visual comparisons, keep the URL, viewport and other capture settings consistent, use the same blocking options on each run, and verify that the content you care about still appears. If you need a record of the visitor experience, avoid suppressing resources that are part of that experience.

The research material does not establish ScreenshotAPI prices, billing rules, or request quotas for these options. Check your account and current service documentation before estimating cost. Do not infer that enabling a blocking flag changes the price of a capture.

6. Troubleshooting

Symptom	Likely cause	What to try
An ad remains visible	The ad is served from a domain or implementation outside the documented common ad-network coverage.	Check the current parameter docs and consider a targeted `block_specific_requests` pattern for the relevant request.
A cookie notice still covers the page	The banner uses a custom implementation or is not recognized by the banner handling.	Confirm `no_cookie_banners=true` is being sent; inspect the site-specific requests and use a targeted approach if supported by the current API.
The page is blank or incomplete	JavaScript, Fetch, EventSource, or another needed resource may be blocked.	Remove broad resource blocks. Leave JavaScript enabled and re-enable the resource class that supplies the missing content.
Layout looks unstyled or images are missing	Stylesheets, fonts, or image requests were blocked.	Keep those resource classes enabled unless the capture specifically does not need them.
Chat bubble remains	Ad, tracking, and cookie-banner settings do not target chat widgets.	Enable `block_chat_widgets=true` if removing the widget is desired.
Tracking-dependent behavior changes	`block_tracking=true` prevents known tracking and analytics requests from running.	Disable that flag when reproducing a user environment or behavior that depends on those requests.
A targeted block has no effect	The pattern may not match the actual request, or request-pattern syntax may differ from your assumption.	Inspect the current docs, verify the exact request URL or path, and try a narrower documented pattern.
A targeted block removes unrelated content	The matching pattern is too broad or shared by multiple page features.	Narrow the match to the endpoint or file involved; otherwise remove the rule.

7. Or skip the browser setup

If your goal is a clean screenshot rather than configuring a browser capture service, ScreenshotNeo is a website screenshot API and MCP server. Its cleanup accepts cookie and consent banners like a visitor and removes 60+ known consent platforms, newsletter popups, and chat widgets; each cleanup 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 page verdict and billing status in headers. AI agents can use its MCP server tools, including take_screenshot, get_page_info, and capture_pdf. Every feature is on every plan: 1,000 shots a month are free with no card, and paid plans start at $5 for 3,000.

One GET request returns an image or PDF. Here is a cURL example; see the ScreenshotNeo API documentation for the available formats, 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}`);

Start free with 1,000 screenshots a month and no card.

8. FAQ

Do I need to enable both ad and tracking blocking?

No. Use block_ads for ad-network requests and block_tracking for known analytics and tracking requests. They serve different goals.

Do not rely on it for that. Enable no_cookie_banners=true for consent overlays; the help page recommends combining it with ad blocking when both are present.

Should I turn off JavaScript to get a cleaner screenshot?

Usually not. Disabling scripts can break or omit content. Keep scripts available and block the specific resource or overlay that is irrelevant.

The documentation describes common ad networks and most cookie banners. It does not promise universal coverage.

Can I use these settings for a faithful audit of the page?

Only if the audit explicitly concerns the configured, filtered view. For a faithful visitor-environment record, capture with the relevant resources enabled and document the environment.