An eTLD+1 is the shortest part of a domain name that an independent party could have registered for itself: an effective top-level domain, plus the single label immediately to its left. In www.example.com the effective top-level domain is com and the eTLD+1 is example.com. In project.github.io it is github.io, because GitHub lets anyone claim a name beneath it, so the eTLD+1 is project.github.io. Browsers call the result a site. Advertising systems call it a domain, a root domain or a property, and use it as the unit against which inventory is authorised, counted and blocked.

The term exists because the line between one organisation's web space and another's cannot be read off the shape of a hostname. Counting dots fails: co.uk looks structurally identical to example.com but is a registry, not a website. Nothing in the Domain Name System marks where registration control passes to the public. That information lives in a list.

How the boundary is calculated

The list is the Public Suffix List, maintained by the Mozilla Foundation as a community resource and published as a plain text file at publicsuffix.org. A public suffix is a name under which anyone can register; entries are also called effective top-level domains, or eTLDs. Its specification states the arithmetic in one line: the registrable domain is the public suffix plus one additional label.

Matching is more involved than a lookup. An asterisk wildcards an entire label and only in the leftmost position, so .foo is valid and bar..foo is not. Where several rules match, the one with the most labels wins. An exclamation mark marks an exception overriding a preceding wildcard, which is how pref.hokkaido.jp can register cookies at the third level while the rest of hokkaido.jp cannot.

Two sections divide the file. The ICANN block covers suffixes delegated through the IANA root zone; the private block holds entries submitted by domain holders themselves. As of September 12, 2026 it carried 10,325 rules, 6,951 in the ICANN section and 3,376 in the private one. The private entries matter most in advertising, because that is where hosting and publishing platforms declare that their subdomains belong to unrelated parties: blogspot.com, github.io, myshopify.com, netlify.app, pages.dev and vercel.app all appear there.

Browsers add the scheme. Google's Privacy Sandbox glossary defines a site as an eTLD+1 together with a protocol, and Chrome's documentation calls websites sharing both same-site and everything else cross-site. Subdomains do not count in that test, nor do ports, which is why login.example.com and www.example.com are one site while example.com and example.co.uk are two. Cookie scope follows the same boundary: RFC 6265 treats the public suffix check as what stops a hostile site setting a cookie with a Domain attribute of com.

Where the boundary sits in an ad transaction

The clearest use in advertising is authorisation. The IAB Tech Lab ads.txt specification defines the root domain on which publishers must post the file as the public suffix plus one string in the name, and tells crawlers to use the Public Suffix List to derive it. Google Ad Manager's documentation repeats that as one level down from the list. The ads.txt file therefore sits on the main domain, and a crawler reaching a page on a subdomain strips back to the eTLD+1 before fetching. Later versions let a root domain point crawlers at a named subdomain, exempt from truncation. The mobile extension follows the same rule, with publishers publishing app-ads.txt in the root directory of the developer site named in their store listing.

In the bid request the boundary is weaker than the file convention suggests. OpenRTB describes site.domain as the domain of the site, used for advertiser side blocking, with foo.com as the example, and publisher.domain as the highest level domain of the publisher. Neither mandates eTLD+1 form, so sellers populate the fields inconsistently. The SupplyChain object identifies each intermediary by domain, and matching those entries against sellers.json is a string comparison that works only when both sides truncate the same way.

Buy-side controls inherit the unit. Blocklists enumerate websites, publishers and apps where advertising must not appear, and inclusion lists do the reverse, both keyed to domains rather than pages. Some controls now reach below the domain: DV360's seller ID blocklists, open to all advertisers since April 2025 at an added 1.5% of media cost, filter by selling entity rather than property.

Privacy plumbing uses the same identifier. The IAB Tech Lab's Accountability Platform requires privacy signal senders and receivers to log each counterparty as an eTLD+1 domain. Chrome's partitioned cookie standard keys storage to the top-level site, not the embedded origin, and the tooling Google shipped for the end of third-party cookies files its guidance under site boundaries.

Origin and evolution

The concept began as a cookie security fix. Early browsers limited cookie scope with a dot-counting heuristic that broke on registries where registration happens at the third level. Mozilla replaced the heuristics with an explicit file during 2005 and 2006, and the first public version appeared in 2007, the year the copyright notice begins. RFC 6265 recommended the approach in 2011.

Advertising adopted it a decade later. Ads.txt arrived in 2017 and leaned on the list from the start, with the March 2021 revision adding inventorypartnerdomain for shared inventory. In April 2022 the Tech Lab opened ads.txt 1.1 for comment, adding ownerdomain and managerdomain so that a group owning several titles could be matched to sellers.json entries without a domain mismatch. Shailley Singh, senior vice president of product at the Tech Lab, said the declarations help advertisers "better identify and control who their spend is going to".

Governance moved in parallel. ICANN's Security and Stability Advisory Committee produced the SAC070 advisory on how such lists should be used, IANA began hosting an authoritative suffix list for root zone entries on December 1, 2019, and the ICANN board closed the advisory on May 12, 2021. Browsers hardened the definition in 2020, when Schemeful Same-Site folded the protocol into the site. A proposal filed against the WHATWG URL standard that June, to expose the eTLD+1 directly to pages so that web applications need not embed the list themselves, has not shipped.

Why the unit matters commercially

Commercial disputes in programmatic trading are settled at this granularity. Domain spoofing works by misrepresenting it: the Financial Times found its display inventory offered on ten exchanges and its video on fifteen, at an estimated loss of around one million pounds a month, because a declared domain is asserted rather than proven. Arbitrage exploits the same asymmetry without the deception. Fraudulent mobile operations work the other side, registering brand-shaped subdomains beneath unremarkable hosting suffixes.

