Share a file with a secure, expiring download link

Last updated: 2026-08-05

Not every transfer has someone waiting on the other end. Maybe the recipient is asleep, on a flight, or you just want to drop a link in a message and move on with your day. For that, Relayium has a second mode: instead of streaming a file live to another open browser, it encrypts the file where you are, uploads only the ciphertext, and hands you a link you can send whenever — the download happens on the recipient's own schedule.

This guide walks through creating one of these links, the expiry and burn-after-read options, and exactly what the zero-knowledge design means in practice — including the honest limits: creating a link needs the sender to sign in, and links count against a storage quota.

Stored links vs. realtime: when to use which

Relayium's realtime mode streams a file live between two open browser tabs: WebRTC is direct on the same LAN, while cross-network browser sessions use TURN by design to carry end-to-end encrypted ciphertext that the relay cannot read or decrypt. Relayium keeps no server-side copy or realtime history, but both people need to be online together. A stored, expiring link flips that trade-off: your browser does the encryption and uploads the result once, and the recipient can open the link minutes, hours, or days later, on their own time.

Use a stored link when you don't know exactly when the other person will be free, when you're sending the same file to more than one person, or when you just want something you can paste into an email or chat and be done with it.

How to create a link

What you need

A signed-in account on the sending side only — the recipient never needs one, and never sees a sign-in prompt.
Files that fit under two separate ceilings: the per-file limit printed next to the picker, and your plan's storage quota. Read both off the page instead of guessing.
A retention window your plan allows. The list only offers the windows your plan supports, and the server enforces the same cap defensively on whatever it receives.
Your own copy of anything important. The page says so under the options: this is temporary delivery, not a backup.

Creating a link takes a few steps, all in the browser:

Open the async transfer page and sign in. Only the sender needs an account; the recipient never will.
```
https://relayium.com/offline-transfer
```
Choose one or more files, or drag them in. The figure next to the picker is the live per-file ceiling for your account.
```
Choose files to upload
Max 512 MiB
```
Set “Expires in”, or turn on “Burn after reading (delete on first download)”. The reminder under them — temporary delivery, not a backup — is the page telling you to keep your own copy.
```
Expires in
1 day
```
Wait while the browser encrypts and then uploads; both phases are shown as they run. Leave the page open until it finishes, after which the link no longer depends on it.
Copy the link, or have the recipient scan the QR beside it, and send it however you like. The whole string matters: everything after #k= is the decryption key and never reaches the server.
```
Link ready — send it to the recipient to download:
https://relayium.com/d/8f3c2a1b#k=hQ2r…
```

What a created link looks like

The page replaces the picker with the link, the date it expires on, and a Copy button — plus a QR of the same link and, under it, the builder for fetching it from a terminal.

Opening the link yourself is the honest way to confirm it: the download page shows the encrypted-link title, the file count with the total size, and a countdown of the time left. What it does not show is any way for us to read the file, because the key stayed in the fragment you copied.

Link ready — send it to the recipient to download:
https://relayium.com/d/8f3c2a1b#k=hQ2r…

Expiry and burn-after-read

Every link needs a lifetime — leaving one live forever isn't the point of a one-off transfer. When you create a link you pick how long it should stay valid, or you can set it to disappear as soon as it's been used once.

Burn-after-read means one download and then nothing — useful when the file is sensitive and you want exactly one person, one time, with nothing left dangling afterward. Be precise about when that single slot is spent, though: it goes the moment real ciphertext starts moving, not when the download finishes. A download interrupted half way has already used it up, and the link is dead even though the recipient holds only part of the file. Only an attempt that delivered nothing at all — zero bytes — hands the slot back, so a connect-then-drop costs nothing. The asymmetry is deliberate: refunding a near-complete read is exactly how a link holder would pull a burn file over and over. Either way, the recipient sees a live countdown on the download page, so they know how much time (or how many downloads) is left — and if their connection is shaky, leave burn off and pick a short expiry instead.

1 hour
1 day (the default)
3 days
7 days
14 days (the maximum, on the top plan)
Or: burn on the first download that delivers any bytes, instead of a fixed time

The zero-knowledge guarantee, and its limits

