Confidential File Sharing — Send Files Without Being Tracked
— Brendan Gray, Founder & Developer
When you upload a file to most sharing services, the service reads it. That's not an assumption — it's in the terms of service. This guide explains what file sharing services actually know about you and your files, and which privacy model genuinely protects what you send.
Share files privately — zero-knowledge encrypted, no account required
Try FileShot.io Free →File encrypted in browser before upload. Server never receives the key.
What File Sharing Services Know About You
Every file sharing service collects some information. Here's what's typically collected:
Always collected (standard for any web server)
- IP address — your internet address at the time of upload
- Timestamp — when the upload occurred
- User agent — your browser and OS version
- Request size — how large the upload was
Collected by most services (even "free" ones)
- Filename — the original name of your uploaded file
- MIME type / content type — what kind of file it is (image, document, video...)
- File content — if stored unencrypted, the service can read what's in the file
- Email address — if you signed up for an account
- Download events — who accessed the link, when, and from where
What FileShot collects
FileShot stores:
- IP address and timestamp (standard server logs)
- File size and MIME type of the ciphertext blob
- File ID
FileShot does not store:
- The original filename (encrypted client-side as part of the ciphertext)
- The file contents (encrypted before upload using AES-256-GCM in the browser)
- The decryption key (never transmitted to the server — lives in the URL fragment only)
- Your identity (no account required)
What "Zero-Knowledge" Actually Means
Zero-knowledge in file sharing means the service provider has zero knowledge of the file's contents. This is achieved by encrypting the file before it ever leaves the browser:
- Your browser generates a random 256-bit encryption key
- Your file is encrypted using AES-256-GCM with that key — in your browser, before any network request
- The resulting ciphertext (looks like random bytes) is uploaded to FileShot's servers
- The decryption key is embedded in the URL fragment (the part after
#) - The recipient's browser receives the URL, extracts the key from the fragment, and decrypts the file locally
The critical step is #4. The HTTP specification defines that URL fragments are never sent to the server. When a browser requests https://fileshot.io/d/abc123#key=XYZ, the server only sees /d/abc123 — the #key=XYZ portion stays in the browser entirely.
This architectural choice means FileShot's servers are technically incapable of decrypting any file, regardless of legal compulsion, data breach, or rogue employee. There's nothing to hand over — only ciphertext.
Comparing Privacy Models
| Service | Encryption Type | Can Provider Read Files? | Account Required? |
|---|---|---|---|
| Google Drive | Encrypted at rest (Google holds keys) | Yes | Yes |
| Dropbox | Encrypted at rest (Dropbox holds keys) | Yes | Yes |
| WeTransfer | TLS in transit only | Yes | Optional |
| OneDrive | Encrypted at rest (Microsoft holds keys) | Yes | Yes |
| FileShot.io | Zero-knowledge (AES-256-GCM, key never on server) | No — technically impossible | No |
What "Encrypted at Rest" Doesn't Mean
When Google or Dropbox say files are "encrypted at rest," they mean the hard drive storing your file uses encryption. But Google or Dropbox hold the encryption keys — they can decrypt your files at any time for:
- Content moderation and scanning for policy violations
- Government subpoenas and legal orders
- Internal employees with sufficient access
- Potential data breaches where key management is also compromised
"Encrypted at rest" in this context means protection against a burglar stealing a hard drive — not protection against the service provider. Zero-knowledge encryption protects against all of the above.
Practical Privacy Steps for File Sharing
1. Remove metadata before sharing
Images contain GPS coordinates, device serial numbers, and timestamps in EXIF metadata. Documents contain author names, revision history, and tracked changes in properties metadata. Use FileShot's Metadata Scrubber to strip this before uploading — even a zero-knowledge upload exposes metadata if it's embedded in the file.
2. Set link expiry
FileShot's upload interface lets you set a link expiry (1 download, 1 hour, 24 hours, 7 days). An expiring link that's accidentally sent to the wrong person is far less dangerous than a permanent one. Once expired, not even the server can serve the file — and the ciphertext is deleted.
3. Use a VPN or Tor for IP masking
FileShot doesn't know your identity, but it does see your IP address (as every web server does). If IP-level anonymity matters to your use case, use a VPN before uploading. This masks your real IP from FileShot's access logs.
4. Share the link only via encrypted channels
A zero-knowledge file link is only as private as how you share it. If you send it via unencrypted email, your email provider can see the URL. Use end-to-end encrypted messaging (Signal, iMessage, WhatsApp) to share download links.
FileShot's Full Product Suite for Private Communication
- File Sharing — zero-knowledge encrypted, 10 GB free, no account
- Encrypted Chat — end-to-end encrypted real-time messaging
- P2P Transfer — direct browser-to-browser, no server storage
- Secure Paste — zero-knowledge encrypted text snippets
- Metadata Scrubber — remove EXIF/document metadata before sharing
Private File Sharing — Zero-Knowledge, No Account
AES-256-GCM encrypted in your browser. Server receives only ciphertext.
Share a File Privately →