ph00lt0 blocklist: one subscription list for uBlock Origin, AdGuard and Pi-hole

One list, many tools, one URL

The repository is a comprehensive blocklist for AdGuard Home, AdGuard, Little Snitch, Open Snitch, uBlock Origin, Brave Adblock, pfBlockerNG and Pi-hole, and the homepage is ph00lt0.github.io/blocklist.

The design decision that defines the project is that the list is format-agnostic in its source and format-specific in its output. The top-level repository entries show the same content in every shape a blocker might want: blocklist.txt for uBlock Origin and AdGuard, domains.txt as the raw domain list, hosts-blocklist.txt, pihole-blocklist.txt, unbound-blocklist.txt, rpz-blocklist.txt for response policy zones, little-snitch-blocklist.lsrules for Little Snitch and Open Snitch on macOS, rethinkdns.mobileconfig for RethinkDNS, and wildcard-blocklist.txt for wildcard matching. There is also a blocklist_issue/ directory for user reports, an install.html page with one-click subscription buttons, a stats.json file the README badge reads for the domains blocked count, and a per-issue index.html.

So instead of maintaining a separate list for each tool, you point every tool at the same source and pick the format that tool understands. The README's Quick Start table makes that explicit with a status column per tool: uBlock Origin and Little Snitch are recommended, AdGuard is full support, AdGuard Home and Brave are recommended, Pi-hole, Open Snitch and pfBlockerNG are full support, RethinkDNS is noted as slow updates, and NextDNS is via API.

The README also lists further tools that the list works with, among them Dnsmasq, Adblock Plus, Blokada, DNSCloak, InviZible, Unbound, OPNsense, wBlock, Technitium DNS and Blocky.

What the list actually blocks

The What This Blocklist Blocks section is long and precise, and it is worth reading in full because it shows the scope is wider than advertising.

On the advertising side there are ad networks and servers, third-party ad serving domains, and programmatic bidding infrastructure, which the README describes as DSPs, SSPs, ad exchanges and real-time bidding endpoints. There is retargeting and audience matching for cross-site ad tracking and behavioural profiling networks, and social widgets, meaning like, share and embed buttons that track users regardless of interaction.

On the tracking side there are analytics and tracking services such as Google Analytics, Mixpanel, Segment, TikTok and Facebook Pixels, stats platforms that collect and profile, data brokers that collect and sell personal data, and font and image trackers described as embedded resources used for browser fingerprinting. Tracking parameters, UTM, affiliate and click-tracking, are removed.

Then the categories that make this list different from an ordinary ad filter list. It blocks debugging trackers such as Sentry and LogRocket, on the grounds that they are collecting data in ways that are not always secure. It blocks cookie and consent management, forced consent banners and cookie walls, and with cosmetic filters it hides cookie banner elements and removes buttons that would let you accidentally consent via dark patterns. It blocks newsletter and chatbot popups. It blocks remote administration tools, described as RATs often used in scams. And it blocks AI data harvesting, meaning LLM interfaces and services that train on or sell user inputs.

The scam categories are extensive too: phishing, health and medical scams, tech support scams, investment and crypto scams including Ponzi schemes and fake exchanges, gambling and lottery, romance and impersonation scams, survey and sweepstakes scams, email spam domains, shareware and fake downloads including cracked software, bloatware and trialware, and cryptojacking scripts.

The cleanup step, and why it is the interesting part

The README states that the blocklist is automatically cleaned and kept free of dead or redundant entries, and that domains are continuously discovered through multiple detection systems, including the author's own automated domains analyser as well as several threat sources.

That cleanup claim is what separates a maintained list from a scraped one. A blocklist that accumulates domains without removing the dead ones is a liability, because a domain that no longer exists may be reused by a different service, and blocking it breaks a site you use for an unrelated reason. The same applies to redundancy, since the same domain served through several hostnames adds nothing but size.

The multiple detection systems matter for a different reason. The README names an automated domains analyser of the author's own plus several threat sources, which means the list is a union of an active detection pipeline and curated feeds. That combination is what makes the list usable as a single subscription for users who do not want to manage several feeds themselves.

The stats.json file and the Domains Blocked badge in the README are built from the same pipeline, so the count of blocked domains in the badge is generated from the actual list rather than typed in. The README also carries a File Size badge pointed at blocklist.txt, which is the number worth watching if you are serving the list from a slow link or a small home server.

The combination guidance is to pair this list with Hagezi Multi Pro++ and OISD Big, which the README links from the Recommended Configuration section. That is an honest recommendation rather than a competitive one: the maintainer is telling you that one list alone is not the whole answer.

Installing it in uBlock Origin

