Frequently Asked Questions

I don't want to set up cloud storage just to try it out.

Use the Community Bucket - a shared storage pool funded by donations. No account, no configuration, just select it when creating a send.

If it's empty, a small donation goes a long way. Storage costs cents on the dollar - see the calculator - and every contribution funds transfers for you, anyone else who stumbles in, and helps keep the lights on.

DONATE TO FILL THE BUCKET

What is The File Share Place?

A desktop app and landing website for sending files to anyone via a secure download link. You connect it to your own S3-compatible cloud storage (Backblaze B2, Wasabi, AWS S3, Cloudflare R2, and more) - your files live in your bucket, this platform just coordinates the access. Don't want to set up storage just to try it? The Community Bucket is a shared storage pool funded by donations that you can use right away. Recipients open a link in their browser, no install required (as long as the files aren't encrypted).

What does it cost?

The app and relay service are free. You pay an S3 compatible cloud storage provider for the storage and egress that you use. Backblaze B2 runs around $6.95 / TB / month with 3x storage free egress and my recommended vendor. Use of the service is subject to the Terms of Service.

What platforms does the app run on?

Windows, macOS, and Linux. The app is currently in private beta - request access to get started.

Are there any plans to allow uploads through the browser?

No. Uploads go through the desktop app by design - it lets the app fully saturate your bandwidth with parallel multipart uploads, pause and resume transfers at any point, handle client-side encryption before anything leaves your machine, and avoid the file size limits browsers impose. Recipients can download through their browser or the desktop app - the app is required for sends using client-side encryption, since decryption happens locally.

Can I use my own domain or add custom branding?

Absolutely. If you're interested in a branded version of this platform, reach out and we can talk through your needs and pricing.

Why does the relay server need my S3 credentials?

When a recipient downloads a file, the relay generates a short-lived presigned S3 URL on their behalf. The credentials are only used for this purpose, are stored encrypted, and are deleted when the send expires. I recommend creating a dedicated API key scoped to the minimum required permissions - you can revoke it at any time from your storage provider's dashboard.

Can you read my files?

Technically I could, but I won't. Downloads go directly from your S3 bucket to your recipient's browser - the relay server is not in the data path and I have no interest in your files. For sends using client-side encryption, I couldn't read them even if I wanted to. See the Privacy Policy for full details. Enable bucket logging or use the E2E encrypted sends if you have concerns.

If you aren't storing my passwords, how are you granting access when the recipient supplies one?

When you create a send, the desktop app hashes the passphrase locally using PBKDF2·SHA-256 — 100,000 rounds over a freshly generated random salt — and only the resulting base64(salt):base64(hash) is transmitted to the relay. The raw passphrase never leaves your machine at send-creation time. We store the hash, not the secret.

When your recipient enters the passphrase in their browser, it is sent to the relay over HTTPS. The relay extracts the salt from the stored hash, runs the same PBKDF2 derivation server-side, and compares the result using a constant-time equality check. If it matches, a presigned download URL is issued; otherwise a 403 is returned. The plaintext passphrase is never persisted — it exists in memory only for the duration of that check.

The demo below runs the exact same algorithm in your browser. Hit Hash it more than once with the same passphrase: each run produces a different result because the salt is regenerated every time, just like it is for each new send.