Architecture, not marketing

How ReadOnce keeps us blind

Send up to 5 TB. We still can’t see a single byte — because the key that unlocks your share never reaches our servers.

Two paths. Only one hits our servers.

Payload path

  1. FILE On your device
  2. Browser encryption AES-256-GCM
  3. Ciphertext Unreadable bytes
  4. ReadOnce storage We only keep ciphertext

Key path

  1. AES key Generated locally
  2. #URL fragment Never sent in HTTP
  3. Recipient Decrypts in their browser

Your browser encrypts it. Your recipient decrypts it.
We never get the key.

Burn after successful download

Resumable download (chunk retries + on-disk size check). For new shares the recipient’s browser also checks a client-computed integrity proof before burn. That proof is encrypted with the same share key — we store the ciphertext; we cannot read the hashes. Interrupted downloads do not burn the ciphertext.

No account-linked file history

Premium uses a billing email only to check plan entitlement. After upload finishes, shares are anonymous ciphertext — not kept as a logged-in content library.

Resumable encrypted upload & download

At multi‑TB scale, a drop at 94% can’t mean “start over.” Uploads and downloads resume where they left off — still as encrypted chunks your browser produced. Premium accepts multi-file and folder drops (up to 100 files, plan total cap).

Straight answers

Can staff open my share?
No. The decryption key never reaches our servers. Without the URL fragment, we cannot decrypt the ciphertext.
What if a 5 TB download fails midway?
The share does not burn. Resume continues from the bytes already on disk (not from a progress counter alone). Burn happens only after the saved size matches and — for new shares — the recipient’s browser verifies the encrypted integrity proof.
Do you checksum files on the server?
No. A plaintext hash on our side would let us fingerprint content and would break zero-knowledge. Your browser hashes each chunk, encrypts that list with the share key, and we store only that ciphertext. The recipient decrypts and compares it locally before burn. We never see the hashes in the clear.
Why unlimited transfers?
We don’t meter monthly bandwidth. Your plan limits the maximum size of each share and how long it stays available — not how much encrypted data you send.
Where is this written legally?
In our Privacy Policy and Terms — including fragment keys and no account-linked file history for finished Premium shares.

Ready when the drop is huge — and private.

Free notes need no account. Premium starts when you need up to 5 TB we still can’t read.

See Orbit — 5 TB Send a free note