How to test an ad against EasyList

All guides - Published September 9, 2026

An EasyList test is most useful as a reproducible preflight check: identify requests that match a known static rule, record the ruleset version, and decide which results need browser confirmation. It should not be presented as a guarantee that every blocker will produce the same result.

Define the test before reading the result

Write down what is being tested: the ad tag, creative URL, landing page, or a resource discovered inside the landing page. Also record the page origin and likely resource type. The same URL can be treated differently when loaded as a script, image, frame, media file, or top-level document.

Adblock.io performs bounded server-side retrieval and static network-rule matching. It does not start an installed blocker, execute the page's JavaScript, apply cosmetic selectors, or reproduce a user's complete browser configuration.

Collect stable, public inputs

• Use the final public HTTPS destination rather than a dashboard preview or authenticated URL.
• Expand shortened links and document every redirect hop.
• Keep the original query string when it affects delivery, but remove secrets and personal data.
• Record whether each discovered request is first-party or third-party relative to the page.
• Do not submit intranet, localhost, private-network, unpublished, or credential-bearing URLs.

For a landing page, a bounded HTML scan can identify explicit resource URLs in markup. Requests created later by JavaScript may be absent, so a clean static result does not mean the executed page makes no additional requests.

Inspect the effective network rule

A useful result names the list, list version, resource URL, resource type, effective action, and matching rule. The effective action matters because an exception can allow a request that also matches a broader blocking pattern.

Review the match in context:

• Is the hostname owned by the advertiser, publisher, platform, or a measurement vendor?
• Does the rule target the whole hostname or only a path or parameter?
• Is the rule restricted to a resource type or third-party context?
• Is the matched request essential to the user journey or only to optional measurement?
• Would removing a duplicate or obsolete tag eliminate the exposure?

Keep cosmetic filtering separate

EasyList also includes page-hiding behavior that depends on selectors and document context. A static network matcher does not tell you whether an element with a particular class or ID will be hidden after rendering. A creative may load successfully and still not be visible.

To test cosmetic behavior, run the page in a controlled browser, preserve the active list versions, and inspect the final DOM and applied styles. Label that outcome as executed-browser evidence rather than merging it into the static result.

Pin the ruleset version

Filter lists change. A report without a version or retrieval time is difficult to reproduce and can become misleading after an update. Adblock.io publishes the source, snapshot identifier, last-modified time, commit reference when available, rule count, artifact hash, and license on thefilter-list data page.

Retest close to launch when the campaign or ruleset changes. Preserve the previous result if a team needs to explain why an outcome changed between two dates.

Interpret pass, warning, and failure narrowly

• Matched block: the tested request matched an effective blocking rule in the pinned snapshot.
• Matched allow: an applicable exception changed the effective action for that context.
• No match: no tested request matched the pinned static network rules; this is not a universal pass.
• Incomplete: the page, rules, response, or resource inventory could not be inspected fully.

Do not convert these outcomes into claims about reach, conversion rate, revenue, platform approval, or every user's experience. Static compatibility evidence answers a narrower technical question.

Know when a browser test is required

Escalate to executed-browser testing when the result depends on:

• JavaScript-created requests, service workers, consent state, or authenticated sessions;
• cosmetic filters, final layout, viewability, interaction, or visual evidence;
• specific extensions, browsers, privacy modes, DNS filters, devices, or regions;
• a disagreement between static evidence and a reported user outcome.