{
  "id": 11276881,
  "title": "Delete-on-read: designing a file share that destroys itself",
  "url": "https://urgent.news/2026/10/01/delete-on-read-designing-a-file-share-that-destroys-itself",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-10-01T20:42:55.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/alisha_albert_fa8993b210a/delete-on-read-designing-a-file-share-that-destroys-itself-3j2i"
  },
  "original_language": "en",
  "account": "Delete-on-read is a design approach for file sharing systems that automatically removes the file after it has been viewed once. This is different from traditional file sharing systems, which focus on persistence and keep files available until they are manually deleted. Delete-on-read is particularly useful for one-time handoffs of sensitive files, as it eliminates the risk of the file being accessed multiple times.\n\nThe core mechanism of delete-on-read is the use of single-use tokens. When a file is uploaded, the server generates a unique, unguessable token and includes it in the share URL. On the first successful GET request, the server streams the file bytes to the client and then immediately deletes the file from storage. Any subsequent requests using the same token will result in a \"gone\" state, indicating that the file has been deleted.\n\nImplementing delete-on-read requires careful consideration of a few details. The file should be streamed and then deleted as soon as the stream finishes, in the same request lifecycle. Unguessable tokens, such as UUIDs or 128-bit random values, should be used to prevent enumeration. Additionally, the \"viewed\" event should be treated carefully to prevent accidental consumption of the single view, such as by serving an interstitial page before the actual download or view.\n\nFor multiple files, the cleanest approach is to bundle them into a ZIP archive at share time and treat the ZIP as the single view-once object. The recipient receives one download and one deletion. Generating the ZIP on upload, rather than on download, keeps the download path simple and predictable.\n\nThe pattern of delete-on-read can also be applied to text files, such as passwords, API keys, and configuration snippets. In this case, the text is stored server-side, a token URL is generated, the text is rendered once, and then deleted on the first render. The same state machine applies as with files, with the only difference being the content type.\n\nThe concept of deletion in delete-on-read implementations can vary. True delete-on-read means that the file bytes are removed from storage permanently, without any backups or caches retaining a copy. Tools that keep files in a trash folder for a limited time should not be considered delete-on-read, as they extend the exposure window beyond the intended life of the file.\n\nDelete-on-read is a simple yet powerful idea that significantly reduces the risk associated with sharing sensitive information. By removing the state of the file after it has been viewed once, users can avoid the common issue of forgetting that a link is still live. Nowiretransfer is a practical example of this pattern, offering free, no-signup access to files and text that automatically delete themselves after one view. The minimal UI required for this pattern makes it an efficient and effective solution for securing sensitive file sharing.",
  "summary": "Most file-sharing systems are built around persistence. Upload, store, serve — and keep serving until someone remembers to delete. But there's a whole class of sharing where persistence is the bug, not the feature: one-time handoffs of sensitive files. The pattern is simple: a link that works exactly once. Here's how to think about building it. The core mechanic: single-use tokens At the heart of…",
  "key_points": [],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}