The quickest route is the subscribe button, which points at the install page for each tool. For uBlock Origin the manual method is documented step by step:

1. Open the uBO Dashboard 2. Navigate to Filter lists 3. Scroll down to + Custom 4. Check Import... 5. Paste: https://raw.githubusercontent.com/ph00lt0/blocklist/master/blocklist.txt 6. Click Apply changes

So the subscription URL for the browser level is the raw blocklist.txt on the master branch, and the same raw file serves AdGuard.

For the device and network levels the README recommends a three-layer approach. Browser level is uBlock Origin, described as best support, or Brave's native adblock. Device level is Little Snitch on macOS or Open Snitch on Linux. Network level at DNS is AdGuard Home if you self-host it, or Pi-hole on a Raspberry Pi, or NextDNS by import to denylist.

The point of the layering is that the same list applied at DNS and in the browser catches different things, and a domain blocked at DNS level stops the request before the browser sees it at all. The README's manual setup sections exist for each tool, and the install page carries the one-click equivalents.

The AdGuard Home and Pi-hole paths use their own format files, pihole-blocklist.txt and the hosts-blocklist.txt respectively, and RethinkDNS gets a mobileconfig file rather than a subscription URL, which is why its status is noted as slow updates.

The Known Issues section, and why it exists

The README has a Known Issues section with a warning that this blocklist prioritizes privacy over convenience, and that this is intentional. The list may break functionality for Facebook, TikTok, Amazon Alexa, link shorteners and email tracking, and the README points at the Troubleshooting section for whitelisting instructions if you encounter issues.

That section is the most honest part of the documentation, and it is a design position rather than a bug list. Breaking Facebook means the social widgets never load, so you cannot be tracked by the embed buttons; blocking TikTok means the app's endpoints are unreachable; blocking Amazon Alexa means the assistant cannot be reached. Each of those is a service you lose something for, and the maintainer has decided the trade is worth it.

The link shortener and email tracking entries are different in kind. Link shorteners break because the redirect is often how a tracking parameter arrives, so blocking them is a side effect of removing the parameters rather than a target in itself. Email tracking breaks because tracked links in marketing emails carry the same parameters.

The consequence for a user is that this list is not a good fit for a shared or work device where other people depend on those services, and the whitelist instructions are the escape valve. The README's own advice is to use the list across the three filtering levels, and the Troubleshooting section is where you find how to carve exceptions back out.

Where this blocklist is the wrong choice

Three limits are structural. The first is that a domain list cannot do cosmetic filtering. The README lists cosmetic filters as one of the things the list addresses, but the mechanism is a DNS and URL-level block, so the honest scope is the domains and the request paths, not the hiding of a cookie banner element within a page. If your main complaint is a consent overlay on a site you otherwise want, you need a filter list with element-hiding rules, which is a different subscription in uBlock Origin's filter lists page.

The second is the site breakage. A list that breaks Facebook, TikTok and Alexa is not a good default for a shared household, a workplace network or a device other people use. The maintainer says the priority is privacy over convenience and that is a legitimate position, but it does mean the list needs per-site whitelisting before it is fit for a network you do not control.

The third is that a single list is a single point of failure for your blocking, and the README's own advice to combine with Hagezi Multi Pro++ and OISD Big is an admission of that. Those lists cover different things, and running several lists at DNS level is the normal practice. The difference in approach is that ph00lt0's list leans towards the scam, tracker and dark pattern categories, while Hagezi and OISD are larger general coverage lists, and combining them gives both the broad coverage and the specific categories.

There is also a question of trust and provenance worth naming. The domains come from an automated analyser plus threat sources, and there is no independent audit of the false positive rate in the README. On a list of this size, some entries will block something legitimate, and the blocklist_issue/ directory is where you would report it. A user who cares about correctness on a specific device should start with the list and the troubleshooting section rather than assume it is safe to apply to a network with other users on it.

Editorial conclusion

The ph00lt0 blocklist suits someone who wants one curated domain list to serve several blocking layers at once, since the same source is published in the format each tool expects and the cleanup step means you are not carrying dead entries that break sites without blocking ads. It is the wrong tool if you need cosmetic filtering, since a domain list cannot hide a cookie banner, and it is the wrong tool if you cannot accept sites breaking, because the maintainer states plainly that privacy is prioritised over convenience. Verify first which of the listed formats your tool consumes, and note that the newest content is on the master branch with the last push on 2026-10-20 and no GitHub releases.

Frequently asked questions

Official sources

1. Issues
2. License: CC-BY-SA-4.0
3. ph00lt0/blocklist on GitHub
4. Project website
5. README