Here's what actually happens when you create a link. Your browser generates a random AES-256-GCM key — a different mechanism from Relayium's realtime mode, which negotiates a key between two devices with X25519; a stored link's key is generated locally, with nothing to negotiate. That key encrypts your files and the list of filenames before anything leaves your device, and it's appended to the download link after a # — a part of the URL that browsers never send to any server. The server stores the ciphertext it's given, and only the ciphertext; it has no way to decrypt it, because it never receives the key.

That design has real trade-offs worth knowing. The key never reaches the server, so there is no password reset we could offer you. It is not quite the link's only copy, though: the browser you uploaded from keeps it locally as well, and “My files” on the account page can rebuild and copy the link in that same browser. What makes a file unrecoverable is losing both — the full link and that local copy, which is what opening the account page on a different device, or clearing this browser's site data, amounts to. After that the stored ciphertext is permanently unreadable, to you and to us. Creating a link requires the sender to be signed in, and every link counts against your account's storage quota until it's deleted or expires. And it's worth being precise about what "zero-knowledge" means here: the ciphertext is genuinely stored on Relayium's server between creation and download — it's just unreadable without the key that never left your browser.

Symptom, check, fix

The recipient opens the link and the page says the decryption key is missing.

https://relayium.com/d/8f3c2a1b#k=hQ2r…   # the key is everything after #k=

The fragment was lost on the way — a chat preview, a link shortener, or a copy that stopped at the #. Send the link again as plain text, and have them paste it into the address bar themselves so nothing rewrites it; the id alone, with no #k= behind it, cannot be decrypted by anyone, us included.

Decryption fails even though the whole link arrived.

https://relayium.com/d/8f3c2a1b#k=hQ2r…   # one id belongs to exactly one key

The id and the key came from different links, which happens when two uploads are copied in the same sitting. Copy the newest link in one piece from the page that created it, or open “My files” on the account page in that same browser and copy the link from the right entry — the #k= fragment and that browser's local copy are the only two places the key exists, because it never reached the server.

The link says it is invalid, expired, or already downloaded and deleted.

https://relayium.com/offline-transfer   # create a fresh link with burn left off

All three are the same state: nothing left to fetch. With “Burn after reading” on, the first download that actually delivers ciphertext spends the only slot — whether it finished or broke off half way — so upload again and leave that off when more than one person, or one retry, needs it.

The download page reports too many requests, or that the sender's monthly transfer is used up.

https://relayium.com/me   # this month's usage covers transfer as well as storage

The file is intact and this is metering. A rate limit clears in a few minutes; an exhausted monthly transfer allowance waits for the month, an upgrade, or your own node. Opening the link again afterwards works, because nothing was consumed.

You need the file back and no longer have the link.

https://relayium.com/me   # “My files” rebuilds the link in the browser that uploaded it

Try the one recovery path there is first: the browser you uploaded from kept the key locally, so open the account page in that same browser, find the entry under “My files” and use its copy-link button. On any other device, or after that browser's site data was cleared, the key is gone and the stored ciphertext is unreadable to everyone, us included — upload again from your own copy, which is why the page tells you to keep one.

Frequently asked questions

Does the person I send the link to need an account?

No. Anyone with the full link — including the part after the # — can open it and download the files. Only the sender needs to sign in to create the link in the first place.

Can Relayium read my file?

No. Your browser encrypts the files with a random AES-256-GCM key before anything is uploaded, and that key travels only in the URL fragment, which never reaches the server. The browser you uploaded from also keeps a local copy of it so “My files” can rebuild the link later; the server stores ciphertext it has no way to decrypt — a zero-knowledge design.

How long do links last?

You choose when you create the link: 1 hour, 1 day, 3 days, 7 days, or up to 14 days depending on your plan, or you can set it to burn on the first download instead of a fixed expiry. After that point the link stops working.

Is the file really gone after burn-after-read?

Burn-after-read is designed for exactly one download, and the slot is spent as soon as that download starts delivering real ciphertext — so the link stops working for anyone who opens it afterward, even if the one download was interrupted and never finished. Only an attempt that transferred nothing at all is handed back.

Have a file ready but no one waiting on the other end? Create an expiring link in your browser and send it whenever you're ready.

Try Relayium now