How a QR-paired browser tool handles encryption without user accounts

A new browser handoff tool is redefining how users transfer files and text between devices without accounts, apps, or cloud storage. By pairing devices through QR codes, the tool enables real-time data sharing with a focus on encryption and privacy—without promising more than it can deliver.

A narrow tool with broad implications

The tool’s core function is simple: open a webpage on one device, scan a QR code from another, and transfer text or a single file between the two browsers. Unlike cloud-based solutions, this approach eliminates the need for accounts, installations, or public file links. Instead, it relies on a live pairing session where both browsers are active simultaneously.

Designing such a tool required balancing flexibility with clarity. Public file links, for example, introduce risks like accidental sharing, log exposure, or offline handling. By avoiding them, the tool simplifies its mental model:

• No accounts or inboxes.
• No public download pages or stored file queues.
• No long-lived share links.

This constraint makes the product less versatile but also more straightforward for users.

Pairing with a short-lived session ID

The QR code doesn’t need to contain a secret. Instead, it can display a short pairing URL like ` This ID acts as a temporary handle to connect WebSocket clients, not as an encryption key. While the ID should be handled with care—since it could be captured via screenshot or screen share—it doesn’t expose a secret payload.

This design choice shifts the encryption burden to browser-generated keys. If the QR code itself were the secret, the UI would need to treat it as highly sensitive material. By separating the pairing ID from encryption, the tool can rely on browser-generated keys for secure communication.

Browser-generated ECDH for secure transfers

The tool uses the Web Crypto API to generate P-256 ECDH key pairs in each browser. Public keys are exchanged through the pairing channel, and the shared secret is derived for AES-GCM encryption. The process works as follows:

• Browser A and Browser B each generate an ECDH key pair.
• Public keys are exchanged via the pairing service.
• Both browsers derive shared key material.
• Browser A encrypts data before sending; Browser B decrypts after receiving.

Separate derivation contexts, such as icyzip/text/ecdh/v2 and icyzip/file/ecdh/v1, ensure key separation between text and file transfers. This prevents future design changes in one path from inadvertently affecting the other.

A critical lesson was avoiding the assumption that a paired session equals a permanent trust relationship. Browser tabs can close, devices may suspend, and network reconnections can reset WebSocket connections. The UI must handle these lifecycle events explicitly, distinguishing between:

• Waiting for the second browser.
• Connected to the expected peer.
• Disconnected or unable to verify the peer (requiring a new QR scan).

Why files are not just big text

File transfers introduce complexities beyond text sharing. Large files require progress tracking, cancellation support, and memory-efficient handling. The current design limits transfers to a single file per session to avoid additional product and security challenges:

• No folder sync or offline queues.
• No public archives or multi-recipient sharing.
• No account-based file history.

Files are encrypted in chunks on the sender’s side, routed through the service as encrypted bytes, and decrypted on the receiver’s side. If decryption fails, the transfer halts rather than displaying partial or corrupted content.

Browser behavior also plays a significant role in the tool’s reliability. Differences in how desktop browsers, mobile Chrome, mobile Firefox, and embedded WebViews handle backgrounding, clipboard access, file inputs, and memory pressure can introduce unexpected vulnerabilities. Features that seem stable in desktop environments may break in real-world phone-to-laptop scenarios.

For tools like this, proving the narrow use case on real devices before expanding functionality is essential. Adding support for multiple files, background retries, or cross-session history may seem useful, but each expansion increases the complexity of states users must understand.

Encryption doesn’t mean invisibility

Browser-side encryption for text and file content doesn’t imply the service sees nothing. The tool’s design explicitly acknowledges metadata exposure. While the payload remains secure, the service may still observe:

• Session timing.
• Data size.
• Transfer direction.

This transparency is intentional. Marketing copy that overpromises privacy risks undermining user trust. The tool’s value lies in its simplicity and reliability, not in claims it can’t substantiate.

Looking ahead, the narrow use case provides a solid foundation. Future iterations could explore broader features, but only if they align with the tool’s core principles: security, simplicity, and user control. For now, the focus remains on delivering a dependable, session-only handoff experience.