ScreenshotAPI.net Request Parameters for Blocking Ads and Trackers

To filter common ad network requests in a ScreenshotAPI.net capture, set block_ads=true. To block requests to known tracking and analytics domains, set block_tracking=true. Both default to false. Cookie-consent overlays use a separate setting, no_cookie_banners=true. For one specific endpoint or script, use block_specific_requests. These are documented controls, not a guarantee that every ad or tracker on every site will be caught. ScreenshotAPI.net resource blocking documentation.

Use the narrowest control that addresses the capture problem. Broadly blocking JavaScript, XHR, or Fetch can remove dynamic content and page functionality. First inspect the result with blocking off, then enable one parameter at a time and compare the output.

1. Choose the request control that matches the problem

Goal	Parameter	Documented behavior and default	Tradeoff
Filter common ad network requests	block_ads=true	Blocks requests to common ad networks. Default: false.	Documentation does not promise removal of every ad on every site. Ads embedded in page content or delivered through first-party infrastructure may remain.
Block known analytics and tracking requests	block_tracking=true	Blocks requests to known tracking domains and services. Default: false.	This is known-domain filtering, not a guarantee that all tracking techniques are detected. A script can also affect page behavior.
Hide consent overlays	no_cookie_banners=true	Blocks or hides cookie-consent banners and popups. Default: false.	This is separate from ad and tracking request filtering. It addresses overlays; it does not mean that all consent-related network requests are blocked.
Block a particular request	block_specific_requests	Accepts one or more URL, path, or pattern rules. Entries may be comma-, space-, or newline-separated.	You need to identify the unwanted request. Pattern matching behavior can depend on the rule and request; validate the result on the target page.
Prevent JavaScript resources from loading	block_js=true	Blocks JavaScript resources. Default: false.	Dynamic content, interactive features, and client-rendered page sections may not load.
Block asynchronous data requests	block_xhr=true or block_fetch=true	Blocks XHR or Fetch requests. Defaults: false.	API-driven content and data loaded after the initial document can be missing.
Stop server-sent live updates	block_event_source=true	Blocks EventSource/SSE connections. Default: false.	Real-time updates will not appear in the capture.

ScreenshotAPI.net’s resource-blocking documentation describes blocking requests to known tracking domains before rendering. The practical scope still depends on the target site’s requests and the service’s current filtering rules; the documentation does not establish universal coverage.

2. Add the settings to a request

The exact endpoint and authentication fields depend on the API version and your account configuration. The official Playground shows a v3 request shape using https://shot.screenshotapi.net/v3/screenshot, a token, a target URL, and output options. Check the current ScreenshotAPI.net Playground and parameter documentation for the request fields that apply to your integration.

For the documented Help example, the key settings to add are block_ads=true and no_cookie_banners=true. Add block_tracking=true when you also want known tracking and analytics requests filtered. A query string conceptually looks like this; supply the endpoint, authentication, URL encoding, and output fields required by your API version:

block_ads=true&no_cookie_banners=true&block_tracking=true

As a version-specific illustration of the v3 request shape shown in the Playground, a request can be composed as follows. Confirm the precise accepted names and response behavior against the live documentation before using it:

curl -G 'https://shot.screenshotapi.net/v3/screenshot' \
  --data-urlencode 'token=YOUR_API_TOKEN' \
  --data-urlencode 'url=https://example.com' \
  --data-urlencode 'block_ads=true' \
  --data-urlencode 'block_tracking=true' \
  --data-urlencode 'no_cookie_banners=true'

The source material establishes these parameter names and behaviors but does not specify a complete response-saving command, language SDK signatures, or the current required authentication field for every account. Use the Playground to complete those version-specific details rather than assuming a response format.

3. Apply request rules narrowly

Block a known endpoint

If a single third-party request causes an unwanted widget or tracking call, use block_specific_requests instead of disabling a broad class of traffic. The documentation says it can accept URL, path, or pattern rules and that multiple entries may be separated by commas, spaces, or newlines. Use the exact syntax accepted by the current API for your request encoding.

block_specific_requests=analytics.example/path,ads.example/script.js

The domains above are placeholders, not known ScreenshotAPI.net rules. Inspect the actual request that you intend to block and verify that the page still renders the content you need.

Keep the page’s data loading intact

Start with block_ads, block_tracking, or no_cookie_banners as appropriate. Only try block_js, block_xhr, block_fetch, or block_event_source if you specifically need to stop those resource types and can accept their effects. For a page that depends on API calls to render its main content, blocking XHR or Fetch can produce a mostly blank capture even if the document itself loads.

4. Validate the capture

