--- title: "What is an ad blocker? | daily.dev Ads glossary" url: https://business.daily.dev/glossary/ad-blocker/ description: "An ad blocker is browser software that stops ads and trackers from loading. Developers install them more than any other audience, so display advertising does not reach them, and the formats that do are part of the content." lastUpdated: "2026-10-20" llmsTxt: https://business.daily.dev/llms.txt --- ## What is an ad blocker? An ad blocker is browser software that stops ads and trackers from loading. Developers install them more than any other audience, so display advertising does not reach them, and the formats that do are part of the content. Also called: Ad blocking, Banner blindness. 67% of developers run an ad blocker (MarketingTech News, developer ad-blocking survey), and 64% of those say they block ads because they are intrusive (business.daily.dev/resources — why developers block most ads). The blockers work from shared filter lists that match ad networks, tracker domains and common ad markup, so a banner from a network is gone before the page finishes loading. Banner blindness is the human version: the developers who do not block ads have learned not to look at anything shaped like one. Between the two, the reachable share of a developer audience through display is a fraction of the audience a network reports. What survives is content. A promoted post inside a feed, served by the platform itself in the same card as every other post, is not on a filter list and is not shaped like a banner. A sponsored slot inside a newsletter arrives in the inbox like the rest of the issue. The lesson for developer marketing is not to fight the blockers but to stop making things they block. ## How many developers block ads, and why? 67% of developers run an ad blocker (MarketingTech News, developer ad-blocking survey), far above the general population, and 64% of those say they block ads because they are intrusive (business.daily.dev/resources — why developers block most ads). The reasons they give are consistent: ads slow pages, track them across sites, and interrupt reading. Developers are also the audience most able to install, configure and keep a blocker, and the one most likely to use a browser that blocks trackers by default. The practical consequence for a display campaign: the audience a network reports is several times the audience that can see the ad, and the developers who cannot see it are the senior ones you wanted most. ## How do ad blockers work, and what gets through? Blockers subscribe to shared filter lists (EasyList and its relatives) that match ad-serving domains, tracker domains and common ad markup: class names, container sizes, script URLs. A banner served by an ad network from its own domain into a standard slot matches on several counts and is removed before the page finishes loading. Anything that pattern-matches to an ad, including an honest promotion with an ad-like class name, can be caught. What gets through is content served by the site itself: a post in a feed, in the same markup as every other post, from the same domain; a slot in a newsletter, which arrives by email where blockers do not run; sponsored articles; a logo in a bar that is part of the page design. The reader can still ignore it, which is why it has to be worth reading. ## What should a developer marketer do about ad blockers? - **Stop making things they block.** Buy placements that are part of the content, served by the platform. - **Check your own site.** An element with a class like "hero-ad" or "promo-banner" can be hidden for most of your visitors by a filter list; test with a blocker on. - **Measure server-side.** Client-side pixels and analytics are blocked too; send events from the backend. - **Do not fight it.** Anti-adblock walls and "please whitelist us" prompts cost more trust than they recover with this audience. The audience is telling you how it wants to be reached. The formats that work are the ones that respect that. ## What does this mean for reporting? Ask every platform how it counts an impression, and whether blocked impressions are excluded. On a display network the served count includes ads that were removed before render; on a platform that serves promoted posts in its own feed, a served post is a post that rendered. Compare channels on reads and conversions, not on served impressions, and expect your own client-side analytics to undercount developer visits for the same reason. **Common mistakes** - Buying display for a developer audience and believing the impression count. - An ad-like class name on your own hero, hidden by a filter list. - Client-side-only analytics on a site developers visit. - An anti-adblock wall on a developer product's marketing site. **How developers experience it** - They installed the blocker years ago and forgot banners exist. - They read a promoted post in a feed because it is in the reading path and labelled. - They leave a site that asks them to whitelist it. ## On daily.dev [In-Feed Ads](https://business.daily.dev/feed.md) on daily.dev are promoted posts served by the platform in the same card as every post and labelled Promoted. They are read as part of the feed, which is why developers see them when they see nothing else. ## What ad blockers remove and what they leave | | Blocked? | Why | | --- | --- | --- | | **Display banners from ad networks** | Yes | Ad-serving domains and banner markup are on the filter lists | | **Promoted posts served by the platform in its own feed** | Rarely | Same domain and markup as every other post | | **Newsletter slots** | No | Email is outside the browser | | **Client-side pixels and analytics** | Usually | Tracker domains are on the same lists | | **Your own elements named like ads** | Sometimes | Class names such as "hero-ad" match generic rules | ## Go deeper - [Reaching the audience that never sees display](https://business.daily.dev/resources/ad-blockers-developers-reaching-audience-never-sees-display.md) - [Native ads for developers: do they work?](https://business.daily.dev/resources/native-ads-developers-do-they-work.md) Related terms: [Native advertising](https://business.daily.dev/glossary/native-advertising.md) | [In-feed ads](https://business.daily.dev/glossary/in-feed-ads.md) | [Viewability](https://business.daily.dev/glossary/viewability.md) ### Frequently asked questions **What share of developers use an ad blocker?** 67%, according to MarketingTech News, developer ad-blocking survey, and most of them say it is because ads intrude. The figure is far above the general population, which is why display does not reach developers. **Can native ads be blocked?** Rarely. Blockers work from shared filter lists of ad-serving domains and banner-shaped markup; a post a platform serves from its own feed, in the same markup as every other post, matches neither. The reader can still ignore it, so it has to earn the read. **How do you reach developers who block ads?** Through what they chose to read: feeds and newsletters they subscribe to, documentation, communities and open source, with placements that are part of that content rather than around it. **Can an ad blocker hide parts of my own website?** Yes. Filter lists match class names and markup patterns, so an element named like an ad on your own site can be hidden for most developer visitors. Test your pages with a blocker on and rename anything that disappears. **Do ad blockers affect analytics and conversion pixels?** Yes. Client-side analytics and pixels are on the same lists. Send conversion events from your server so the campaign is measured even when the browser blocks scripts. [All terms](https://business.daily.dev/glossary.md) | [Explore your options](https://business.daily.dev/schedule/?ref=glossary-ad-blocker) | [How pricing works](https://business.daily.dev/pricing.md)