Is it safe to send files over the internet?

Last updated: 2026-08-06

"Is it safe to send this file?" is a reasonable question to stop and ask, whether it's a tax return, a contract, or just photos you'd rather stayed private. This guide isn't about scaring you off common tools — it's about walking through, plainly, what actually happens to a file when you email it, drop it in a cloud folder, or carry it on a USB stick, what the phrases "end-to-end encrypted" and "zero-knowledge" actually promise, and what to check before you trust any tool with something you care about.

None of this requires a technical background. By the end, you'll know what questions to ask — of any transfer method, including this one.

Where files actually go wrong: the everyday risks

Email attachments pass through your mail provider's servers and the recipient's, both of which commonly scan, index, and back up messages for spam filtering and disaster recovery — long after you've forgotten you sent it. Forward the email once, and the file is in front of someone you never intended, with no way to know every copy is gone.

Cloud storage links are convenient, but a link usually keeps working until you remember to revoke it, and "anyone with the link" is only as private as an unguessable URL — which a link-shortening service or a careless forward can undo. The file also inherits the security of the whole account it sits in, not just the share itself.

A USB stick feels safe because it's offline, but that's exactly the gap: most drives aren't encrypted by default, so a stick left in a laptop bag or a rental car hands over the plaintext to whoever finds it, no password required.

Free public upload sites solve the immediate problem — get a file from A to B — but rarely say what happens next: how long it's kept, whether it's scanned, who might stumble on it, or how the site pays its bills (ad-funded file hosts have a track record of bundling trackers or worse).

Email: retained and scanned by mail servers, easy to forward beyond your control
Cloud links: keep working until revoked, and inherit the whole account's security
USB drives: unencrypted by default, easy to lose or leave behind
Free upload sites: retention and scanning practices are usually unclear

What "end-to-end encrypted" and "zero-knowledge" actually mean

Plenty of services say "encrypted" and mean only that the connection to their server is encrypted — standard HTTPS/TLS, the same padlock icon your bank uses. That's real protection against someone eavesdropping on the network, but it stops at the server: once your file arrives, the service itself can read it, because it holds the key. A lot of everyday tools stop exactly there.

End-to-end encryption means something stronger: the file is encrypted before it leaves your device, with a key that only the sender and the intended recipient ever hold. The service that carries it — the server, the relay, anything in between — never has the key, so it never has the plaintext, no matter how it's asked.

"Zero-knowledge" is a related idea usually applied to something stored rather than sent live: even data sitting at rest on a server was encrypted with a key the server itself was never given, so the operator has no way to read it, ever, no matter how long it stays there.

"Encrypted" alone often just means TLS to the server — the provider can still read the file.
"End-to-end encrypted" means only sender and recipient hold the key.
"Zero-knowledge" means the server holds data it structurally cannot decrypt, even at rest.

What to actually check before trusting a transfer tool

What you need to run this checklist

Ten minutes and a browser. The first two checks are reading, not auditing.
Two devices for the live checks. Three and four cannot be done from a marketing page, which is exactly why they are worth doing.
No security expertise. Each item below is either something you can read or something you can see happen.

The marketing language on a website is worth less than a few concrete questions:

Find the vendor's own answer to "can you read my files?" in their source, not on their pricing page. If there is no source, that is already an answer.
```
https://github.com/relayium/relayium
```
Check the licence and whether the repository is the thing that is actually deployed. A claim you can inspect is a different kind of claim from one you are asked to accept.
On a live transfer, compare the verification code on both screens. This is the step that turns "end-to-end encrypted" from a sentence into something being enforced between these two particular endpoints.
```
https://relayium.com/
```
While that transfer runs, open your browser's developer tools and watch the network panel. Look for your file's contents in what is being uploaded. Not finding them is the point; finding them would be the finding.
Check what is left afterwards: whether a link expires on its own, and whether the service could produce the file again later if someone asked it to.

What passing this checklist actually tells you

The first two checks are cheap and rule out most tools in minutes. The last three cannot be faked by a landing page, because they are things you watch happen on your own two devices.

None of it makes a tool trustworthy in the abstract. It makes specific claims checkable, which is the most any of us can do without reading every line ourselves.

Does it say "encrypted" (could mean just TLS) or specifically "end-to-end encrypted" (only sender and recipient hold the key)?
Is there a way to verify the connection wasn't tampered with — a code you compare, not just a padlock icon you have to trust?
Is the file's integrity checked, so a corrupted or altered file doesn't arrive silently wrong?
Is the code open source and auditable, or are the claims just marketing you have to take on faith?
Does sending or receiving require handing over more identity than the transfer actually needs?
If anything is stored, does it have a clear, finite lifetime — an expiry or delete-after-download — instead of sitting there indefinitely?

How Relayium answers each of these

