Hosts, domains, and AdGuard rules are not interchangeable.

Why the format matters

DNS filtering lists describe hostnames, but the syntax around a hostname carries meaning: whether it is an exact host, a domain plus subdomains, an exception, a regex, or a mapping to an IP address. The software also matters. Pi-hole, AdGuard Home, and an operating system hosts file do not all interpret the same line the same way.

A DNS blocklist format converter that only strips punctuation can produce a file that loads successfully and blocks less than the original — or more. That is why CleanWeb generates each target format from normalized hostnames and labels the output, rather than pretending every format is a cosmetic variation of another.

Hosts format

A hosts file maps names to addresses. A blocklist commonly uses the unspecified IPv4 address:

# Comment
0.0.0.0 example.org
0.0.0.0 tracker.example.org

• Matching: an entry applies to that exact hostname. It is not a wildcard for subdomains.
• Scope: a hosts file affects the machine where it is installed. It is not a network-wide DNS subscription by itself.
• Comments: lines beginning with # are conventionally comments. Inline comment behavior depends on the consumer.
• Risk: mapping a hostname to an arbitrary IP is not necessarily blocking. It might redirect traffic to a local service. inspect non-blocking mappings before treating a hosts file as a blocklist.

Read the hosts file installation guide if you plan to use this format on a device.

Domain-only lists

Some DNS tools accept one hostname per line without an IP address or AdGuard markers:

# Domain-only list
example.org
tracker.example.org

Pi-hole's gravity parser accepts plain domain lines as well as hosts-format lines. The exact matching semantics depend on the feature you use. Pi-hole exact domain entries do not automatically block subdomains; Pi-hole's wildcard/regex features are separate.

A domain-only file is often the least ambiguous interchange format for exact hostnames, but comments, duplicate handling, and subdomain behavior still vary by consumer. Use a validator before installation.

AdGuard and ABP-style DNS rules

AdGuard Home uses a DNS-oriented subset of Adblock-style syntax. The base blocking rule is:

||example.org^
@@||allowed.example.org^

• ||example.org^ targets the domain and its subdomains according to AdGuard's filtering engine.
• @@||example.org^ is an exception (allow) rule. Rule precedence matters.
• Lines beginning with ! or # are comments in AdGuard DNS rule syntax.
• Modifiers such as $important, wildcard patterns, regex rules, and cosmetic selectors are additional AdGuard/ABP syntax. They are not all DNS-level rules and cannot be copied into a hosts file.

Pi-hole v6 also accepts ABP-style ||domain^ entries, while older Pi-hole releases did not. This is one reason a file saying “Pi-hole compatible” needs a version and a test, not just a label.

DNS blocklist format conversion: what a safe conversion preserves

CleanWeb's generator starts from normalized hostnames from licensed source categories, then emits the selected target syntax. It does not claim that arbitrary uploaded lists can be converted without losing semantics.

Conversions that silently change meaning

• Stripping || and ^ from an AdGuard rule and calling it an “exact domain” conversion. It loses AdGuard's subdomain behavior.
• Converting an exception rule into a block. @@||example.org^ is not a block rule.
• Copying modifiers into a different format. A modifier such as $important has no hosts-file equivalent.
• Treating cosmetic rules as DNS rules. Element hiding and script injection syntax is not a hostname blocklist.
• Taking every hosts line as blocking. A hostname mapped to a real service IP is not necessarily an entry you want to convert into 0.0.0.0.
• Combining different formats in one file. A permissive parser may accept mixed lines, but another tool may ignore them or interpret them differently.

Verify the file, not the label

1. Validate the source with the DNS blocklist validator. Check line numbers for invalid hostnames, duplicates, unsupported constructs, and conflicts.
2. Compare the converted list against the original with the rule diff. Review removed and added rules as a set; a large semantic change is a warning sign.
3. Load the file in the actual target software and check the rule count and query log. Passing a syntax check does not prove the software imported every line.
4. Keep the original source URL and license notice with the generated file. Attribution should survive the conversion.

For authoritative syntax details, use AdGuard's DNS filtering syntax reference and the parser documentation for your Pi-hole version.