Feature

Passwords, expiry dates, and download limits

Layer practical access controls onto a transfer by setting a password, an availability window, and a cap on successful downloads.

Try the real sender See how it works ↓

Access recipePrivate handoff

Recipient pathLink → password → preview → download

01PBKDF2Password derivation with SHA-256

02210,000Password hashing iterations

03Per transferExpiry and download-limit choices

Feature01

Each control answers a different risk

A password protects against someone who only has the link. Expiry closes an old delivery. A download limit restricts repeated successful access. Combining them can help, but none replaces confirming the recipient.

Feature02

Passwords are not stored as readable text

TransferSize derives the stored password value using PBKDF2-SHA-256 with 210,000 iterations and a random salt. Send the password through a different channel from the link so intercepting one message does not reveal both.

Feature03

Choose limits that match the job

Short deadlines are useful for sensitive handoffs but frustrating when a stakeholder is away. Download limits should allow the expected devices and retries. Tell the recipient about both before delivery.

Edge cases

Before the handoff

Does a password encrypt the uploaded file itself?

No. It gates access to the transfer. Do not treat it as client-side end-to-end file encryption.

Can I extend an expired transfer?

Plan around the chosen window before sharing; availability after expiry should not be assumed.

Move something real

Try the workflow in the live sender, with no card required.

Choose files