Most people have clicked a link and seen a message saying it has expired. But few people have thought about what that actually means what changed between when the link worked and when it stopped. The mechanics behind expiring links are genuinely interesting, and understanding them matters for anyone who relies on link expiry as a privacy feature rather than just a convenience.

A URL Is Just an Address, Not the Content

The first thing to understand is that a URL a web address is just a set of directions to a location. The content at that location is separate from the address itself. When you share a link, you are sharing directions, not the content. This means that making a link expire involves one of two things: either removing or changing the content at the destination, or making the server stop responding to requests for that address.

Most expiring link systems use the first approach. When you access an expiring link, the server checks a database to see whether the link's expiry time has passed. If it has, the server returns an error message instead of the content. The content might still exist in the database it just cannot be reached through that address anymore. This is the soft approach to link expiry, and it has an important implication: the content is not necessarily gone just because the link stopped working.

True Deletion Versus Blocked Access

For privacy purposes, the distinction between blocking access to content and actually deleting it matters enormously. A system that blocks access but keeps the content has a database full of sensitive messages that could theoretically be accessed by someone with direct database access a system administrator, a hacker who breaches the database, or a law enforcement agency with a valid subpoena.

True deletion means the content is physically removed from storage when the expiry time arrives. In practice, this requires a background process that runs regularly typically every few minutes to every hour scanning the database for records whose expiry time has passed and executing hard deletions on them. On storage systems that allow forensic recovery, truly private systems go further and overwrite the storage sectors with random data, making recovery impossible even with physical access to the storage hardware.

TTL: The Technical Mechanism of Expiry

The standard technical approach to automatic content expiry is called a Time-To-Live, or TTL. When a piece of data is stored, it is stored alongside a TTL value a duration or a specific timestamp indicating when it should be considered expired. Modern cloud storage systems like Cloudflare KV, Redis, and DynamoDB support native TTL, which means the storage system itself handles deletion automatically without requiring a separate cleanup process.

Native TTL is significantly more reliable than application-level cleanup jobs because it does not depend on a scheduled process running correctly. The storage system guarantees deletion at the TTL boundary as a core feature of how it works, not as an optional behavior that requires maintenance. For applications where data expiry is a privacy guarantee rather than just a preference, native TTL in the storage layer is the appropriate architectural choice.

What Expiry Cannot Do

Link expiry has important limits that users should understand. It cannot delete data that was copied before expiry if someone downloaded or screenshot the content while the link was active, expiry does nothing to that copy. It cannot affect data that was captured by intermediate systems, such as caching proxies or archival services that automatically index public URLs. And it cannot guarantee deletion from backup systems unless the backup system is specifically designed to respect TTL values, which many are not.

For genuinely sensitive content, these limits mean that link expiry should be understood as reducing the window of exposure rather than eliminating it entirely. Content that is active for 24 hours and then genuinely hard-deleted has a much smaller attack surface than content stored indefinitely but it is not equivalent to content that was never stored at all. Honest privacy communication requires making this distinction clear to users.