01 / Start here
How SendIt establishes a secure session
The exact setup depends on whether the devices connect with a QR invitation or a manually entered session PIN.
- 01
Create a short-lived session
The sending browser creates the session and prepares the key material used to protect content.
- 02
Pair with QR or PIN
QR invitations carry a 256-bit secret in the URL fragment. PIN-only pairing uses ephemeral P-256 ECDH to establish shared key material.
- 03
Verify PIN pairing
For PIN sessions, both devices show one eight-digit security number derived from the agreement. Continue only when the numbers match.
- 04
Encrypt before transmission
Messages, file content, filenames, MIME types, and clipboard content are encrypted in the browser before reaching the relay or temporary object storage.
02 / Guide
Authenticated encryption for messages and files
SendIt uses AES-256-GCM, which both encrypts data and authenticates it. Altered encrypted content fails authentication instead of being silently accepted by the receiving browser.
Per-file keys are derived with HKDF-SHA-256. File chunks are independently authenticated with transfer context so a chunk cannot simply be moved to another position or transfer and remain valid.
03 / Guide
Where the decryption keys live
Key material stays in browser memory and is not saved to local storage. SendIt's relay, database, and Cloudflare R2 storage do not receive the browser-held decryption key.
That design has a deliberate usability tradeoff: a stored-file download card cannot survive a page refresh if the browser no longer has the key needed to decrypt it.
04 / Guide
What encryption does not hide
End-to-end encryption protects the content, but it does not make the transfer invisible. SendIt still processes information required to connect devices, route data, limit abuse, and enforce large-transfer credits.
Connection metadata, transfer timing, session identifiers, and file size can remain visible. The device and browser also remain part of the security boundary, so a compromised endpoint can expose content after decryption.
05 / Guide
What “secure” means here
SendIt is designed for private browser transfers between two devices. It does not claim to replace enterprise managed file transfer, formal compliance programs, hardware-backed endpoint security, or an audited records platform.
Use a system with the required identity, retention, audit, legal, and compliance controls when your organization depends on those assurances.
Comparison
Protected content and visible metadata
| Protected end to end | Still visible for operation |
|---|---|
| File contents | File size |
| Filenames and MIME types | Transfer timing |
| Messages and clipboard content | Session identifiers |
| Stored file objects | Connection metadata |
Questions
Common questions
Can SendIt's relay decrypt my file?
The relay does not receive the browser-held decryption key. It routes encrypted content and the operational metadata needed to deliver it.
What should I do if the security numbers do not match?
Cancel the pairing immediately and create a new session. A PIN connection should only be approved when the same eight-digit number appears on both devices.
Are large files encrypted in temporary storage?
Yes. Credit-based large-transfer objects are encrypted before upload. Cloudflare R2 stores the encrypted object and does not receive the browser-held decryption key.
Does end-to-end encryption protect a compromised device?
No. Encryption protects data between endpoints; malware, unsafe downloads, or someone controlling either endpoint can access content after it is decrypted there.