BROWSER-TO-BROWSER TRANSFER

Send a file from one browser to another.

Open a temporary channel, copy the link, and keep the source tab online. this2.link prefers a direct WebRTC DataChannel and verifies encrypted chunks in the receiving browser.

Open a browser channel

WebRTC first · encrypted fallback · verified chunks

THIS2LINK / CHANNEL

01BROWSER AENCRYPT LOCALLY

WEBRTC / CIPHERTEXT

02BROWSER BVERIFY + RESTORE

NO SERVER FILE COPY

PROCESS

The browser-to-browser route

Prepare locally

Your browser creates a random capability, derives separate encryption and channel credentials, and encrypts the selected file on the device.

Negotiate a route

The browsers use signaling to discover one another and exchange WebRTC connection details. The capability and file key are not placed in signaling messages.

Transfer and verify

Encrypted chunks travel over the direct DataChannel when possible. The receiver authenticates the chunks before restoring the file.

WEBRTC

Direct is preferred, not falsely guaranteed

WebRTC can establish a browser-to-browser path across many home, office, and mobile networks. It avoids first placing a complete file in a central download bucket.

Some networks block or degrade direct connectivity. After a bounded connection attempt, this2.link can switch to a WebSocket path that only forwards ciphertext. The source browser must still remain online.

USE CASES

Designed for an active handoff

This model works well when two people are present at roughly the same time: moving a photo from phone to laptop, sending a project export to a collaborator, or passing text and a file during a call.

No software installation
No recipient account
One host-led channel with private visitor replies
Completed receivers can temporarily relay onward

BOUNDARIES

What a direct transfer does not promise

Not permanent hosting

The link depends on at least one online browser that still holds the encrypted content.

Not always a direct route

Strict NAT, corporate firewalls, VPNs, or browser restrictions can force the ciphertext fallback.

Not anonymous networking

Peers and infrastructure can observe ordinary connection metadata even though file content remains encrypted.

FAQ

Browser-to-browser transfer FAQ

Is WebRTC used for every transfer?

WebRTC is the preferred route. If it cannot connect, this2.link can forward bounded encrypted chunks through its WebSocket relay.

Does the signaling server receive the decryption key?

No. Signaling receives derived room credentials and connection messages, not the complete URL Fragment capability or file key.

Must both browsers stay open?

A source must remain online during transfer. After receiving and caching the encrypted content, the receiver can become a temporary source while its page stays open.

Can I send text as well as a file?

Yes. A channel can pass text or one file at a time, and both sides can continue replying while the channel remains connected.

Browser-to-browser transfer when the network allows it.