---
title: "Why Ad Blockers Hide Elements Named "ad""
canonical_url: https://ot.webclat.com/qa/ad-blocker-hiding-elements-named-ad
description: "Cosmetic filter lists hide elements by matching class/id substrings, not by understanding what the element does - here's why an unrelated element gets caught, and how to audit for it."
source: Webclat | OneTrust Solutions (OneTrust partner, independent consultancy)
---

# Why does an ad blocker hide a legitimate page element just because its class/id contains "ad" or a tracking-like pattern?

**Short answer:** Ad blockers apply cosmetic (element-hiding) filter rules that match on CSS selectors, and popular lists like EasyList include broad selectors targeting any class or id containing substrings such as "ad", "ads", or "banner-ad" - so a completely unrelated element (an "address" field styled with class `ad-field`, for example) can get hidden purely by string coincidence, with no analysis of what the element actually renders or does.

## Why this happens

Cosmetic filtering and network-request blocking are separate mechanisms (see the ad-blocker-detection page for the full distinction). Cosmetic rules work entirely on the DOM: a stylesheet injected by the extension applies `display:none !important` to anything matching a selector in the subscribed filter list. Those selectors are written and maintained by volunteers across thousands of sites, so many of them are broad, substring-style class/id matches rather than site-specific rules - they're optimized to catch ad units across the whole web, not to avoid false positives on any one site's naming conventions.

Because the match is purely textual, there's no way for the filter list to know your `ad-field` class means "address field" rather than "advertisement". The extension can't inspect intent - it only sees a selector match.

## Fix it

1. **Audit your codebase for risky class/id substrings** - Search for class and id names containing ad, ads, adv, sponsor, or banner-ad as substrings on elements that have nothing to do with advertising, since these are the most common substrings targeted by generic cosmetic filters.

   ```
grep -rniE 'class="[^"]*\bad(s|v)?\b|id="[^"]*\bad(s|v)?\b'  src/
   ```

2. **Rename the offending classes/ids** - Where you control the markup, rename to something unambiguous - `ad-field` becomes `mailing-address-field`, for example. This is the only fix that reliably works across every blocker and every list, since it removes the pattern match entirely.

3. **For third-party widgets you don't control, wrap rather than rename** - If a vendor's embed script hardcodes a risky class name, wrap it in a container with your own unambiguous class and move any layout-critical styling you need onto the wrapper instead of depending on the vendor's original class surviving unhidden.

4. **Confirm the specific rule that's firing before assuming a fix worked** - Inspect the element in DevTools while the blocker is active and check its computed style for an injected `display: none !important` rule - the rule's source (visible in most browsers' style inspector) usually names the extension, confirming which mechanism is actually responsible before you spend time chasing the wrong fix.

5. **Accept that genuinely ad-related UI will keep getting hidden** - If the element legitimately is an ad slot or a tracking-adjacent widget, this cosmetic hiding is the expected, intended behavior of the tool the visitor installed - it isn't a bug to work around, and attempting to defeat it for actual ad content is a different decision with its own considerations (see the related page on detecting and responding to partial blocks).

## How to verify it worked

- With the ad blocker enabled, load the page and visually confirm the previously-hidden element now renders after the rename or wrap.
- In DevTools > Elements, check the computed style panel for the element - a passing result shows no extension-injected `display:none` rule; a still-broken result shows the same injected rule still applied.
- Test against more than one blocker/list combination if possible (different browsers or extensions subscribe to different lists) before concluding the fix is complete everywhere.

## Related

- [What's a reliable, current method to detect that a visitor is running an ad blocker?](https://ot.webclat.com/qa/detect-ad-blocker-reliably)
- [How do I gracefully handle (or measure the impact of) ERR_BLOCKED_BY_CLIENT on my tracking requests?](https://ot.webclat.com/qa/err-blocked-by-client-tracking-requests)
- [Why do Snowplow tracker requests get silently blocked in the browser, and how do I detect it?](https://ot.webclat.com/qa/snowplow-requests-blocked-by-browser)

Contact: ot@webclat.com | (813) 694-4451 | https://ot.webclat.com/#contact