A conventional web link names a place. A content address names the data itself, and that difference determines what happens when the underlying file changes.
Location addressing assumes a custodian
A standard address specifies a server and a path on it. Whoever controls that server decides what is returned when the address is requested.
The content can be replaced, redirected or removed at any time while the address stays identical. Nothing in the link commits anyone to serving the same thing tomorrow.
This works because the web assumes a responsible operator. It fails whenever the operator disappears, changes its mind or is compelled to act.
A hash is a fingerprint of the data
Running a file through a cryptographic hash function produces a short value that changes completely if any byte of the input changes. The function cannot be run backward.
Using that value as the address means the identifier is derived from the content. Two identical files produce the same address regardless of where they are stored.
Anyone who receives a file can verify it by hashing it and comparing the result to the address they requested. Verification requires no trust in the sender.
Retrieval becomes a search rather than a fetch
Because the address contains no location, a client must ask the network who holds the matching data. Peers announce what they store, and a lookup finds them.
Any peer can serve the file, and the requester can verify what arrives. This removes the single point of failure that a location-based address creates.
It also means retrieval depends on someone still storing the data. A content address remains valid forever while pointing at nothing if every copy disappears.
Immutability creates a versioning problem
Changing a file changes its hash and therefore its address. A system built purely on content addressing cannot express the idea of updating something in place.
Mutable naming layers solve this by mapping a stable name to whichever content address is current, with the mapping signed by a key.
The result is two distinct guarantees. The content address proves what the data is; the name proves who chose to point at it.
The consequences reach digital ownership
Collectible metadata stored at a location address can be altered by whoever runs the server, which means the described asset can change after purchase.
Metadata stored at a content address cannot change without the identifier changing, so a token referencing it commits to a specific set of data permanently.
This is why the storage choice in a collection's contract is a substantive property rather than an implementation detail. It decides whether the reference can be rewritten.