Public Suffix Lookup

Runs in browser New DNS & Domains

Paste host names or URLs and the tool applies the Public Suffix List algorithm to each: every matching rule is found, an exception rule or the longest rule wins, and you get the public suffix (co.uk, github.io), the registrable domain (eTLD+1) and the subdomain, with the rule and the list section (ICANN or PRIVATE) that decided. Internationalised names are shown in Unicode and punycode. The list is bundled with the page (Public Suffix List, Mozilla Foundation, MPL 2.0) and nothing you type leaves your browser.

Privacy: This tool runs entirely in your browser. Your input never leaves your device.

What is the Public Suffix List?

The Public Suffix List, a Mozilla initiative maintained as a community resource, names every suffix under which people can register names: top-level domains (com), registry second levels (co.uk, com.sa) and, in a PRIVATE section, platforms that give out subdomains (github.io). The registrable domain (eTLD+1) is the public suffix plus one label; browsers use it to refuse cookies set for a whole suffix and to decide which hosts belong to the same site.

Security note: Code that takes the last two labels as the registrable domain gets co.uk and github.io wrong, which can let one tenant's cookies or permissions reach another tenant's hosts.

How to use Public Suffix Lookup

  1. Paste host names or URLs, one per line; URLs are reduced to their host.
  2. Leave "ICANN section only" off for the browser view, or tick it to see registrable names the way a registry does.
  3. Read the table: the public suffix is what nobody can register under, the registrable domain is the site a cookie or a registration belongs to.
  4. Check the notes for wildcard, exception, private and unlisted suffixes, and the details panel for every rule that matched the first host.

Public Suffix Lookup features

  • Public suffix, registrable domain (eTLD+1) and subdomain for up to 50 host names or URLs at once
  • The rule that decided, its type (listed, wildcard, exception or the implicit "*") and its section, ICANN or PRIVATE
  • An "ICANN section only" switch for the registry view, where private suffixes such as github.io count as ordinary names
  • Internationalised names in Unicode and punycode, side by side
  • Every matching rule listed for the first host, so you can see why the longest or the exception rule won
  • Runs entirely in your browser on a bundled copy of the Public Suffix List (Mozilla Foundation, MPL 2.0), whose version is shown
  • Results as you type, and a CSV download of the table

Inputs and outputs

Inputs

  • Host names or URLs: one per line (commas and semicolons also separate them), up to 50. A URL is reduced to its host; a port, a path and user information are ignored.
  • ICANN section only: off by default (both sections, as browsers use the list); on for the registry view.

Outputs

  • Results: per input the public suffix, the registrable domain, the subdomain, the prevailing rule and its section.
  • First host in detail: Unicode and ASCII forms, the labels, the top-level domain, the prevailing rule and its type, every rule that matched and, for internationalised names, the punycode forms.
  • Notes: private, wildcard, exception and unlisted suffixes, names that are themselves public suffixes, and input problems.
  • Public Suffix List data: the version of the bundled list, its rule counts, its source and its licence.

Public Suffix Lookup example

A country-code second level, a private suffix and an exception rule

Input:

www.example.co.uk
shop.example.github.io
www.city.kobe.jp

Output:

Results:
www.example.co.uk | co.uk | example.co.uk | www | co.uk | ICANN
shop.example.github.io | github.io | example.github.io | shop | github.io | PRIVATE
www.city.kobe.jp | kobe.jp | city.kobe.jp | www | !city.kobe.jp | ICANN
Notes: shop.example.github.io: the rule comes from the PRIVATE section: the suffix belongs to a company that gives out subdomains to its customers, not to a registry. · www.city.kobe.jp: an exception rule makes this name registrable although a wildcard covers its neighbours: !city.kobe.jp
Public Suffix List data: List version 2026-10-07_07-28-19_UTC · Rules 6949 ICANN + 3387 PRIVATE

How to read the Public Suffix Lookup results

Public suffix: the level under which people register names (com, co.uk, github.io). No cookie can be set for it, and a name that is itself a public suffix shows "—" as registrable domain.

Registrable domain (eTLD+1): the name a registry sells or a platform hands out, and the "site" browsers group hosts by. www.example.co.uk and shop.example.co.uk share example.co.uk.

