Stop Emailing Files to Yourself: A Lighter Way to Move Files Between Devices

Alisha Albert — Fri, 02 Oct 2026 00:49:38 +0000

How often do you email a screenshot to yourself just to get it from your phone to your desktop? Or upload a video to Drive, wait for it to sync, then download it on the other device five feet away?

We all do it. And it's absurd when you think about it — but the alternatives each have their own tax.

The friction of cross-device sharing

Apple's AirDrop is genuinely great, and completely locked to Apple's ecosystem. The moment one device is a Windows PC or an Android phone, you're back to square one.

Messaging apps work everywhere but compress media aggressively. Fine for a meme, terrible for anything you actually care about.

Cloud drives don't compress, but they make you pay in ceremony: upload, wait, manage sharing permissions, copy the link — and then the link lives forever unless you remember to kill it. For a file you needed for thirty seconds, that's a lot of overhead.

A smaller idea: the one-time handoff

Most cross-device transfers aren't storage problems. They're handoff problems. The file needs to get from device A to device B once, and then nobody needs the link again.

That's the idea behind nowiretransfer. You add a file (or paste some text) on one device and get a 6-character code. Type the code — or scan the QR — on the other device, and the file opens. No account, no app install, works in any modern browser.

What makes it different from just another cloud link:

Files go up and come down as-is. No compression, no quality loss.
Shares expire. You pick 1 hour, 24 hours, 3 days, or 7 days, and the files delete themselves when time's up. No "oops, that link from March is still live."
Private by default. Shares are unlisted — only the code opens them — and transfers are encrypted.
250 MB per file, multiple files per share.

Try it out

Next time you're about to email yourself a file, try this instead: open nowiretransfer on your phone, add the file, and open the code on your laptop. It takes about ten seconds, and there's nothing to clean up afterward.

What's actually hard about this

The interesting engineering isn't the transfer — it's the lifecycle. Expiry has to be real (bytes deleted, not just links hidden), codes have to be unguessable but typable, and the whole thing has to work on mobile browsers that love to kill background tabs mid-upload. Worth thinking about if you're building anything with shared state that shouldn't outlive its purpose.

Sometimes the best feature is the one that deletes itself.

Delete-on-read: designing a file share that destroys itself

Alisha Albert — Thu, 01 Oct 2026 20:42:55 +0000

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 delete-on-read is a token, not a file path. The flow:

Upload stores the file and generates a random, unguessable token.
The share URL contains the token — nothing else identifies the file.
On first successful GET, the server streams the bytes, then immediately deletes the stored file (and any database record pointing to it).
Any later request with the same token returns a "gone" state.

The deletion has to happen server-side, right after the response completes. Client-side tricks — like a page that hides the link after viewing — don't count. If the bytes are still on disk, the share isn't really view-once.

A few details that matter more than they look:

Stream, then delete. Don't load the whole file into memory if you can stream it. Delete the source as soon as the stream finishes, in the same request lifecycle.
Make tokens unguessable. UUIDs or 128-bit random values. Sequential IDs are an invitation to enumeration.
Treat "viewed" carefully. If the recipient's browser prefetches or a link-preview bot hits the URL, that can burn the single view. A common fix: serve an interstitial page first ("click to reveal"), and only count the actual download/view click.

Multi-file shares: the ZIP trick

Single files are the easy case. For multiple files, the cleanest approach is to bundle them into a ZIP at share time and treat the ZIP as the single view-once object. The recipient gets one download, one deletion. nowiretransfer uses exactly this approach — you can drop several files in, and they arrive as one self-deleting archive.

Generating the ZIP on upload (rather than on download) keeps the download path simple and predictable: one stream, one delete, done.

Text shares are the same shape

The pattern generalizes nicely to text. Store the snippet server-side, hand out a token URL, render the text once, delete on first render. It's the same state machine as files — the only difference is the content type. Passwords, API keys, and config snippets are the natural use case, and they benefit from the same "no residue" guarantee.

What "deleted" should mean

This is where implementations get honest or don't. True delete-on-read means:

The file bytes are removed from storage (not just unlinked from a database row).
Backups and caches don't quietly keep a copy around past its intended life.
There's no "recently deleted" grace period that extends the exposure window.

If you're evaluating a view-once tool rather than building one, these are the questions worth asking. A tool that keeps files in a trash folder for 30 days isn't view-once — it's a file host with a countdown timer.

Why this is worth building (or using)

Delete-on-read is a small idea with an outsized effect on how people share sensitive things. It removes the whole category of "I forgot that link was still live." The UX is almost nothing — upload, share, done — because the security model is the absence of state, not the presence of more controls.

If you want to see the pattern in action, nowiretransfer is a clean example: free, no signup, files and text that delete themselves after one view, multi-file ZIP packaging. It's a good reference for how little UI this pattern actually needs.

The broader lesson: sometimes the best data retention policy is not having the data at all.

DEV Community: Alisha Albert