Temporary file sharing that actually expires
Self-destructing file share with on-demand revoke · Updated May 2026
Send a file that auto-deletes after seven days. If you change your mind sooner, click the revoke link in the email we send you and it's gone in a second.
- 5 GB per file, no signup, browser only
- 7-day auto-expiry via S3 lifecycle plus DynamoDB TTL
- One-click revoke from the confirmation email
- No Trash, no recover. Expired means gone
Most file-sharing tools default to permanent. Upload to Google Drive, Dropbox, or OneDrive and the file sits there until you remember to delete it, which you almost certainly won't. The few tools that do auto-expire (WeTransfer, SwissTransfer) hard-lock the expiry date and don't let you take a file back early. sto.care does both: every upload self-destructs after seven days, and a one-click email link kills it sooner if you change your mind.
DefinitionWhat temporary file sharing actually means
Temporary file sharing is the model where expiry is built in, not bolted on. The default for cloud storage is the opposite: a Drive or OneDrive upload stays live until you, an admin, or a retention policy goes back and ends it. Temporary sharing removes that step. The file ends on a clock, and you only touch it again if you want it gone sooner.
The distinction matters because human memory is a terrible retention policy. Stale shareable links from years prior are a recurring topic in Google's support forums, and Drive's own stop or change how a file is shared article confirms why: files don't auto-delete, and link access doesn't auto-expire. You have to find each file and revoke it by hand. Temporary sharing skips that step by making expiry the default.
MechanicsHow the 7-day auto-expiry works
When you upload a file, the API records two things: the object in S3 (eu-west-1, server-side encrypted with AES-256) and a row in DynamoDB with the metadata, the recipient email, and a TTL field set to seven days from now. Both have an automatic expiry path.
S3 handles the file itself via an object lifecycle rule. AWS sweeps expired objects out of the bucket on or shortly after their expiry timestamp; once that runs, the object is gone and any pre-signed URL pointing at it 404s. DynamoDB handles the metadata via TTL on the record, which deletes the row within 48 hours of the timestamp elapsing. The result is no orphan records, no stale links, no long-tail archive sitting in a bucket somewhere.
There's no "Trash" or "Recover deleted files" tier. Once it's gone, it's gone. That matters because it's the part most cloud storage gets wrong: Drive keeps deleted files in Trash for 30 days, OneDrive for 30 to 93, and the link can sometimes be re-enabled. With sto.care, expiry is destruction, not a soft-delete.
On-Demand RevokeKilling the link before the timer runs out
Auto-expiry on its own isn't enough. Sometimes you send the wrong file, or send the right file to the wrong person, or just change your mind ten minutes later. The fix is the confirmation email we send the sender when the upload finishes. That email contains a secure revoke link, signed with a token tied to the upload. One click and the file is purged out of S3 immediately, ahead of the lifecycle sweep, and the metadata row is marked revoked.
You don't need an account to do this. You don't need to remember a password. You just need access to the email inbox you put on the upload form. If somebody is mid-download when you click revoke, their connection drops; the next try gets a 404. It's the closest thing to an "undo send" that file sharing offers.
Use CasesWhen temporary is the right default
Temporary sharing fits anywhere the file isn't meant to be a long-term artefact. A few cases where the trade-off is clearly correct:
- One-shot client delivery: a finished video, a signed contract, a render. The recipient downloads it, you both move on.
- Sensitive documents: tax forms, ID scans, medical reports. The shorter the link lives, the smaller the window for something to go wrong.
- Source files for a one-off collaboration: stems for a remix, raw photos for an editor, a PSD for a freelancer.
- Any file you'd rather not still be live in someone else's inbox a year from now.
Where temporary is the wrong default: anything you need indefinitely accessible (a portfolio, a public software release, a wiki). For those, persistent storage is genuinely better.
Lifecycle ControlWhen the file actually disappears
The "temporary" label hides three different behaviours. Some tools never expire and lean on you to remember (Drive, OneDrive). Some hard-lock the timer and ignore you when you change your mind (WeTransfer free, SwissTransfer). Some claim auto-delete and then keep the object in a 30-day Trash where the link can sometimes be re-enabled. The question we'd push you to ask is what happens at the moment the timer hits zero, and whether you get to move that moment forward yourself.
Two patterns sit behind that table. WeTransfer free and SwissTransfer give you a clean purge but no early kill switch: once you upload, you're committed to the timer. Dropbox Transfer trades the other way and gives you a dashboard kill switch, then routes the file through a 30-day soft-delete after expiry rather than a hard purge. We're trying to get both ends right: a one-click revoke from the confirmation email we already send you, and a hard purge the moment the timer or the revoke fires. No Trash, no recover, no second life.
PrivacyWhat we do and don't see
We move files between your browser and S3 over TLS, and S3 writes every object to disk with AES-256 server-side encryption under AWS-managed keys. That's server-side, not end-to-end: AWS holds the keys, so we (and AWS) could technically read a file if compelled to. If that's a concern for what you're sending, an end-to-end-encrypted tool with client-side keys is a better fit. The Electronic Frontier Foundation's Surveillance Self-Defense guide walks through when each tier matters.
We don't scan file contents for advertising, training, or any other use. We don't maintain a long-term archive, because the seven-day sweep removes the substrate to scan against. The only metadata we keep past expiry is the minimum needed for abuse handling (sender IP, file hash for blocked-extension counting), and even that rolls off after the record TTL fires.
Files live in AWS eu-west-1 (Ireland), which puts them inside the EU's regulatory perimeter. That's GDPR, the Digital Services Act, and Irish data-protection law. It also means a US-style subpoena doesn't reach the bucket directly; it has to go through MLAT or the EU-US Data Privacy Framework. The story isn't bulletproof (no provider's is) but it's a meaningful step up from a US-jurisdiction default.
FAQCommon questions
What does temporary file sharing actually mean?
It means the link you send has a real end date built in, not a vague "you can delete it later if you remember". On sto.care every upload self-destructs seven days after it's created. The file leaves the bucket, the download link 404s, and there's nothing left to clean up.
How does the 7-day auto-expiry work under the hood?
Each upload is stamped with an expiry timestamp seven days from creation. An S3 lifecycle rule sweeps the object out of the bucket on or shortly after that timestamp, and the matching DynamoDB record uses TTL to drop at the same time. There's no archive, no soft-delete, no "recover for 30 days" tier.
Can I delete a file before the 7 days are up?
Yes. The confirmation email you get when the upload finishes contains a secure revoke link. Click it once and the file is gone, even if a recipient is mid-download. You don't need an account to revoke, just access to that email.
Is sto.care end-to-end encrypted?
No, and we don't claim it is. Files travel over TLS, and S3 encrypts them at rest with AES-256 server-side keys managed by AWS. End-to-end encryption would require a key only you and the recipient hold, which we'd have to build a separate flow for. If that's the threshold you need, look at something like Tresorit or a self-hosted Cryptpad.
Where are the files actually stored?
AWS S3 in eu-west-1 (Ireland). Traffic to and from the bucket is TLS, the bucket itself is private, and downloads happen through short-lived signed URLs we generate per request. After seven days (or sooner, on revoke) the object is purged by the lifecycle rule.
Are there limits I should know about?
Five gigabytes per file, ten uploads per hour from the same IP, no monthly cap on transfers. Executable types like .exe, .sh, .bat, .ps1 and friends are blocked at the upload step to keep the abuse rate low. Everything else is fair game.
Send a file in seconds. Take it back any time.
UPLOAD A FILE →Looking at specific competitors? Read sto.care vs Google Drive for the persistent-storage trade-off, or sto.care vs WeTransfer for the locked-expiry one. There's also a longer guide to free file sharing without signup if you want the wider landscape.