The Public Suffix List is a cross-vendor initiative to provide an accurate list of domain name suffixes, maintained by the hard work of Mozilla volunteers and by submissions from registries, to whom we are very grateful.
The usefulness of this can be seen if we take the example of cookies. In the past, browsers used an algorithm which only denied setting wide-ranging cookies for top-level domains with no dots (e.g. com or org). However, this did not work for top-level domains where only third-level registrations are allowed (e.g. co.uk). In these cases, websites could set a cookie for .co.uk which would be passed onto every website registered under co.uk.
Since there was and remains no algorithmic method of finding the highest level at which a domain may be registered for a particular top-level domain (the policies differ with each registry), the only method is to create a list. This is the aim of the Public Suffix List.
Software using the Public Suffix List will be able to determine where cookies may and may not be set, protecting the user from being tracked across sites.
As well as this, the Public Suffix List can also be used to support features such as site grouping in browsers. By knowing where the user-controlled section of the domain name begins and ends, browsers can group cookies and history entries by site in a way that couldn't easily be done before.
Some use the PSL to determine what is a valid domain name and what isn't. This is dangerous. gTLDs and ccTLDs are constantly updating, coming and going - and certainly not static. If the PSL is incorporated in a static manner, and your software does not regularly receive PSL updates, it will erroneously think that valid TLDs are not valid, or conversely treat decommissioned TLDs that should be invalid as valid. The DNS should be the proper source for this information, despite the performance benefits of some local source to pre-empt network latency. If you must use the PSL for this purpose, please do not bake static copies of the PSL into your software without update mechanisms that are frequently checking for its frequent updates and incorporating them.
These are some of the uses of the list we know about. If you are using it for something else, you are encouraged to tell us, because it helps us to assess the potential impact of changes. For that, you can use the psl-discuss mailing list, where we consider issues related to the maintenance, format and semantics of the list. Note: please *do not* use this mailing list to request additions to the PSL's data.
In the future it may be used for, for example, restricting DOM Storage allowances on a per-domain basis.
Qt uses it to restrict cookie setting from version 4.7.2 onwards.
Crawler-Commons is a suite of tools for building a web crawler, and it uses the PSL.
C, Perl and PHP: regdom-libs includes libraries for working with the Public Suffix List.
C: libpsl, a fast offline PSL lookup library in C
C: Faup, a command line tool with a C library and Python bindings
Elixir: publicsuffix-elixir
Erlang: publicsuffix_erlang
Go: tldextract
Go: publicsuffix-go
Haskell: publicsuffix-haskell
Java: regdom-libs has a Java port too
Java: Guava - Google's core Java libraries - has a PSL-using class
Java: Java API for the Public Suffix List
JavaScript: publicsuffixlist.js
JavaScript: tld.js
TypeScript: tldts
Lua: lua-psl
.NET: Louw.PublicSuffix.
Objective-C: KKDomain
Perl: Domain::PublicSuffix
PHP: php-domain-parser
Python: publicsuffix2
Python: publicsuffixlist
Python: tldextract
Raku: PublicSuffix - a static automatically updated interface
Ruby: publicsuffix-ruby gem
Rust: publicsuffix - a super-fast dynamic implementation that can be updated at runtime
Rust: psl - an even faster static implementation, compiled down to native Rust code
Rust: addr - a public suffix list based domain name and email address parser
Rust: psl-types - common types for the public suffix implementation crates
Swift: Dashlane/SwiftDomainParser
There's also a list of libraries in various languages in the comments on this Stack Overflow question.