Privacy & How It Works

1. Files are temporary by default

Every file you upload is automatically deleted 30 minutes after upload, regardless of whether anyone has viewed or downloaded it. This is not a setting you can disable — it's a hard limit enforced on our storage layer.

• The 30-minute timer starts the moment the upload finishes, not when someone opens the link.
• Once expired, the file's bytes are permanently deleted from storage — this is not reversible, and we cannot recover expired files for anyone, including the uploader.
• The link itself will simply show "File not found" after expiry — the metadata is deleted alongside the file.

2. Delete-after-first-download

If the uploader enables "delete after download", the file is deleted as soon as it's viewed or downloaded for the first time — even if that's seconds after upload, well before the 30-minute window ends.

In practice, this means a one-time-download link can only ever be opened successfully by one person, one time. If you send the link to multiple people, only whoever opens it first will get the file — everyone else will see an expired/not-found response.

3. Password protection

You can optionally protect a file with a password at upload time. Here's exactly what that does and doesn't do:

What we store

We never store your password in plain text. When you set a password, it's immediately hashed using SHA-256 combined with the file's unique object ID before it ever touches our database. Only this hash is stored — the original password is discarded and never written to disk.

How verification works

• Metadata (filename, size, upload date) is always visible without a password — only the file's actual content is gated.
• To view or download a protected file, the password is sent along with the request and hashed again on our server; the two hashes are compared, and content is only released on a match.
• We use a constant-time comparison when checking password hashes, which prevents timing-based attacks that try to guess a password one character at a time.
• Incorrect passwords return a generic 401 error with no hints about which part of the password was wrong.

What password protection doesn't do

A password does not extend the file's lifetime — the 30-minute expiry (and delete-after-download, if enabled) still applies on top of the password requirement. A password only adds an extra check before content is served; it doesn't change when the file is deleted.

4. Where files are stored

Files are stored in a private object storage bucket that is not publicly accessible on its own. All access goes through our server, which checks expiry and password requirements before returning any file content directly — there is no public URL that bypasses these checks.

• No third party has direct access to the storage bucket.
• No CDN or intermediate cache stores a persistent copy of your file.
• Metadata (filename, size, content type, expiry, whether a password is set) is stored separately from the file content itself, in a small database used only to enforce these rules.

5. What we don't do

• We don't scan, analyze, or read the contents of uploaded files.
• We don't use uploaded files for analytics, training, or any purpose beyond serving them back to whoever has the link.
• We don't require an account, email, or any personal information to upload or download a file.
• We don't log passwords anywhere — not in application logs, error messages, or analytics.

6. What you're responsible for

Because links have no login requirement, anyone with the link and password (if set) can access the file within the time limit. Treat the link itself as sensitive — sharing it is equivalent to sharing the file.

• Only share links over channels you trust.
• If a file is sensitive, use password protection and share the password separately from the link (e.g. a different app or in person).
• Once a link is opened by the wrong person, we have no way to revoke access retroactively — the file is served the moment the checks pass.