Secure file sharing, private by default
A share link is a key to your file, so it should behave like one: impossible to guess, useless once revoked, and gone when its job is done. Here is exactly how uploadtol.ink keeps shared files private — stated plainly, including what it doesn't do.
Unguessable links, hashed at rest
- Every download link is a token of 32 cryptographically random bytes — 256 bits, a 43-character code. Guessing one is not a practical attack.
- The server stores only a SHA-256 hash of each token. Even someone with a copy of the database could not reconstruct working links.
- Files are never listable or browsable. There is no public index, no directory, no "recent uploads" — the only way to a file is a link its owner created.
Links you can constrain — and kill
- Expiry: each link lives 1 to 720 hours, never longer than the file itself. How expiring links work →
- Download caps: set a maximum download count and it is enforced atomically — simultaneous requests can't sneak past the limit.
- Kill switch: deleting the file immediately stops every link to it.
Out of search engines, by design
Links get pasted into chats, issues and forums that crawlers read. Every
download response therefore carries an X-Robots-Tag: noindex
header — the authoritative signal that keeps a URL out of search results
even when it's linked publicly — and the download namespace is excluded in
robots.txt. Your shared file does not become a search result.
Downloads that can't run in your browser
Files are always served as attachment downloads, never rendered inline. A shared HTML or script file downloads like any other file instead of executing on our domain — closing off the classic trick of using a file host to serve malicious pages.
Account and payment security
- Passwords are hashed with PBKDF2-SHA-256 at 600,000 iterations — they are never stored or logged in plain text.
- Sessions use short-lived access tokens with rotating refresh tokens; if a stolen refresh token is ever replayed, the whole session family is revoked automatically.
- Payments run through Stripe Checkout — card numbers never touch our servers.
- Files are encrypted in transit (TLS) and at rest in storage, and public endpoints are rate-limited per IP.
What it is not: end-to-end encrypted. If nobody but the recipient may ever be able to read the file, encrypt it yourself before uploading (e.g. with age or 7-Zip AES) — an encrypted file uploads, shares and expires exactly like any other.
Frequently asked questions
Can someone guess a download link?
Not realistically. Each link token is 32 bytes (256 bits) from a cryptographic random generator — a 43-character code with more possible values than there are atoms guessed per second could ever cover. The server also stores only a SHA-256 hash of the token, so even a database leak would not expose working links.
Do shared links show up in search engines?
No. Every download response carries an X-Robots-Tag: noindex header — the authoritative opt-out search engines honor even for links posted publicly — and robots.txt excludes the download namespace from crawling.
Do recipients need an account?
No. Recipients just open the link and the file downloads. They never need an account, never pay, and never see anything except the file you shared.
Is it end-to-end encrypted?
No — files are encrypted in transit (TLS) and at rest in storage, but the service is not end-to-end encrypted. If your threat model requires that nobody but the recipient can ever read the file, encrypt it yourself before uploading (for example with age or 7-Zip AES); an encrypted file uploads, shares and expires exactly like any other.