Pi-hole Optimized Blocklists ships pre-merged lists you point Pi-hole at

What the repository produces

The repository is described as providing pre-optimized, deduplicated blocklists for Pi-hole, and the README calls them pre-built and pre-optimized. The description in the project metadata spells out the composition: pre-built, deduplicated Pi-hole blocklists merged from curated upstream sources and community reports, giving a master list plus advertising, tracking, malware and phishing, suspicious, and NSFW categories, rebuilt weekly. The word deduplicated is the load-bearing part of that. When you merge a dozen upstream feeds yourself, the same domain appears in several of them, and Pi-hole's gravity ends up carrying every duplicate, which costs memory and inflates the domain count in the admin interface. Doing the merge once, offline, means the list a user subscribes to contains each domain once. The badge in the header advertises more than 2.6 million domains in total, and the per-category counts are given in the tables.

The eight lists and their sizes

The available lists table gives a domain count for each output, and the sizes differ by three orders of magnitude, which tells you how the categories differ.\n\n```text\nall_domains.txt Everything combined (except NSFW) 2,662,931\nadvertising.txt Ad networks & services 264,454\ntracking.txt Analytics & telemetry 18,087\nmalicious.txt Malware, phishing, scams 2,224,616\nsuspicious.txt Potentially unwanted 50,287\ncomprehensive.txt Curated multi-category 495,065\nnsfw.txt Adult content (separate) 530,044\nnsfw_abp.txt Adult content, ABP format 497,991\n```\n\nThe malicious category dominates at over 2.2 million domains, which is the aggregate of the threat intelligence, fake and DynDNS feeds plus the ad and tracking feeds, and it explains why all_domains.txt is close to the size of the malicious list on its own. The comprehensive list at 495,065 is the balanced option, since it merges the HaGeZi Pro, OISD Big and 1Hosts Lite sources. The tracking list is small by comparison at 18,087 because it holds only the native tracker feeds rather than every analytics endpoint on the web.

The NSFW list and the ABP variant, and the version requirement they carry

The newest addition is nsfw_abp.txt, a subdomain-blocking NSFW list. It is an ABP-format version of nsfw.txt that blocks adult domains and all their subdomains, for example cdn.example.com as well as example.com, for more complete filtering. It requires Pi-hole Core 5.16 or later and FTL 5.22 or later. Two details are easy to get wrong. The first is that nsfw.txt is deliberately excluded from all_domains.txt because it blocks legitimate adult sites, so if you want NSFW filtering you add it as a separate list. The second is that the ABP variant has fewer lines, 497,991 against 530,044, because it leaves out subdomains that one of its own rules already blocks. The guidance is to use it instead of nsfw.txt, not alongside it, for more thorough filtering. The same ABP requirement applies to any list that includes ABP-style entries, since those need Core 5.16 and FTL 5.22, released in 2023 and standard on current installs. A note worth keeping is that pihole -q will not enumerate the individual subdomains covered by an ABP entry.

Adding them to Pi-hole

The quick start is three steps. In the Pi-hole admin interface you open Lists on Pi-hole v6 or Group Management and then Adlists on Pi-hole v5, you add the URL of each list you want from the table, and you run pihole -g, or use Tools and then Update Gravity, to load them. The URLs point at the media.githubusercontent media path for the repository's lists directory rather than at raw GitHub, which is what GitHub uses for files in the repository. Since the lists are plain text served over HTTP, there is no build step, no container to run and no local state to keep in sync. The repository layout is small and reflects that. There is a lists directory with the outputs, a custom directory holding the community-submitted files, a blocklists.conf file that defines the sources and how they map to categories, a whitelist.txt file, and the workflow files under .github that do the weekly rebuild. The README states the last update date directly, which was October 18, 2026.

Where the domains come from, and the licences that come with them

The sources are configured in blocklists.conf, and each list keeps its own licence, which is the detail that matters most for anyone thinking about redistribution. HaGeZi DNS Blocklists supplies the Pro list to the comprehensive category, the threat intelligence, Fake and DynDNS lists to the malicious category, the Pop-Up Ads list to advertising, and the native trackers list covering Amazon, Apple, Huawei, LG webOS, OPPO and Realme, Roku, Samsung, TikTok, Vivo, Windows and Office and Xiaomi to tracking. OISD supplies Big to comprehensive and NSFW to the nsfw category. 1Hosts Lite feeds comprehensive. AdAway hosts feeds advertising, Peter Lowe's ad server list feeds advertising under its own licence with no commercial use, anudeepND feeds advertising under MIT, and the AdGuard DNS filter feeds advertising under GPL-3.0. The HaGeZi and OISD entries are GPL-3.0, 1Hosts is MPL-2.0 and AdAway is CC BY 3.0. The repository itself is MIT, but the upstream terms apply to the merged output, which is worth checking against your own use before you redistribute the lists as part of a product.

Community reports and the weekly rebuild

The reporting workflow is issue-driven and the decisions are made by a person. The README offers three issue templates: one to request that a malicious, ad, tracking, suspicious or adult domain be blocked, one to report a false positive where a legitimate domain is being incorrectly blocked, and one for a bug in the lists or the automation. A bot posts an evidence report on each block and false-positive issue, and the maintainer makes every decision. An accepted change takes effect at the next weekly update. The FAQ explains the mechanics: domains reported via issues are added to custom/<category>.txt files in the repository, and these are referenced as sources in blocklists.conf via raw GitHub URLs, so the optimizer picks them up on the next weekly run just like any other upstream source. The cadence is every Sunday, by a GitHub Actions build scheduled for 00:00 UTC, with the honest caveat that GitHub often starts scheduled builds a few hours late, so a report merged on Sunday evening may not appear until the following week.

Where these lists are the wrong choice

Three limits. The first is that this is a static, pre-built product and the README says so directly, in contrast with the sibling project. Zach's Lists, at lists.zachlagden.uk, offers custom source selection so you pick which blocklists to include, smart whitelisting with regex, wildcards and subdomain patterns, multiple output formats in hosts, plain and Adblock syntax, and real-time build progress. Both use the same underlying sources and are maintained by the same person, so the difference is entirely about control and features. If you need to add your own corporate blocklist or exclude a domain that keeps breaking, the static file is the wrong shape. The second is the false-positive risk of the master list. The README's own guidance is that comprehensive.txt is a good balance for most users while all_domains.txt gives maximum blocking and may cause false positives. The domain counts explain why, since a list that blocks over 2.6 million domains will eventually block something you need. The third is the version floor and the update lag. ABP entries need Core 5.16 and FTL 5.22, an ABP entry hides every covered subdomain from pihole -q output so debugging becomes guesswork, and a weekly rebuild means a compromised domain can sit unblocked for days. A blocklist that reduces your DNS traffic is worth having, but it is a filter, not a security boundary.

Editorial conclusion

Adopt these lists if you run Pi-hole and want one maintained URL per category instead of curating upstream feeds yourself. Skip them if you need per-source control or automatic whitelisting, since the README points at Zach's Lists for that. Before you pick a category, read the FAQ guidance on which list to use and check the Pi-hole Core version, because the ABP-format entries require Core 5.16 or later and FTL 5.22 or later.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. zachlagden/Pi-hole-Optimized-Blocklists on GitHub