Public Suffix List

View the Public Suffix List

The list is kept in source code control on Github. You can read more information on the format the list uses below. Please note that the list is encoded using UTF-8.

The copy on, linked below, is updated daily from Github. If you wish to make your app download an updated list periodically, please use this URL and have your app download the list no more than once per day. (The list usually changes a few times per week; more frequent downloading is pointless and hammers our servers.)

To be kept informed of changes to the list, you can subscribe to an Atom change feed in your favourite feed reader.

List format

A public suffix is a set of DNS names or wildcards concatenated with dots. It represents the part of a domain name which is not under the control of the individual registrant.



Here is an example (incomplete) list section. The rules are numbered, but the numbers would not appear in the real file:

            1. com
            2. *.jp
            // Hosts in can't set cookies below level 4...
            3. *
            4. *
            // ...except hosts in, which can set cookies at level 3.
            5. !
            6. !

The example above would be interpreted as follows, in the case of cookie-setting, and using "foo" and "bar" as generic hostnames:

  1. Cookies may be set for
  2. Cookies may be set for
    Cookies may not be set for
  3. Cookies may be set for
    Cookies may not be set for
  4. Cookies may be set for
    Cookies may not be set for
  5. Cookies may be set for because the exception overrides the previous rule.
  6. Cookies may be set for, because the exception overrides the previous rule.

Formal algorithm

Here is an algorithm for determining the Public Suffix of a domain. (Note: it may not be the most efficient algorithm.) The domain, as well as all rules from the Public Suffix List, must be canonicalized in the normal way for hostnames - lower-case, Punycode (RFC 3492) - prior to being compared.



  1. Match domain against all rules and take note of the matching ones.
  2. If no rules match, the prevailing rule is "*".
  3. If more than one rule matches, the prevailing rule is the one which is an exception rule.
  4. If there is no matching exception rule, the prevailing rule is the one with the most labels.
  5. If the prevailing rule is a exception rule, modify it by removing the leftmost label.
  6. The public suffix is the set of labels from the domain which match the labels of the prevailing rule, using the matching algorithm above.
  7. The registered or registrable domain is the public suffix plus one additional label.


The Public Suffix List is subdivided, using markers in the comments, into two sections, labelled as ICANN domains and PRIVATE domains.

ICANN domains are those delegated by ICANN or part of the IANA root zone database. The authorized registry may express further policies on how they operate the TLD, such as subdivisions within it. Updates to this section can be submitted by anyone, but if they are not an authorized representative of the registry then they will need to back up their claims of error with documentation from the registry's website.

PRIVATE domains are amendments submitted by the domain holder, as an expression of how they operate their domain security policy. Updates to this section are only accepted from authorized representatives of the domain registrant. This is so we can be certain they know what they are getting into.

While some applications, such as browsers when considering cookie-setting, treat all entries the same, other applications may wish to treat ICANN domains and PRIVATE domains differently. For example, Certification Authorities checking for wildcard misissuance would not issue a "*.com" wildcard cert ("com" is in the ICANN domains list) but could legitimately issue a "*" wildcard cert to the domain owner, in this case Google ("" is in the PRIVATE domains list).

Test Data

There is a short set of test data available. You will need to define a checkPublicSuffix() function which takes as parameter a domain name and the registrable part of the domain, runs your implementation on the domain name and checks the result is the registrable domain expected. Thanks to Rob Stradling of Comodo for providing this test data.