Relayium

Relayium vs Dropbox for sending a file

Last updated: 2026-07-31

Dropbox earns its reputation. It syncs a folder across every machine you own, keeps a version history when you overwrite something by accident, and makes it painless to hand a whole project folder to a client with a shared-link invite. If you want a working folder that just stays in sync, Dropbox does that job well and this isn't an argument against using it that way.

The friction shows up on a narrower job: one file, one recipient, and no need to keep it afterward. Dropbox puts it in an account first. Relayium instead streams it live — direct over WebRTC on the same LAN or as end-to-end ciphertext over TURN across networks — or creates a link that decrypts only in the recipient's browser and disappears on your schedule.

What Dropbox is genuinely good at

Dropbox's core strength is that a folder you rely on is always current everywhere: edit a file on your laptop and it's already updated on your phone by the time you check. Selective sync, LAN sync for large local transfers, and file-recovery/version history all serve that same goal — a durable, dependable place for files you keep coming back to.

Shared folders and Dropbox Paper make it a solid pick for ongoing collaboration, and its link-sharing is genuinely convenient for small teams that already live in Dropbox day to day. None of that is what Relayium is trying to be — Relayium doesn't sync a folder or keep a working copy of anything.

The gap: a share link still means an account holds the file

To send one file through Dropbox, it first has to be inside Dropbox — uploaded to your account, sitting in a folder, before you generate a shareable link for it. That link points at a copy Dropbox is storing on your behalf, readable by Dropbox's own infrastructure and staying there until you go back and delete the file or revoke the link yourself.

For a one-off send, Relayium's realtime mode avoids a stored server-side content copy or history: WebRTC is direct on the same LAN, while cross-network browser sessions use TURN by design to carry end-to-end ciphertext the relay cannot read or decrypt. When you do want a link because the recipient is offline, the stored-link mode keeps a property Dropbox sharing lacks: your browser generates a random AES-256-GCM key and encrypts before upload, and the key lives only in the URL fragment after #, which browsers never send to a server. Dropbox can technically read files in your account; Relayium's stored-link server holds only ciphertext it cannot decrypt.

Realtime send: no server-side content copy or history

When both people are online, realtime transfer streams up to 1,000 files over the selected path: direct WebRTC on the same LAN, or TURN by design across networks. There is no upload-for-storage step or server-side realtime content history. Advanced verification (off by default) adds a matching 6-digit verification code (SAS) for both sides, every file is checked with SHA-256 end to end, and a dropped connection resumes.

There's no server-side storage-size cap; the receiving browser sets the practical ceiling. Chrome and Edge stream to disk; Firefox and Safari may buffer in memory, so Relayium warns above roughly 256 MB. On the same LAN no account is needed and WebRTC connects directly. Across networks, whoever creates the pairing code signs in and the browser uses TURN by design; the relay carries only end-to-end ciphertext it cannot read or decrypt. The person joining never needs an account.

When you need a link instead: zero-knowledge, self-expiring

Sometimes a link genuinely is the right tool — the recipient is asleep in another time zone, or you want one URL to paste into an email instead of coordinating a live session. Relayium's stored-link mode is built for exactly that, without giving up the privacy of realtime mode.

You pick how long it lives — 1 hour, 1 day, 3 days, 7 days, or up to 14 days depending on your plan — or set it to burn after the first completed download, so there's no lingering copy to remember to clean up. Creating the link requires the sender to sign in (it counts against a storage quota on the account), but the recipient just opens it and downloads — no Dropbox-style account required on their end. Because the decryption key never leaves the URL fragment, Relayium's server for a stored link is structurally unable to read what's inside it, which is a different guarantee than a Dropbox share link, where Dropbox's own infrastructure can technically decrypt the file it's hosting.

Side-by-side

The differences most relevant to a one-off send:

Frequently asked questions

Does the file sit in an account like it would with Dropbox?

Not as a server-side realtime copy or history. On the same LAN WebRTC is direct; across networks TURN carries end-to-end ciphertext the relay cannot read or decrypt. A download link does store zero-knowledge ciphertext, but the server cannot decrypt it and the link expires or burns after the first download.

Does my recipient need to sign up for anything?

No. On the same LAN, neither side needs an account. The pairing-code or stored-link creator signs in; the person joining the realtime session or downloading the link never needs an account.

Is there a file size limit?

Realtime transfers handle up to 1,000 files per batch with no server-side size cap — Chrome and Edge stream straight to disk for tens of gigabytes. When no streaming path applies and the browser has to buffer in memory, Relayium warns above roughly 256 MB; that figure is a deliberately conservative estimate, not a hard limit. Stored links count against a quota tied to the sender's account.

Is Relayium free to use instead of a Dropbox plan?

Yes. Relayium is free and open source under the AGPL-3.0 license, with the full protocol and code at github.com/relayium/relayium — there's no paid tier gating bigger or faster transfers.

Send the file in realtime without putting it in anyone's account — no install, and no account needed on the same LAN.

Try Relayium now

Keep reading