your files. your trust.
last updated: 22 August 2026.
most file-transfer tools work by taking a copy of your file first, holding it on their own servers, and handing it to you later. that copy is itself a target, a second place a file can leak or be lost from. toss-it doesn't do that: every upload streams straight from a sender's browser into the one Google Drive folder you connected, in bounded chunks, and toss-it never writes the file itself to disk at any point in between. there is no second copy sitting on our infrastructure to protect, because there isn't one.
how a file moves from a sender's browser into your storage.
senderadds files
toss-itencrypted transfer
your storagesecure delivery- passwords are hashed with scrypt (never stored or logged in plain text) and checked against the Have I Been Pwned breach database before we accept them, see privacy for exactly what that check does and doesn't send.
- every upload link's token is 256 random bits. we store only a one-way cryptographic hash of it, never the token itself, a used or expired link can't be reconstructed even by us.
- connecting Google Drive grants toss-it only the narrowest scope Google offers for this (
drive.file): per-file write access to what the app creates, never read access to your existing files or folders. - your Google credentials and any in-progress upload session are encrypted at rest (AES-256-GCM), never stored or transmitted in plain text.
- all traffic, from a sender's browser to our gateway and from our gateway to Google, runs over TLS.
every link you create is scoped tightly, and you stay in control of it after the fact:
- links expire automatically at a time you set.
- you can pause a link to stop new uploads temporarily without losing it, or revoke it permanently, both take effect immediately.
- size limits, file-count limits, and accepted file types are enforced per link.
- link creation is rate-limited to prevent automated abuse of a link you've shared.
toss-it does not scan uploaded files for malware. because files stream directly into your storage rather than landing in a holding area first, there is currently no point in the pipeline where a scan could run before delivery. treat files that arrive through a link the same way you would treat any file from a sender you can't fully vet, and see terms for how responsibility for received files is allocated.
every third party with any access to your data while operating toss-it, and exactly what they can see:
| subprocessor | purpose | what it can access |
|---|---|---|
| Google (OAuth + Drive API) | the destination storage you connect, and the identity used to sign in with Google. | only the one Drive folder you pick, via a per-file write grant, never your whole Drive. |
| Vercel | hosts the Next.js web app and its control-plane API routes. | encrypted metadata in transit to and from the app. never file contents. |
| Fly.io | hosts the dedicated transfer gateway that streams uploaded bytes to Google Drive. | the bytes of a file mid-transfer, streamed straight through, never written to disk. |
| Neon | managed PostgreSQL database for account and link metadata. | metadata only, names, sizes, timestamps, status. never file contents. |
| Resend | delivers account emails: verification and password-reset messages. | your email address and the message content, only when an email is actually sent. |
| Have I Been Pwned (via Cloudflare) | checks new passwords against known data breaches before we accept them. | the first five characters of a SHA-1 hash of your password, never the password, the full hash, or your email. |
if you find a security issue, email security@toss-it.online with what you found, the steps to reproduce it, and its potential impact. we don't run a paid bug-bounty program, but every report is read and acknowledged, please give us a reasonable window to fix an issue before disclosing it publicly.