Authorisation files stop only part of that. An IAB Europe study of 2,054 European news publishers found ads.txt on at least 72.64% of them, yet a fabricated publication can host a perfectly valid file of its own. Such a file proves which sellers may transact a domain, not whether the entity behind it is real.

Limitations and disputes

The maintainers publish their own catalogue of design problems. The list is static, so consumers holding an outdated copy misclassify newer suffixes until their software updates. It carries no version field. Wildcard and exception handling varies between implementations, with some entries ignored outright. And a single entry is blunt: a registrant wanting cookies isolated beneath a subdomain cannot say so without also affecting certificate issuance decisions taken from the same file.

Ownership is the deeper gap. An eTLD+1 marks a registration boundary, not a corporate one. One company routinely holds dozens, the problem ownerdomain was written to patch, and one eTLD+1 can host thousands of unrelated tenants. Attempts to bridge the first case in the browser have failed. Chrome's Related Website Sets would have let an organisation declare domains it operated and share cookies across them. Research by Brave with the University of St Andrews, Imperial College London and Hong Kong University of Science and Technology, presented at the 2024 Internet Measurement Conference, found users could not reliably tell when two sites were related. Mozilla and Apple declined to implement it, and Chrome retired it in October 2025.

Subdomains cut the other way. Server-side tagging moved measurement onto publisher-controlled hostnames, on the assumption that sharing an eTLD+1 with editorial content would deter blocking, and in May 2026 the EasyPrivacy and AdGuard lists began naming those subdomains explicitly. Blockers work at hostname granularity when it suits them.

Not the same as

An origin is scheme, host and port together, so www.example.com and login.example.com are different origins inside one eTLD+1. Origin governs script access; eTLD+1 governs cookies and storage.

A top-level domain is the final label alone. Effective TLDs include multi-label suffixes such as co.jp and privately declared ones such as github.io, which no root zone list contains.

Registrable domain, root domain and eTLD+1 name the same thing. Ads.txt uses the second, browsers the third.

Recent developments

Retirement of Related Website Sets left the boundary without a sanctioned exception, and partitioned cookies as the route for state confined to one publisher's domain. Fingerprinting defences use the same scope: Brave's version 1.93 release on August 13, 2026 randomises the reported WebGL extension list per session, per site at the eTLD+1 level and per storage area, so hashed values cannot be correlated between sites.

Authorisation is being rethought around richer objects than a text file keyed to a root domain. Brian O'Kelley published adagents.json on March 30, 2026 as a proposed successor to ads.txt, promising placement-level, geography-aware and date-bounded checks rather than a flat list of seller identifiers. Whichever format prevails, it will still be fetched from a root domain derived through the Public Suffix List.

Timeline

  • 1994: Netscape's cookie mechanism introduces domain matching, using dot-counting heuristics to limit cookie scope
  • 2000: ICANN delegates additional generic top-level domains, exposing the heuristics as inadequate
  • 2005 to 2006: Mozilla replaces its cookie heuristics with an explicit list of effective top-level domains
  • 2007: The first public version of the Public Suffix List appears; the list carries a copyright notice from this year
  • April 2011: RFC 6265 documents the public suffix check as protection against cookies set at registry level
  • 2014 to 2015: ICANN's Security and Stability Advisory Committee reviews use of public suffix lists, producing advisory SAC070
  • 2017: The IAB Tech Lab publishes ads.txt, defining the root domain as the public suffix plus one label
  • December 1, 2019: IANA begins hosting an authoritative suffix list covering root zone entries
  • May 18, 2020: ICANN's Office of the Chief Technology Officer publishes a guide to the list for registry administrators
  • June 24, 2020: A WHATWG URL proposal asks browsers to expose the eTLD+1 to pages directly
  • November 2020: Chrome documents Schemeful Same-Site, adding the URL scheme to the definition of a site
  • March 2021: The ads.txt specification adds inventorypartnerdomain for shared inventory relationships
  • May 12, 2021: The ICANN board closes the SAC070 advisory
  • February 8, 2022: Maintenance documentation for the list moves to GitHub
  • April 13, 2022: The Tech Lab opens ads.txt 1.1 for public comment, adding ownerdomain and managerdomain
  • October 2024: Research on Related Website Sets is presented at the Internet Measurement Conference
  • October 2025: Chrome retires Related Website Sets along with most Privacy Sandbox technologies
  • March 30, 2026: adagents.json is published as a proposed successor to ads.txt
  • August 13, 2026: Brave ships fingerprinting randomisation scoped per site at the eTLD+1 level
  • September 12, 2026: The list carries 10,325 rules, 6,951 in the ICANN section and 3,376 in the private section

Summary

Who. The Mozilla Foundation maintains the Public Suffix List as a community resource, with registry operators and domain holders submitting entries to its two sections. Browser vendors consume it to define a site. The IAB Tech Lab writes it into ads.txt and its successors, and exchanges, demand-side platforms and verification vendors apply the resulting unit in authorisation checks, blocklists and reporting.

What. An eTLD+1 is a public suffix plus one additional label: the shortest registrable piece of a domain name, and the boundary at which cookies, storage, authorisation files and inventory records are scoped.

When. The concept dates to cookie scoping work in the mid-2000s, with the list first published in 2007 and referenced by RFC 6265 in 2011. Advertising adopted it through ads.txt from 2017, and browsers folded the URL scheme into the definition in 2020.

Where. In the browser it governs cookie scope, storage partitions and same-site tests. In the supply chain it determines where authorisation files are fetched, how seller domains are matched, and what a blocklist entry covers.

Why. It is the unit of accountability in programmatic trading, which makes it the unit that fraud targets and that transparency standards keep trying to reinforce. It also marks registration control rather than ownership, so a single company holding many domains or a single domain hosting many tenants both fall outside what the boundary can express.