Hashlink

A hashlink inextricably binds a URI to the cryptographic hash of its target resource. This creates a tamper-evident reference: any alteration to the referenced content, even a single bit, will produce a different hash, immediately breaking the link. This mechanism provides a verifiable guarantee that the retrieved content is exactly what the link's creator intended, eliminating trust in the intermediary server or network.

• Uses algorithms like SHA-256 or BLAKE2b
• Detects both malicious tampering and silent data corruption
• Transforms a trust-based reference into a verifiable assertion

Unlike traditional URLs that locate a resource by its network address (location-based), a hashlink identifies a resource by its cryptographic fingerprint (content-based). This enables retrieval from any source—a different server, a local cache, or a peer-to-peer network—because the identifier is a property of the content itself, not its location.

• Decouples identity from location
• Enables multi-source retrieval and resilient access
• Foundational for systems like IPFS and content-addressable archives

The hashlink specification mandates an explicit algorithm identifier prefix (e.g., hl:sha256:) within the URI scheme. This design provides cryptographic agility, allowing systems to identify and use the correct hashing algorithm immediately. As stronger algorithms emerge or older ones are deprecated, the link itself carries the necessary metadata for verification without external configuration.

• Supports multiple hash algorithms: sha256, sha384, sha512, blake2b
• Enables seamless algorithm migration over time
• Prevents algorithm confusion attacks by making the choice explicit

Beyond the core hash, a hashlink can encode optional metadata, most critically a content type hint (e.g., hl:sha256:...?type=application/json). This allows a client to understand the expected format of the target resource before retrieval. It can also specify a transformation path, indicating that the hash applies to a specific canonicalized form of the data, such as an RDF dataset after applying a particular normalization algorithm.

• Communicates expected MIME type via query parameter
• Supports canonicalization instructions for complex data
• Enables robust linking in semantic web and linked data ecosystems

By combining a location-independent identifier with cryptographic verification, hashlinks create persistent references that survive link rot. Even if the original server goes offline, the link remains meaningful: any copy of the content can be verified against the hash. This is critical for long-term archival, legal evidence, scientific reproducibility, and any system where the integrity of a reference must be maintained for decades.

• Provides a self-certifying identifier
• Eliminates dependence on a single point of failure
• Ideal for digital preservation and verifiable credentials

As a formal W3C specification, the hashlink scheme is designed for broad interoperability across systems, programming languages, and platforms. This standardization ensures that a hashlink generated by one application can be resolved and verified by another, independent implementation. It forms a critical interoperability layer for higher-level standards like Verifiable Credentials, Decentralized Identifiers (DIDs) , and C2PA manifests.

• Published as a W3C Note with multi-stakeholder review
• Provides a stable, versioned IANA-registered URI scheme
• Serves as a building block for the verifiable web

Hashlink supports multiple hash algorithms through its metadata field, allowing systems to evolve as cryptographic standards change.

• The hl parameter encodes both the hash value and an algorithm identifier (e.g., zm for SHA-256, zQ for SHA-3).
• Future-proofing: As SHA-256 is deprecated, hashlinks can seamlessly transition to post-quantum algorithms without breaking existing references.
• This agility is critical for long-term data integrity in archival and compliance systems.

Hashlinks are a foundational component in W3C Verifiable Credentials for cryptographically binding a credential to its schema or rendering template.

• A credential's @context field can use a hashlink to reference a specific, immutable version of a vocabulary file.
• Tamper-evident: Any alteration to the referenced context document immediately invalidates the credential's integrity check.
• This ensures that the semantic meaning of a credential remains fixed and auditable over its entire lifecycle.

Hashlink extends the concept of Subresource Integrity (SRI) beyond browser contexts to any URI-referenceable resource.

• Use case: A JSON-LD document can reference an external schema via a hashlink, guaranteeing the schema hasn't been silently modified.
• Process: The client resolves the hashlink, computes the hash of the retrieved bytes, and compares it to the hash encoded in the link.
• A mismatch triggers a cryptographic trust failure, preventing the use of corrupted or maliciously altered dependencies.

Any standard URL can be transformed into a hashlink by appending the ?hl= query parameter with the hash of the resource's content.

• Example: https://example.com/data.csv?hl=zm9YZpCjPLPJ4Epc acts as both a locator and an integrity check.
• Resolution: A hashlink-aware client can verify the downloaded data against the embedded hash.
• This dual function bridges the gap between location-based and content-based addressing, enabling gradual adoption.

Hashlinks are used within DID Documents to reference service endpoints and public keys with cryptographic certainty.

• A DID Document can specify a hashlink for a service endpoint, ensuring the endpoint's configuration is immutable.
• Key rotation: New keys can be announced with hashlinks to their verification methods, preventing substitution attacks.
• This integration creates a chain of cryptographic trust from the identifier to all its associated resources.