Upload a file, get a link to share

You have a 400 MB video, a 1.2 GB design file, or a folder of tax returns you zipped up at 2 GB. You want a URL you can paste into Slack or iMessage so the other person can grab it. That's the whole job. sto.care does it in three clicks, free, with no account on either end. Below is exactly what happens when you upload, what the link looks like, and what the recipient sees.

The FlowHow upload-and-share works on sto.care

The full path from drag-and-drop to copy-link is three steps, and each one writes a different thing to the backend. That separation is the reason the link can't be guessed and the file can't leak in transit.

Step 1: pick the file. Drag it onto the upload zone on the homepage or click to open a file picker. The browser reads the file name, size, and MIME type locally and sends those metadata bits (not the file itself) to our API. We check the size against the 5 GB ceiling, reject blocked extensions like .exe and .bat, and check the rate limiter (10 uploads per IP per hour). If anything fails, you get the error before any bytes move.

Step 2: the presigned upload. Our API returns an AWS S3 presigned URL, which is a short-lived signed URL that authorizes the browser to PUT a single object directly into our eu-west-1 bucket. The file goes browser to S3 over TLS. Our Lambda never sees the bytes. For files over a few hundred MB the browser uses multipart upload, so a flaky connection only retries the affected chunk instead of the whole file.

Step 3: confirm and write the metadata. Once the upload finishes, the browser pings our confirm endpoint with the upload ID and the recipient email. We write a single DynamoDB record with the file ID, size, recipient, an expiry timestamp seven days out, and a revoke token. SES then sends two emails: the recipient gets the download link, and you get a confirmation that includes a one-click revoke link.

The LinkWhat the link looks like

The download URL has the form https://sto.care/f/<id>, where the ID is a random 8-character base32 slug. Roughly a trillion combinations, generated server-side, never derived from the file name or the sender. There's nothing identifying in the URL. No email address, no filename, no upload timestamp. If someone screenshots the link in a meeting, the URL gives away nothing about who sent what to whom.

The trade-off, and we'd rather say it than gloss over it: possession of the link is the authentication. Anyone who has the URL can download until it expires or is revoked. That's the same model as a Dropbox public link or a WeTransfer download URL. The Mozilla developer docs have a good primer on transport security for why the URL itself shouldn't be your only line of defense. Send links over channels you already trust, and revoke them the moment they're not needed.

The Recipient ViewWhat the person on the other end sees

The recipient clicks the link and lands on a single page. File name. File size. A download button. That's it. No banner ads, no "upgrade to Pro" modal, no email-gate before the download. Compare that to the current WeTransfer free download experience, which routes through a full-page sponsored background and an interstitial before the file starts. SendGB and Filemail are similar. We don't take ad money and we don't upsell, so the page is just the file.

The download itself is a redirect to a fresh presigned S3 URL valid for a few minutes. The browser pulls the bytes directly from S3 in eu-west-1. We increment a download counter on the metadata record so you can see whether the file's been picked up, but we don't log the IP or the user agent past what S3 logs by default for billing.

Expiry & RevokeHow the link dies

Two ways. The first is the seven-day timer. DynamoDB has a TTL attribute on every record, set to seven days from upload, and the table automatically purges expired items. A scheduled Lambda follows the TTL events and deletes the corresponding S3 object. After that, the link returns a 404. Nothing lingers in cold storage; nothing gets archived for "legal hold".

The second is the revoke link in your confirmation email. Click it and the metadata record is marked revoked, the S3 object is deleted, and the URL goes 404 within seconds. This is the part competitors don't do cleanly without a paid account: a free WeTransfer transfer sent without signing up runs its full retention period with no per-link revoke surface. If you sent the wrong file or the wrong recipient anonymously, you wait it out. With sto.care it's one click from the confirmation email, no account needed.

What Can Go WrongThe failure modes

The link is a public-ish URL. If the recipient forwards it, the next person can download. If they paste it into a Slack channel with 200 people, all 200 can download. The unguessable ID stops someone scraping for active links, but it doesn't stop a recipient from sharing. This is the same trade-off every link-share tool ships with. The OWASP cheat sheet has a useful note on tokens in URLs if you want the formal version.

The mitigation is the revoke. The moment you're not sure the link is going to the right place, kill it. We don't support password protection right now, and we'd rather not pretend we do. If you genuinely need a password gate, we point readers at SwissTransfer for that one feature, even though they fall short on revoke.

ComparedOther upload-and-link tools, briefly

• Google Drive link: account-walled. The sender always needs a Google account, and the file lives in your 15 GB shared quota until you delete it manually.
• Dropbox link: Dropbox account required for the sender. Free tier caps file size at 2 GB and the file stays in your 2 GB total storage forever.
• WeTransfer: no sender account on the free tier, but transfers expire after three days, and anonymous free transfers can't be revoked early.
• sto.care: no account either side, 5 GB per upload, seven-day auto-expiry, one-click revoke from the confirmation email.

FAQCommon questions

Want the lifecycle deep-dive instead? Read temporary file sharing. Or compare the alternatives: sto.care vs WeTransfer and sto.care vs Google Drive.