Built for privacy.
Honest about the limits.
Understand how GetFileShare protects direct peer-to-peer transfers and optional password-locked cloud files before upload.
Cryptographic Foundations
RSA-2048 + AES-256-GCM
The receiving browser generates a per-session RSA-2048 (RSA-OAEP, SHA-256) key pair. The sender wraps a random 256-bit AES key with that public key, then encrypts every chunk with AES-256-GCM before it leaves the device. All via the Web Crypto API.
Safety code Confirmation
Both devices display a fingerprint of the public key each is actually using, as 8 emoji and 12 hex characters. Comparing them rules out a substituted key — the one attack encryption alone cannot prevent.
Argon2id Key Derivation
Separate from E2E transfer: for password-protected cloud uploads, your passphrase becomes a 256-bit key in the browser via Argon2id. The password and key never leave your device.
Security Model Breakdown
Direct E2E Security
Encrypted in the browser, device to device where possible
- The receiving browser generates a per-session RSA-2048 (RSA-OAEP, SHA-256) key pair. The sender wraps a random 256-bit AES key with that public key, then encrypts every chunk with AES-256-GCM before it leaves the device.
- The private key is generated inside the receiving browser, is non-extractable, and is destroyed when the tab closes. It is never transmitted.
- Larger transfers travel over a WebRTC data channel, which adds DTLS transport encryption on top. Additional transport encryption on top of the AES-GCM layer, not a substitute for it.
- Chunks are relayed through our server when a direct connection is impossible, and for small transfers where negotiating one would take longer than sending the file — still as ciphertext we hold no key for. The relay is a bridge, not a reader.
- Some peer connections cannot find a direct route and are relayed by our TURN server instead. It forwards packets that are already encrypted twice over — your AES-GCM ciphertext inside the connection's own DTLS — and holds no key for either layer.
- Each chunk carries a GCM authentication tag with its sequence number authenticated alongside it, and a SHA-256 hash of the whole file is verified on arrival.
Client-Side Cloud Security
Zero-knowledge when you set a password
- Password protection is optional, and it is what makes a cloud upload zero-knowledge: with it on, file contents are encrypted in your browser with AES-256-GCM before the upload starts.
- For password-protected cloud uploads, your passphrase becomes a 256-bit key in the browser via Argon2id. The password and key never leave your device.
- Files go to S3-compatible object storage, which encrypts them at rest. Without a password that encryption is ours, so we could open the file; with one, what we store is ciphertext we have no key for.
- We never store or log your password.
- Zero-knowledge describes the file's contents, not the transfer. The server still reads and stores the surrounding record — file size and type, the file name on cloud uploads, who uploaded it and when, and the IP address and browser of each side — and keeps it for the periods published in the privacy policy, not indefinitely.
Infrastructure & Application Security
Good cryptography doesn't help if the server around it is misconfigured. Here's what protects the platform itself:
- All traffic to the platform is encrypted in transit via TLS.
- A strict Content Security Policy restricts what the page may load and where it may send data: scripts must be our own files served from this domain — inline scripts and eval are refused outright — and every other origin the page may contact is named explicitly. Standard hardening headers accompany it (HSTS, nosniff, a deny on framing, and a permissions policy that switches off everything but the camera the QR scanner needs).
- Cloud-stored files sit in encrypted-at-rest object storage, kept separate from our metadata database.
- API endpoints are rate-limited to deter automated abuse, and repeated failed attempts to join a transfer room are throttled per IP address.
- Cross-origin requests are restricted to our own web client — the API does not accept arbitrary cross-site requests.
- Every request is server-side validated against a strict schema; unexpected fields are rejected before they reach business logic.
- Your file content, file metadata, and IP address are never used for advertising and never used to train machine learning or AI models. No file content or file metadata ever reaches a third-party analytics service; the only such service is the optional, consent-based site analytics described in our Privacy Policy, which sees page paths with share links and file names stripped out.
- Some pages may show a sponsor banner. Those are static images served from this domain — no ad network, no ad script, no cookie or tracking pixel — so nothing about you or your file is shared with an advertiser and what is shown is the same for every visitor.
What this does and does not prove
The system is designed so that our servers never hold a key that could decrypt your files. On a direct peer connection the file data never reaches us at all. When one cannot be established — or the transfer is too small to be worth negotiating one — it passes through our relay, and a peer connection that cannot find a direct route is carried by our TURN server. In every one of those cases what we handle is ciphertext we hold no key for.
That holds as long as the code running in your browser is the code we describe. For the encryption itself you no longer have to take that on trust: it is served as a published build you can reproduce byte for byte and compare against what your browser loaded. What remains is the application around it, which is closed source — it is what hands your file and your password to that code, and nothing here proves it does not read them first.
Three things are checkable without trusting us: rebuild the published encryption yourself and compare its hash with the file your browser loaded; compare the safety code with the other device, which rules out a substituted key; and watch the network traffic in your browser's developer tools, which also tells you which path a given transfer actually took — a relayed transfer shows ciphertext frames on the WebSocket, and a direct one shows no file data leaving for our servers at all.
The algorithm names and key sizes on this page aren't hand-typed marketing copy — the direct-transfer encryption code reads its parameters from the same file this page quotes, and an automated build check fails the build if any page states a crypto claim of its own instead of importing it from there.
Transport stack for direct transfers: WebRTC data channel → SCTP → DTLS. DTLS secures the connection; SCTP carries the data channel. The safety code and the browser-side encryption above it are what make the transfer end-to-end.
Check it yourself, without trusting us
We have not had an independent security audit — we are new, and we would rather say so than imply otherwise. What we can do is publish the part that is checkable: the client-side encryption source, a set of test vectors, and a standalone Python decryptor that talks to nothing.
For a password-protected upload of your own, open My account → Uploads and choose Encrypted copy. That saves the object exactly as our storage holds it, plus a small metadata file. Open the .enc file in a hex editor to see that it is noise, then decrypt it offline with your password using argon2-cffi and pyca/cryptography — libraries with no connection to us. The test vectors are generated from the same module your browser runs, so they reflect the implementation rather than a description of it.
What that proves, precisely: the objects we store are ciphertext, and only your password opens them. On its own it says nothing about the browser code that did the encrypting — which is what the verifiable build below is for. Together they cover both halves: that the stored file is genuinely encrypted, and that the code which encrypted it is the code we published.
The crypto source, vectors and decryptor →Verifiable build
The encryption is not compiled into this site. Your browser fetches it as one published file, built from public source by a build anyone can repeat byte for byte — so you can check that the code encrypting your file is the code we published, rather than taking our word for it.
- Open your browser's developer tools, reload, and find the crypto file it fetched. It is not minified — you can read it.
- Hash that file.
- Clone the public repository, run the build, and hash what it produces.
- The two digests match, or something is wrong and you should not trust this site.
The build pins its compiler and its dependencies to exact versions, emits no timestamps and does not minify, so two builds of the same source produce identical bytes on any machine. Without that, a published hash would mean nothing — it could never be reproduced to contradict.
What it does not cover. This proves the encryption is the published code. It does not prove the closed-source page around it hands your file and password to that code untouched — which is now the sharpest limit left, and the honest thing to say beside the claim.
v1.2.0 · SHA-256Read further
- How end-to-end encryption works in a file transfer — the protocol explained without the jargon.
- Share files without cloud storage — including how to verify in your own browser that nothing was uploaded.
- Password-protect a file before sharing it — what the client-side password does and does not cover.
- How the three sharing modes differ — direct, cloud, and file requests compared.
- Infrastructure — where the servers are and what runs on them.
Security Questions, Answered Plainly
The system is designed so that our servers never hold a key that could decrypt your files. On a direct peer connection the file data never reaches us at all. When one cannot be established — or the transfer is too small to be worth negotiating one — it passes through our relay, and a peer connection that cannot find a direct route is carried by our TURN server. In every one of those cases what we handle is ciphertext we hold no key for. That holds as long as the code running in your browser is the code we describe. For the encryption itself you no longer have to take that on trust: it is served as a published build you can reproduce byte for byte and compare against what your browser loaded. What remains is the application around it, which is closed source — it is what hands your file and your password to that code, and nothing here proves it does not read them first.
The receiving browser generates a per-session RSA-2048 (RSA-OAEP, SHA-256) key pair. The sender wraps a random 256-bit AES key with that public key, then encrypts every chunk with AES-256-GCM before it leaves the device. For password-protected cloud uploads, your passphrase becomes a 256-bit key in the browser via Argon2id. The password and key never leave your device.
Both devices display a fingerprint of the public key each is actually using, as 8 emoji and 12 hex characters. Comparing them rules out a substituted key — the one attack encryption alone cannot prevent.
Yes, and the guarantee comes from the browser-side encryption layer rather than the network transport. Larger transfers travel over a WebRTC data channel, which adds DTLS transport encryption on top. Additional transport encryption on top of the AES-GCM layer, not a substitute for it.
There is no readable file content to take. On a direct peer connection the file never reaches our servers at all; on the relay and TURN paths it passes through as ciphertext without being written to disk. For password-protected cloud uploads, storage holds ciphertext encrypted under a key derived in your browser from a passphrase we never receive, so a copy of that storage yields nothing readable. What a breach would expose is the metadata we do keep — transfer times, file sizes and types, cloud file names, and the IP addresses, user agents and approximate location (country) of each side, within the retention windows in the privacy policy.
Three things are checkable without trusting us: rebuild the published encryption yourself and compare its hash with the file your browser loaded; compare the safety code with the other device, which rules out a substituted key; and watch the network traffic in your browser's developer tools, which also tells you which path a given transfer actually took — a relayed transfer shows ciphertext frames on the WebSocket, and a direct one shows no file data leaving for our servers at all.
File content is never logged, but non-content metadata about the transfer is: sizes and types, timestamps, which transport carried it (direct, our TURN server, or our relay), connection diagnostics such as setup time, round-trip time, an estimated connection speed and re-sent chunks, and the IP address, browser user-agent and approximate location (country) of each side. Direct transfers are the exception on one field — the file name is dropped before the record is written, because it is the piece most likely to describe what you sent. Cloud shares keep the name, since serving the share requires it. None of this is kept indefinitely: raw IP addresses, user agents and device identifiers are deleted after 30 days, and the transfer records themselves after 180 days. We keep it for rate limiting, abuse prevention and security investigations. It is never sold, never used for advertising, and never used to train AI models. The privacy policy sets out the full list and the full retention schedule.
The file becomes permanently unrecoverable. A reset would require us to hold something that opens your file, and we deliberately do not hold it. Keep the passphrase somewhere you trust before you share the link.