How to Share Files Without Storing Them in Cloud Storage

To share a file without storing it in cloud storage, use a direct peer-to-peer WebRTC transfer: the file streams straight from your browser to the recipient's, so it is never written to a server in the first place — nothing to store, and nothing for a breach to expose.

When you upload a file to a conventional cloud host to create a share link instead, several serious privacy risks emerge:

1. Indefinite Data Retention: Cloud providers retain copies of your files on remote hard drives, frequently long after you delete the share link.
2. Centralized Data Breaches: Server data centers are prime targets for cyberattacks, credential stuffing, and automated web scrapers.
3. AI Training & Content Scanning: Automated systems regularly scan hosted files for advertising keywords, indexing, or AI model training.
4. Forgotten Public Links: Shared cloud links left active indefinitely expose private corporate or personal data to unauthorized access.

Zero-cloud peer-to-peer transfer connects the sender's web browser directly to the recipient's web browser using WebRTC technology.

• Your web browser acts as an ephemeral live stream source.
• Data flows in encrypted packets directly to the recipient's device.
• As soon as the transfer finishes and the browser tab closes, the session ends and the keys in browser memory are gone, leaving no copy of your file anywhere on the internet. A non-content record that the transfer happened is kept on our side — see the limits section below.

Stream files directly from your device to the recipient with 0 bytes stored online.

1. On the device that will receive the file, open getfileshare.cloud/receive.
2. Share the room code it generates with the sender, who enters it at getfileshare.cloud/send.
3. Select your file and keep the browser tab open while your recipient downloads the streamed data directly.
4. Once completed, close the tab — the session ends and no copy of the file remains anywhere.

Every service in this category claims it does not store your files. You do not have to take ours on faith — a browser you already have can check the claim in about a minute.

Watch the network tab

Open your browser's developer tools (F12 on Windows, ⌥⌘I on a Mac) and select Network before you start a transfer. Then send a file and watch what leaves the machine.

On a direct transfer you will see the signalling messages that negotiate the connection. Those are small, and they do carry the file's name, size and type — the receiving side has to be told what it is being offered before it accepts. What you will not see is the file itself going anywhere: the bytes travel over the WebRTC data channel, which is not an HTTP request and never appears as an upload. A service quietly uploading your file cannot hide a multi-megabyte POST from that panel.

Compare the safety code

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.

Encryption alone cannot tell you who you encrypted for. Reading those 8 emoji aloud on a call — and hearing the same ones back — is what closes that gap.

Know what the check does not prove

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.

We would rather state that plainly than let you discover it later. The security page sets out the whole trust model, including what we can and cannot promise — or see the private file sharing checklist to run the same seven questions against any provider you're evaluating, this one included.

• Legal & Financial Documents: Tax forms, audit reports, contracts, and identity scans.
• Intellectual Property: Software source code, design prototypes, and confidential trade secrets.
• Sensitive Personal Media: Private family photos and personal records that should never exist on cloud servers.
• Regulated Handovers: Medical records, HR files, and anything covered by a retention policy that a third-party copy would violate.

For collecting sensitive files from someone rather than sending them, a file request does the same job in reverse.

Not storing the file removes an entire class of risk. It also removes the conveniences that storing it buys, and a guide that skipped this would be selling rather than explaining.

• Both devices must be online together. There is no copy sitting anywhere for the recipient to collect later, so the transfer happens while you are both present or not at all.
• The sending tab has to stay open. Your browser is the server for the duration. Locking your phone or switching apps mid-transfer can interrupt it.
• There is no re-download. If the recipient's disk fills or they close the tab early, the file has to be sent again. Nothing was retained to retry from.
• A restrictive network can force a relay. Some corporate firewalls and mobile carrier NATs make a direct connection impossible. 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.
• No delivery receipt in the interface. You see the transfer complete in your own tab, but there is no list of past direct transfers to look back at the way there is for cloud links.
• A 1 GB per-file ceiling applies to direct transfers, which is smaller than several cloud services' free tiers.

"No cloud storage" is a claim about your file, not about every record of the transfer. Your file contents are never written to our servers on the direct path. The transfer itself is logged: which room, when, how many files and their sizes, which transport was used, and the IP address and browser user-agent of each side. File names are the one thing dropped before that record is written, because the name is the piece most likely to describe what you sent. We keep the rest to run the service, enforce rate limits and investigate abuse, and it is on a deletion timer rather than kept forever: raw IP addresses and user agents are deleted after 30 days, and the record itself after 180. The privacy policy publishes the full schedule. If you need a transfer that leaves no server-side record at all, no browser-based service can honestly offer you one.

Direct transfer is the right default for confidential material. It is the wrong tool in these cases, and reaching for it anyway will just make sharing harder than it needs to be:

• The recipient is in another timezone. Waiting to be online simultaneously is worse for privacy in practice, because it pushes people toward emailing the file instead.
• Several people need the same file. One link that ten people fetch on their own schedule beats ten scheduled direct sessions.
• You need the file to outlive the conversation. A contract someone may need to re-download next week needs to exist somewhere next week.
• You are sending from a device you cannot babysit. A phone that sleeps, a laptop that shuts its lid — neither can hold a streaming session open.

The middle ground is a password-protected cloud link: the file is encrypted in your browser first, so what reaches storage is ciphertext under a key we never receive. You get the asynchronous convenience without handing over a readable copy. That path is described in the WeTransfer alternative guide, and the mode comparison lays both out side by side.