Section PRIVATE: a company runs the suffix and gives subdomains to customers; browsers keep those customers apart. Section "Not in the list": the top-level domain is missing from the list, so only its last label is treated as the suffix.

With "ICANN section only" a private suffix is ignored: shop.example.github.io then has the registrable domain github.io, the name GitHub registered.

When to use Public Suffix Lookup

  • Checking which cookie Domain values a host may set, or why a browser rejected one.
  • Grouping URLs from logs or analytics by site (eTLD+1) instead of by full host name.
  • Validating the registrable-domain logic of your own code against the reference list.
  • Understanding why a multi-tenant platform's subdomains are treated as separate sites.

Troubleshooting

  • "Not a valid host name": the line has spaces, two dots in a row, a label longer than 63 characters or characters a host name cannot have. The note under the table names the problem.
  • A suffix you expected is missing: the bundled copy may predate its addition to the list. Compare the list version shown with publicsuffix.org.
  • An IP address is listed as having no public suffix: the list covers domain names only.
  • A host on a private platform (github.io, blogspot.com) shows the platform as the suffix: that is intended; tick "ICANN section only" for the registry view.

Frequently asked questions about Public Suffix Lookup

What is the difference between the ICANN and PRIVATE sections?

The ICANN section lists the top-level domains and the names registries sell under (co.uk, com.sa). The PRIVATE section lists domains whose owners give subdomains to unrelated customers, such as github.io or blogspot.com, so that browsers treat each customer's subdomain as a separate site. Tick "ICANN section only" for the registry view, where example.github.io belongs to github.io.

Why does the list matter for cookies?

Browsers refuse a cookie whose Domain attribute is a public suffix, so no site can set a cookie for all of co.uk or github.io. The registrable domain is also what makes two hosts the same "site" for SameSite cookies and several other browser boundaries.

Which version of the list does the tool use?

A copy bundled with the page, generated from publicsuffix.org; its version and rule counts are shown under "Public Suffix List data". A suffix added to the list after that copy was made is missing until the bundled copy is refreshed.

What do wildcard and exception rules mean?

A wildcard rule such as *.kobe.jp makes every name directly under kobe.jp a public suffix of its own. An exception rule such as !city.kobe.jp takes one name back out, so city.kobe.jp is registrable. The tool names the rule that decided and lists every rule that matched.

Is anything I type sent to a server?

No. The list and the algorithm run in your browser, and the tool makes no network request at all.

Technical notes

The algorithm is the one publicsuffix.org documents: every rule whose labels match the right-hand labels of the name is a candidate (a "*" label matches any one label); an exception rule (!) wins over all others and removes its left-most label; otherwise the rule with the most labels wins; with no match, the implicit rule "*" makes the top-level domain the public suffix. The registrable domain is the public suffix plus one more label.

Names are lower-cased, normalised to NFC and converted to punycode (IDNA, RFC 5891) before matching, because the list is stored in ASCII form; results are shown back in the form you typed. Browsers use the same list to scope cookies (RFC 6265 rejects a Domain attribute that is a public suffix) and to define "site" for SameSite cookies.

Limitations and methodology

The answer is only as current as the bundled list; additions made at publicsuffix.org since the version shown are not known to the tool.

The list says where registrations happen, not who owns a name or whether it exists: use WHOIS / RDAP Lookup or DNS Lookup for that.

At most 50 lines per run; further lines are ignored with a warning.

Security and privacy

Everything runs in your browser on a list bundled with the page; nothing you type is sent to Mutqan or to anyone else.

References

  • Public Suffix ListMozilla FoundationWhat a public suffix is (com, co.uk, pvt.k12.ma.us), why browsers use the list to stop "supercookies", and that the list is a Mozilla initiative maintained as a community resource.
  • View the Public Suffix ListMozilla FoundationThe list itself and its format: the ICANN and PRIVATE sections, wildcard (*) and exception (!) rules, and the algorithm that picks the prevailing rule.
  • RFC 6265: HTTP State Management MechanismIETF · 2011How cookies are set and sent: the Set-Cookie attributes (Expires, Max-Age, Domain, Path, Secure, HttpOnly) and their scope rules.