Persistent uniform resource locator

OCLC PURL system
Company type	Software system
Industry	Internet technology, URL redirection
Founded	1995
Founder	Stuart Weibel, Erik Jul
Headquarters	United States
Products	Persistent Uniform Resource Locator (PURL) resolver software
Website	purl.org

Adapted from the English Wikipedia article Persistent uniform resource locator, available under CC BY-SA 4.0Updated 9 August 2025

A persistent uniform resource locator (PURL) is a type of uniform resource locator (URL) designed to redirect users to the current location of a specified web resource by utilizing HTTP status codes for redirection.

Originally, PURLs were hosted primarily at purl.org or other domains containing the term purl, often running on variants derived from the original OCLC PURL system software. Over time, the notion of PURLs evolved into a broader term describing any redirection service (known as a PURL resolver) that:

employs a "root URL" as its base resolver address (for example, http://myPurlResolver.example);
permits users to generate new names beneath this root URL (such as http://myPurlResolver.example/name22);
links each name to a target redirect URL with the ability to update it;
guarantees the persistence of both the root URL and resolver infrastructure, frequently upheld through contractual agreements.

PURLs provide a solution to the problem of unstable URLs within location-based URI schemes like HTTP by managing URL resolution centrally. From a technical standpoint, resolving a PURL is comparable to SEF URL resolution. This entry concentrates on the OCLC PURL system created by OCLC (Online Computer Library Center).

History

The concept of PURLs was introduced by Stuart Weibel and Erik Jul at OCLC in 1995. The initial implementation utilized a customized pre-release version of Apache HTTP Server prior to its 1.0 launch. In 2007, OCLC engaged Zepheira to upgrade and expand the software, moving the official site to purlz.org—the 'Z' signifying Zepheira—to differentiate it from OCLC’s original PURL resolver.

The versioning history of PURL software is somewhat intricate: OCLC distributed versions 1 and 2 based on Apache starting in 1999 under OCLC Research Public Licenses. Zepheira launched PURLz 1.0 in 2007 under the Apache License 2.0; although PURLz 2.0 entered beta testing in 2010, it never reached final release. The Callimachus Project began integrating PURLs with its 2012 version.

From 1995 until September 2016, OCLC maintained the longest-running PURL HTTP resolver, accessible via purl.oclc.org, purl.org, purl.net, and purl.com. Other notable resolvers include the US Government Printing Office’s purl.fdlp.gov, which has supported the Federal Depository Library Program since 1997.

The PURL approach is also utilized by w3id.org, which may eventually replace older PURL services and technologies.

On September 27, 2016, OCLC partnered with the Internet Archive to transfer responsibility for PURL resolver services and administration to Internet Archive. This collaboration established a sustainable service hosted by Internet Archive that manages persistent URLs and subdomain redirections for purl.org, purl.com, purl.info, and purl.net. The new platform operates on newly developed software independent of previous versions, reinstating management features that had been disabled during OCLC’s tenure. Currently, OCLC redirects DNS queries for purl.oclc.org to purl.org.

Principles of operation

The PURL framework facilitates general URL curation for HTTP URIs across the World Wide Web, enabling external parties to control URL resolution and manage associated metadata.

A Persistent URL (PURL) serves as a web address that redirects clients to another resource location. When the target resource moves, updating the PURL maintains a stable link, preserving hyperlink functionality. Both content providers and users can administer PURLs independently from the original source, ensuring link stability despite changes in resource addresses.

Typically, a basic PURL responds to an HTTP GET request with a 302 status code ("Found") alongside an HTTP "Location" header specifying the updated URL for client retrieval.

Among various types of persistent identifiers for digital resources—such as Digital Object Identifiers (DOIs), Life Sciences Identifiers (LSIDs), and INFO URIs—PURLs stand out by offering active management capabilities that support ongoing preservation and curation of digital content.

However, critics highlight that because PURLs depend on network resolution mechanisms, they are susceptible to issues like Domain Name System failures or host outages. When a PURL fails to resolve, it can be unclear whether this results from network problems or from the absence of the PURL itself.

From a technical perspective, PURLs are valid URLs adhering to standard URL syntax rules. They generally utilize the HTTP scheme, with the host component identifying the PURL server. The domain name acts as a hierarchical path segment allowing different administrators to manage separate domains. Together, the domain and assigned name constitute a unique identifier for each PURL.

Contrast with permalink

Both PURL and permalink function as stable URLs directing users to online resources. Their primary distinction lies in the adaptability of their domain name and intended durability:

A permalink generally maintains a fixed domain and is created to remain valid for several years.
A PURL supports domain modifications and is designed to endure for multiple decades.

Categories

PURLs are often classified according to the HTTP status codes they emit, although not every HTTP code corresponds to a PURL category. Additional classifications such as "chain," "partial," and "clone" describe specific operational roles.

PURL categories
Category	PURL definition	HTTP status meaning
200	Content delivered or assembled dynamically	OK
301	Permanently redirected to a new URL	Moved Permanently
302	Basic redirect to a target URL	Found
Chain	Redirects internally to another PURL on the same host	Found
Partial	Redirect with appended trailing path segments	Found
303	Redirects to an alternate URL for additional information	See Other
307	Temporary redirect to a specified URL	Temporary Redirect
404	Resource temporarily unavailable (not found)	Not Found
410	Resource permanently removed	Gone
Clone	Duplicates attributes from an existing PURL record	N/A

The majority of PURLs use the "simple" (302) type, which redirects users while keeping the PURL itself as the canonical access point, ensuring continued resolution even if the destination changes. Some administrators opt for 301 redirects, indicating to clients that they should update future requests to use the final URL.

The "chain" type facilitates internal redirection between PURLs hosted on the same server, enhancing efficiency and avoiding browser-imposed redirect limits.

An active or "200" PURL produces content dynamically by aggregating metadata or executing computations; this is particularly useful for generating real-time status updates or distributed queries. Examples of implementations include PURLz 2.0 and The Callimachus Project.

Type "303" directs clients toward alternate URLs that provide supplementary resource details without returning the resource itself. This is commonly employed for metadata delivery in Resource Description Framework (RDF) formats, supporting Semantic Web and linked data initiatives in line with W3C recommendations.

Types "307," "404," and "410" manage temporary redirects and indicate resources that are either missing or permanently removed, assisting resource administrators with lifecycle management. The "clone" type simplifies administrative tasks by enabling replication of existing PURL records.

Handling URL fragment redirection

The PURL system supports partial redirection, meaning if an incoming request does not exactly match a registered PURL, it checks whether the initial portion corresponds to one. When a match is found, the unmatched trailing path is appended to the target URL during redirection. For instance, a PURL registered at http://purl.org/some/path/ pointing to http://example.com/another/path/ will redirect requests like http://purl.org/some/path/and/some/more/data to http://example.com/another/path/and/some/more/data. This mechanism allows a single PURL to represent hierarchical web resources as a root node. The current PURL service denotes this behavior using the "partial" type.

While partial redirections involving URL paths conform to HTTP 1.1 standards, handling fragments (the portion following #) during redirection lacks an established protocol. Fragment identifiers specify particular sections within a resource.

Applying partial redirection with fragments raises ambiguity: it is uncertain whether fragments should be preserved and transferred to the target URL or discarded under the assumption that content changes render them invalid. Bos proposed that fragments be retained during HTTP 3xx redirects unless the destination URL already contains a fragment, in which case the original fragment should be omitted. Although this proposal did not become an official IETF standard, it was revisited in a W3C Note providing guidance where no formal standard exists. Nonetheless, many browsers have yet to implement this consistently.

Since version 1.0 of PURLz, the service has supported partial redirections that include fragment identifiers by appending them onto target URLs, aiming for compliance with W3C recommendations and reducing inconsistent behaviors across web clients.

External links