1. Capture the target with the blocking settings disabled and save the baseline result.
2. Enable just the setting that matches the issue. For ads plus a consent overlay, the Help page recommends block_ads=true with no_cookie_banners=true.
3. Compare the resulting screenshot against the baseline: check that the content you need remains, the overlay is gone, and the unwanted requests no longer affect the rendered page.
4. Add block_tracking=true or a specific request rule only if needed, then compare again.
5. If a section goes missing, remove the last broad blocking option and narrow the rule to a specific request.

ScreenshotAPI.net documents the settings and their intended behavior. This workflow is a validation method for your page; it is not a claim that a particular site or rule has been independently tested.

5. Troubleshoot common results

Symptom	Likely cause	What to try
Ads still appear	block_ads targets common ad network requests; coverage is not described as universal. An ad may be served through the site’s own domain or already be part of page content.	Confirm the parameter is included and set to true. If you know the responsible URL or path, try block_specific_requests. Do not assume every ad can be filtered.
A cookie banner still covers the page	Ad blocking does not turn on cookie-banner handling; they are separate controls.	Add no_cookie_banners=true and verify the exact parameter name in the current documentation.
Analytics still seems to run	block_tracking covers known tracking domains and services, not every analytics implementation.	Check which request remains and use a specific request rule if appropriate. Avoid treating the setting as a universal privacy guarantee.
Page content is missing or the capture is mostly blank	JavaScript or asynchronous data may have been blocked, so the site could not render dynamic content.	Remove block_js, block_xhr, and block_fetch unless they are essential to the goal. Prefer ad/tracker controls or a targeted rule.
Live information is stale or absent	block_event_source=true prevents EventSource/SSE updates.	Disable it if the capture must include live updates.
One request rule has no visible effect	The pattern may not match the actual request, or the content may be embedded or loaded another way.	Identify the actual URL/path and adjust the pattern using the current documented syntax. Change one rule at a time.
Request is rejected or a setting appears ignored	Endpoint version, parameter spelling, authentication, or value encoding may not match the active API contract.	Compare the request with the current Playground example and resource-blocking documentation. URL-encode the target URL and any pattern characters as required by your HTTP client.

6. Performance, reliability, and cost considerations

Request blocking changes what resources are available to the page during rendering. Blocking ads or trackers can reduce third-party requests, but the reviewed documentation gives no latency benchmark or guarantee about capture speed. Do not assume a specific speedup.

Reliability depends on how the target site is built and which resources it needs. Known-domain controls are convenient for broad filtering, while a specific request rule is more targeted but requires maintenance if the site changes its endpoints. Keep a baseline capture and recheck important pages when their layout or dependencies change.

The supplied ScreenshotAPI.net sources describe parameters and vendor-published product material, but do not provide plan pricing or per-capture cost details. Check current plan terms directly before estimating costs. The homepage advertises 75+ API parameters and 20,000+ ad-blocking rules; these are vendor claims with no year stated on the reviewed page, not independently audited measurements. ScreenshotAPI.net homepage.

Or skip the browser setup

If your goal is a clean screenshot rather than configuring and maintaining request rules, ScreenshotNeo is a website screenshot API and MCP server. It accepts a URL in one GET request and can return PNG, JPEG, WebP, or PDF. Its capture flow accepts cookie and consent banners like a visitor and removes 60+ known consent platforms, newsletter popups, and chat widgets; each step can be turned off. Bot checks/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: take_screenshot, get_page_info, and capture_pdf.

One-call example, saving the returned image bytes as shot.webp:

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 documentation for request options. Python:

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.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://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await import('node:fs/promises').then(fs => fs.writeFile('shot.webp', Buffer.from(await res.arrayBuffer())));

Cookie banners, popups, and chat widgets are removed before the shot; bot checks, blank pages, and failed loads are never billed; an MCP server lets AI agents take screenshots; and 1,000 screenshots a month are free with no card, with paid plans starting at $5 for 3,000. Create a free ScreenshotNeo account.

FAQ

Are ad blocking and tracking blocking the same setting?

No. block_ads filters common ad network requests, while block_tracking targets known tracking and analytics domains.

Does block_tracking=true remove every tracker?

The documentation describes known-domain filtering and does not promise detection of every tracking method.

Should I use block_js=true to remove ads?

Usually that is broader than needed. It can prevent dynamic page content and interactive features from loading; start with the ad-specific control.

Can I remove a consent banner without blocking ads?

Yes. Use no_cookie_banners=true; it is a separate setting.

Where can I check the current request shape?

Use the official Playground and resource-blocking documentation to confirm the endpoint, authentication, and parameter syntax for your API version.