For a live transfer, with both people online at once, Relayium generates a fresh X25519 key pair on each device and derives a shared AES-256-GCM key that exists only inside the two browsers — it's never sent to Relayium's own servers. An optional short verification code (a SAS) — shown when you turn on advanced verification, which is off by default — lets both sides confirm the keys weren't swapped by a dishonest server in the middle, and each file's SHA-256 hash is checked end to end so a corrupted transfer doesn't arrive looking fine. The mechanics of exactly how that works are covered in more depth in "How Relayium encrypts your files end-to-end", if you want to go further than this page.

When the recipient isn't online yet, a stored download link uses a genuinely different, zero-knowledge design: your browser generates a random AES-256-GCM key and encrypts the files with it before anything uploads. That key is never sent to the server — it lives only in the link's URL fragment, the part after #, which browsers never transmit. The server ends up holding ciphertext it has no way to decrypt, plus an expiry you choose: 1 hour, 1 day, 3 days, 7 days, or up to 14 days depending on your plan, or burn after the first completed download.

Across networks, Relayium's browser app uses TURN by design: the relay carries end-to-end encrypted ciphertext, but it never receives the key and cannot read or decrypt the file.

None of this asks you to trust a claim on faith: Relayium's client and server code is open source under the AGPL-3.0 license, so it can be read and audited rather than taken on faith.

Same-network transfers need no account at all.
Sending across networks by pairing code, or creating a stored link, needs the sender to sign in — the recipient never needs an account.

Encryption isn't the whole story — a few habits still matter

Strong encryption protects a file in transit and at rest, but it can't stop you from sending a link to the wrong address — treat a share link like the file itself, and don't post it somewhere public.

For anything genuinely sensitive, turn on advanced verification and take the extra few seconds to compare the verification code out loud on a call, or in person, rather than trusting that two matching screens next to each other haven't both been fooled.

And no transfer tool, however well encrypted, protects a file that's already exposed on a device that's compromised — good encryption assumes the two ends themselves are trustworthy. None of this is a reason to be paranoid about sending files; it's just worth knowing what encryption does and doesn't cover.

When a check does not give you a clean answer

Three places people get stuck. In each case the ambiguity is itself informative.

What you run into, what to check, what it means

The network panel shows a large upload and you cannot tell what is in it.

https://relayium.com/   # developer tools, Network panel, during a transfer

That is the expected result, not a dead end. What you are looking for is the absence of anything recognisable from your file — a filename you chose, a string you know is in the document. If you can read your own content in the payload, that is the finding, and it is a decisive one.

There is no verification code, so the third check cannot be done.

https://relayium.com/   # a stored link has no second live endpoint to compare against

You are on a stored-link transfer rather than a live one. There is no second endpoint online to compare against, so the guarantee has a different shape: the key lives in the link fragment and never reaches the server at all. Compare codes on live transfers, and check link expiry on stored ones.

The source is open but you cannot read the language it is written in.

https://github.com/relayium/relayium   # is the claim falsifiable at all

You do not have to. The question this check answers is whether the claim is falsifiable at all: is there a repository, does it correspond to what is deployed, could someone who does read that language contradict it. A claim nobody is in a position to check is the finding.

Frequently asked questions

Is it safe to email a sensitive file?

Email isn't designed for confidential file transfer — attachments are commonly retained, scanned, and backed up by mail servers on both ends, and a forwarded message can put the file in front of people you never intended. It's fine for low-stakes files; for anything sensitive, a tool with end-to-end encryption removes that exposure.

What does "zero-knowledge" actually mean?

That the party storing your data was never given the key to read it. The encryption happens on your device before anything uploads, and the key lives only somewhere the server never sees — like a URL fragment — so what sits on the server is ciphertext it structurally cannot decrypt, not just data it promises not to look at.

Is a password-protected zip file good enough?

It's better than nothing, but the password often travels the same way as the file — in the same email thread, for instance — which undoes the protection, and zip encryption implementations vary widely in strength. A tool built around end-to-end encryption removes that weak link by never needing a shared password at all.

Does Relayium keep a copy of my files?

In realtime mode, Relayium keeps no server-side copy or transfer history: WebRTC is direct on the same LAN, while cross-network browser sessions use TURN by design to carry end-to-end encrypted ciphertext the relay cannot read or decrypt. For a stored link, the server holds only encrypted ciphertext it cannot read, until the link expires or is downloaded once if you chose burn-after-read.

Do I need an account to send or receive a file?

On the same network, neither side needs an account. Sending across networks by pairing code, or creating a stored link, requires the sender to sign in — but the person receiving never needs an account, whichever mode is used.

Curious whether a tool actually protects what it claims to? Start a transfer, turn on advanced verification, and see the verification code and the zero-knowledge link for yourself.

Try Relayium now