Five words,
and the file is there.
Read a short code out loud and the two browsers find each other. From then on the bytes travel straight from one device to the other, encrypted end to end. There is no upload step, no copy on disk, and no expiry to set — because there is nothing sitting anywhere waiting to expire.
This browser can't open a wormhole
It needs WebRTC data channels and the Web Crypto API over a secure connection. Recent Firefox, Chrome, Edge and Safari all qualify. In the meantime, a one-time secret link works everywhere.
Type it, paste it, or paste the whole link. Case and punctuation don't matter — the words do.
The code is the key. It is generated in this tab and never sent to the server — in the link it rides after the #, which browsers never transmit.
Both tabs have to be open at the same time. Need to leave something for someone to pick up later? Send a one-time secret instead.
A switchboard, not a warehouse
A one-time secret keeps ciphertext on the server until someone reads it. A wormhole keeps nothing, because nothing ever arrives: the server introduces the two browsers and gets out of the way.
The bytes never reach us
The transfer runs over a WebRTC data channel opened directly between the two browsers. Our server relays a few kilobytes of handshake and is told to close the room the instant the channel is up — while the file is still moving, the rendezvous no longer exists. There is no upload endpoint to point at, no object storage bucket, and no row in a database.
Five words, stretched
The pairing code is generated in the sender's browser and turned into an AES-256 key by 300,000 rounds of PBKDF2. The server relays messages it cannot open, and never sees the words.
The handshake is sealed
The connection offer — including the DTLS fingerprint that authenticates the peer — travels inside the encrypted envelope. A server that wanted to sit in the middle would have to forge a message it cannot even read.
It fails rather than reroute
Most transfer tools fall back to a TURN relay when NAT gets in the way. That works by pushing the bytes through someone else's machine. There is no TURN server here, and after connecting the app checks the chosen candidate pair really is direct.
Encrypted twice, on purpose
WebRTC already encrypts the channel with DTLS. Every chunk is also sealed with AES-256-GCM under a key derived from your code — the guarantee does not rest on the network path staying what it is today.
Four steps, one of them out loud
Pick your files
They stay on your disk. Nothing is read, hashed or uploaded at this point — choosing a file only tells the page what to send later.
Share the code
A slot number and five words from the PGP word list, picked so they survive being read over a bad phone line: 4-adroitness-basalt-chairlift-crucial-decadence. Say it, or send the link — the words sit after the #, which never leaves the browser.
The browsers find each other
Both sides derive the same key from the code and exchange a sealed handshake through the rendezvous. Both screens then show the same four-word verifier: if they match, there is nobody in between. A wrong code is rejected, and the sender simply keeps waiting for the right one.
The file crosses
Straight from one device to the other, in encrypted chunks. On the same Wi-Fi it never leaves the building. Close either tab and the transfer stops where it stands, leaving nothing behind on either side of the wire.
Borrowed from magic-wormhole
The idea, and the lovely detail of a code you can read down the phone, come from magic-wormhole by Brian Warner. The pairing codes here use its PGP word list, and the shape of the protocol — short code, rendezvous, direct transfer — is its shape.
It is not the same protocol, and it will not talk to the wormhole command-line tool. Two things force that. magic-wormhole moves data over a raw TCP connection, which a web page cannot open — the existing browser ports solve this by routing the transfer through a transit relay, which is the one thing this feature is not allowed to do, so it uses a WebRTC data channel instead. And magic-wormhole authenticates its two-word code with SPAKE2, a password-authenticated key exchange that turns a wrong guess into a failed online attempt; there is no SPAKE2 in a browser's crypto toolbox, so the code here is a plain shared secret that has to survive an offline attack instead — hence five words and 300,000 rounds of PBKDF2 rather than two words.
For sending between two computers you control, the real magic-wormhole is better: it resumes, it has no browser in the way, and it is a genuine PAKE. This is for the case where one end is someone else's laptop and all you can ask them to do is open a web page.
Frequently Asked Questions
Q: Where is my file stored during a transfer?
Nowhere. It goes browser to browser. The server only relays the encrypted handshake and never receives a byte of the file, so there is nothing on it to store, log or hand over.
Q: Do we both have to be online at once?
Yes — that is the trade. A wormhole is a live connection. For something the other person can pick up tomorrow, use a one-time secret link.
Q: How big can a file be?
Up to 100 MB per transfer without an account, and 1 GB with a free account. Those are fairness limits, not storage limits — nothing is stored either way. Beyond that the receiving browser is the real ceiling: on Chrome and Edge a single file streams straight to a location you pick, while elsewhere it is assembled in memory first.
Q: What if no direct connection can be made?
It fails and tells you. Some corporate and mobile networks make direct connections impossible; the usual workaround is relaying the bytes through a third machine, which would break the promise on this page. On the same Wi-Fi it essentially always works.
Q: Can I use it from a script or the API?
Not yet — a wormhole needs a browser at both ends. The cURL API covers one-time secrets, which is the right tool for CI and deployment scripts anyway.