Log In Get Started
Free tool

404 Send

The file goes straight from your browser into the recipient’s browser. It never ends up on our servers — we pass only an encrypted envelope describing the connection so that the two browsers can find each other. We see neither the file, nor its name, nor either side’s address.

Pick the files, hand over the link — and keep the tab open while the transfer runs.

Ready to send
Drop files here or

The link lives ten minutes. The transfer is direct — the file never appears on our servers.

How it works

Ordinary file-sharing services are all built the same way: the file travels to someone else’s disk, sits there for who knows how long and lives a life of its own. Here it is different. The sender’s browser and the recipient’s browser connect directly over WebRTC, the file goes between them, and our server takes part in exactly one step — passing the envelope with the connection description so the sides can find each other.

That envelope we do not read either. It contains the IP addresses of both sides, so the page encrypts it at your end, and the key stays in the part of the link after the hash — by the design of HTTP that part is never sent to a server at all. On our side an opaque string sits for ten minutes, and we have no key to it.

What does not work here

If both sides sit behind networks with symmetric NAT — typical of mobile internet and strict corporate Wi-Fi — a direct connection will not be established. The cure is for one side to change network. The relay through which such connections are usually pushed we deliberately do not run: through it the files would travel through us, and the point of the tool is the opposite. What your network blocks can be checked with the neighbouring tool.

The same principle in everything else

404 VPN is built the same way: we keep no visit logs, no DNS queries and no traffic contents. Not because we promise, but because there is nothing to hand over on request.

How it works →

FAQ

guest@404vpn:~$ cat send-faq.md
[01] $ Where does the file sit until the recipient opens it? ▸
> Nowhere. It sits on your disk, and the transfer begins only when the recipient has opened the link and pressed Accept. That is why the tab must stay open: this is not an upload to a server but a direct connection between two browsers, and one side does not work without the other.
[02] $ What does your server see? ▸
> A string it cannot read. The recipient’s browser needs a description of the connection — the SDP — and that contains the IP addresses of both sides. So the page encrypts it at your end (AES-GCM) and puts the key in the #-part of the link: by the design of HTTP that part of an address is never sent to a server at all. The room name is a hash of the same secret. We do not have the key, rather than promising not to use it.
[03] $ How large a file can be sent? ▸
> The limit is not in the transfer but in the recipient’s memory: the browser assembles the whole file before offering to save it. On an ordinary laptop that is comfortably several gigabytes; on an old phone, hundreds of megabytes. The speed is the lesser of the two channels, usually the sender’s upload.
[04] $ It says "the connection was not established". What does that mean? ▸
> It means both sides turned out to be behind a network that does not allow a direct connection — that happens on mobile networks and on corporate Wi-Fi with symmetric NAT. Switching one side to another network usually helps: the recipient moving from mobile data to Wi-Fi, for instance. We deliberately run no relay in between: through it the files would travel through us, and the whole point is the opposite.
[05] $ The link could leak. Will a stranger take the file? ▸
> Whoever opens the link first. The link works once and lives ten minutes, but within those ten minutes it is the key — pass it the same way you would trust to pass the file itself. And do not close the tab before the transfer ends: the moment you do, the link stops meaning anything.