Sending in the Browser

File transfer in the browser happens entirely on the Tallow homepage. The send module is embedded directly in the hero section (anchor #send) — there is no separate web app or /transfer page to open. No installation is required; everything runs client-side with WebAssembly.

Getting Started

1. Go to the Tallow homepage send module
2. Drop files or folders into the drop zone, or click to browse, or select a folder
3. Tallow starts your room as soon as files are added — a shareable room code plus a short link (/s/<token>) appear automatically
4. Share the short link (or the room code) with the receiver
5. The transfer starts automatically once the receiver joins and accepts

All cryptographic operations happen in your browser via WebAssembly. The browser client connects to the relay via WebSocket and uses the same end-to-end encryption (ML-KEM-1024 + X25519, AES-256-GCM, BLAKE3) as the CLI.

Sending Files

1. Go to the homepage send module
2. Drag and drop files or folders into the drop zone, or click to browse (use or select a folder for a whole directory)
3. Your room starts automatically — a shareable room code plus a short link (/s/<token>) appear right away
4. Share the short link (or the room code) with the receiver
5. The transfer starts automatically once the receiver joins and accepts

Receiving Files

1. Open the short link your sender sent you (/s/<token>) — you join automatically, no code to type
2. Accept the files when prompted — the transfer begins securely
3. Files are received end-to-end encrypted

Transfer Progress

During a transfer, the send module shows:

• Progress percentage with current speed and ETA
• Bytes transferred versus total bytes
• Completion status with per-chunk integrity verification

One-Time Room

Each bundle opens a one-time encrypted room. The room code is a six-character passcode (for example, U93DGU); the relay only ever receives a one-way, memory-hard Argon2id derivation of it — never the code itself. Up to 1 GiB (1 GB) per room, nothing stored — the cap is enforced in the client before the offer is sent; within it, the practical limit is your browser (End-to-end mode decrypts in the browser and its direct device-to-device path is verified byte-exact at 256 MB, 512 MB and 1 GB; transport-only mode streams to disk). The room is automatically closed when the transfer completes — files are never persisted server-side.

How share links work: the /s/<token> short link carries a derived, opaque token — never the room code itself. The token is resolved in your browser; the server serves a static page and keeps no token-to-room mapping (short-link paths are excluded from access logs). Anyone holding the link can join, just like anyone holding the code.

The sender must keep the tab open until the receiver finishes.

Direct LAN transfers (Transport-only mode)

When both devices are on the same network, Transport-only transfers try a direct connection between the two devices first — the file data never leaves your network, and the relay is used only to introduce the devices (room code) and set up the connection. If a direct connection can’t be made, the transfer falls back to the relay automatically.

• Enable / disable: the Direct LAN control appears under the Transport-only/End-to-end selector whenever Transport-only is selected; it also lives in Settings → Transfer as Direct LAN transfers (on by default).
• Monitoring: while a transfer runs, the status line shows the live path — Direct — local network, Direct — peer-to-peer, or Via relay.
• No configuration needed: the browser negotiates everything automatically. Networks that block peer-to-peer traffic (guest Wi-Fi, strict corporate networks) simply fall back to the relay.
• Privacy: a direct connection exposes your local network address to the other device (standard for peer-to-peer; host addresses are mDNS-obfuscated where the browser supports it). Enhanced Privacy, Tor mode, and Relay-only (hide your IP) all disable direct connections.

Traffic padding

Traffic padding is opt-in (Settings → Transfer → Traffic padding). When it is on, the browser sends encrypted dummy chunks at a constant rate alongside the real transfer, so a passive observer cannot infer transfer timing, size or direction from the wire. Dummy chunks are marked and discarded by the receiver, and a 30-second wind-down follows a stop so the end of a session is not readable from the traffic either.

Tiers are 1, 5 and 25 Mbps. The tier is the rate of the dummy stream, not a cap on the transfer — it runs in parallel with the real data, which is why it costs bandwidth and is off by default.

The trade is stated rather than hidden: our tolerance is that padding overhead stay at or below 5 % of the link rate. Pick the tier nearest — but not above — that fraction of your connection, and step down (or turn padding off) if the padded stream would exceed it. A 25 Mbps padder on a 10 Mbps link is not a padder. Padding masks timing; it is not a size or confidentiality guarantee — for confidentiality from the relay, use an End-to-end transfer.

Browser Requirements

Required browser features:

• WebAssembly (WASM)
• WebSocket
• SubtleCrypto API (for random number generation)
• File API / Drag and Drop

Security Notes

• All encryption keys exist only in browser memory and are zeroed on disconnect
• No data is stored on the server — the relay only forwards encrypted bytes
• One-time rooms expire and are emptied after each transfer
• The browser client has no server-side component — everything is a static export