How to Send Large Files Online Without Cloud Storage: A Deep Dive Into Browser-to-Browser File Transfer
Sending a small PDF to someone is easy.
Sending a 20GB video project, a folder full of RAW photos, a large ZIP archive, or hundreds of gigabytes of footage is a completely different problem.
Most file-sharing services follow the same basic model:
Your device → cloud server → recipient's device
You upload the file first. The service stores it somewhere. Then the other person downloads another copy.
That model works well, but it comes with trade-offs.
You may run into file-size limits. Uploading can take a long time. The recipient still has to wait for the upload to finish. Files may remain stored on third-party infrastructure. Some services require accounts. Others limit how many gigabytes you can transfer every month unless you pay.
But browsers are capable of something much more interesting.
Instead of uploading a file to a storage server first, two browsers can establish a connection and transfer data directly between devices.
That changes the architecture to something closer to:
Your device → recipient's device
This is the idea behind peer-to-peer browser file sharing.
I became interested in this problem while building ButterShare, a browser-based file-sharing tool designed around direct device-to-device transfers instead of traditional cloud storage. Visit https://buttershare.com/.
In this article, I want to explain how this kind of file transfer works, why WebRTC makes it possible, where the technical challenges are, when peer-to-peer file sharing makes sense, and where traditional cloud storage is still the better solution.
The Problem With Traditional Large File Transfers
Before looking at WebRTC, it helps to understand what usually happens when you send a file using a conventional cloud file-sharing service.
Imagine you need to send a 40GB video project to another person.
With a cloud-based service, the process normally looks something like this:
Sender
|
| Upload 40GB
v
Cloud Storage
|
| Download 40GB
v
Recipient
The file travels across the internet twice.
First:
Sender → Server
Then:
Server → Recipient
From the user's perspective, this creates an awkward workflow.
If your upload speed is slow, your recipient may wait a long time before being able to download anything.
For example, assume you have:
100 Mbps download
20 Mbps upload
A large upload is constrained primarily by that 20 Mbps upload connection.
A 40GB project can therefore take a significant amount of time to reach the server before the recipient even begins downloading it.
For occasional transfers this may be fine.
For video editors, photographers, developers, designers, filmmakers, students, or teams working with large datasets, it becomes much more noticeable.
Why File Size Limits Exist
People sometimes assume file-sharing companies add file limits simply because they want users to upgrade.
There is obviously a business component, but there is also a very real infrastructure cost.
If a cloud file-transfer provider stores a 100GB file, it needs infrastructure for:
100GB of temporary storage
Upload bandwidth
Download bandwidth
Database records
File metadata
Malware scanning
CDN or egress traffic
Redundancy
Cleanup processes
Download links
Expiration jobs
Access controls
Monitoring
Abuse prevention
Now multiply that by thousands or millions of transfers.
Suddenly "send a file" becomes a substantial storage and infrastructure problem.
This is one reason peer-to-peer architecture is so interesting.
If the server never has to permanently store the file, a large part of the traditional file-transfer infrastructure disappears.
What Is Peer-to-Peer File Sharing?
Peer-to-peer, usually shortened to P2P, means devices communicate with each other rather than relying entirely on a central server to move the actual content.
A simplified P2P transfer looks like this:
Device A
|
|
| Direct data connection
|
v
Device B
A server may still be involved in helping the devices discover and connect to each other.
But once the connection has been established, the file data can travel between the peers rather than being uploaded to permanent cloud storage first.
This distinction is important.
Peer-to-peer does not necessarily mean "there are absolutely no servers anywhere."
Servers can still handle things such as:
Signaling
Session creation
Connection negotiation
Authentication
Analytics
Rate limiting
STUN
TURN fallback
Metadata
What matters is whether the actual file must be stored on a central server before it can reach the recipient.
WebRTC Makes Browser-to-Browser File Transfer Possible
Most developers know WebRTC because of video calls.
Products like browser-based meeting applications use WebRTC to transmit:
Audio
Video
Real-time data
But WebRTC can also create something called a DataChannel.
A WebRTC DataChannel allows browsers to exchange arbitrary binary data.
That means you can transfer:
Images
PDFs
Videos
ZIP archives
Audio
Documents
Project files
Binary blobs
Practically any file type
The browser already has most of the networking capabilities required.
No native desktop application is necessarily required.
A Simplified WebRTC File Transfer
The high-level architecture might look like this:
Signaling Server
/ \
/ \
/ \
v v
Browser A <----> Browser B
WebRTC
DataChannel
The signaling server helps Browser A and Browser B establish communication.
After negotiation completes, a DataChannel can be opened.
Conceptually:
const channel = peerConnection.createDataChannel("file-transfer");
Then binary data can be sent:
channel.send(chunk);
Of course, production file transfer is considerably more complicated than those two lines.
But those lines demonstrate the core idea.
The browser can transmit arbitrary data through the connection.
Step 1: The Sender Selects a File
A user might choose a file through a normal browser file input:
<input type="file" id="fileInput" />
JavaScript receives a File object:
const input = document.querySelector("#fileInput");
input.addEventListener("change", () => {
const file = input.files[0];
console.log(file.name);
console.log(file.size);
console.log(file.type);
});
A browser does not necessarily need to upload that file to your server.
JavaScript can read pieces of the local file and send them through a WebRTC DataChannel.
That is the foundation of browser-based P2P file transfer.
Step 2: Create a Transfer Session
The sender needs some way to tell the recipient:
Connect to this transfer.
There are several ways to represent the session.
For example:
https://example.com/receive/random-session-id
Or a QR code containing that URL.
The session identifier should not itself contain the file.
It simply identifies the connection session.
The sender might receive something like:
Session ID:
6bd194d7-2cb9-45e2-91f9...
The application can turn that session into a shareable URL.
This is the direction I ultimately preferred for ButterShare because sending a URL or scanning a QR code is more natural than manually typing connection codes. A ButterShare receiving link looks like https://buttershare.com/receive?code=YG45F3.
Step 3: Signaling
Here is where WebRTC gets slightly more complicated.
Two browsers cannot magically know how to reach each other.
They first need to exchange connection information.
This process is called signaling.
WebRTC itself does not mandate one signaling protocol.
Developers commonly implement signaling using:
WebSockets
Socket.IO
Server-Sent Events combined with HTTP
Firebase
Supabase Realtime
Custom WebSocket servers
The signaling channel exchanges information such as:
Offer
Answer
ICE candidates
A simplified sequence looks like this:
Browser A
|
| Create offer
|
v
Signaling Server
|
| Forward offer
|
v
Browser B
Browser B
|
| Create answer
|
v
Signaling Server
|
| Forward answer
|
v
Browser A
The signaling server coordinates the introduction.
It does not necessarily need to receive the file itself.
Step 4: ICE, STUN and NAT Traversal
This is one of the most important parts of WebRTC.
Most computers are not directly exposed to the internet.
They are behind:
Routers
NAT
Corporate networks
Mobile networks
Firewalls
Suppose your laptop has a private IP address such as:
192.168.1.20
That address only makes sense inside your local network.
Someone elsewhere on the internet cannot simply connect to it.
WebRTC uses a system called ICE — Interactive Connectivity Establishment to determine how two peers can communicate.
STUN servers help a device understand its public-facing network information.
Conceptually:
Browser
|
| "How does the internet see me?"
|
v
STUN Server
The STUN server provides information that can help peers attempt a direct connection.
What Happens When Direct P2P Is Impossible?
This is where discussions about "direct file transfer" often become oversimplified.
Sometimes two devices cannot establish a direct connection because of their network configurations.
Examples include:
Strict corporate firewalls
Symmetric NAT
Restricted Wi-Fi networks
Certain mobile carrier networks
WebRTC deployments can use a TURN server as a fallback.
Instead of:
Device A ------------ Device B
the traffic may become:
Device A
|
v
TURN Relay
|
v
Device B
The TURN server relays the traffic.
That still differs from traditional cloud storage because the relay does not necessarily persist the entire file as an uploaded object waiting for later download.
But it does mean that "100% direct P2P in every possible network environment" is not realistic for many WebRTC applications.
Good P2P systems should handle this transparently.
Step 5: Establish the DataChannel
Once WebRTC negotiation succeeds, the sender and receiver can communicate over a DataChannel.
Example:
const peer = new RTCPeerConnection();
const dataChannel = peer.createDataChannel("files");
dataChannel.binaryType = "arraybuffer";
dataChannel.onopen = () => {
console.log("Peer connection established");
};
On the receiving side:
peer.ondatachannel = (event) => {
const channel = event.channel;
channel.binaryType = "arraybuffer";
channel.onmessage = (event) => {
console.log("Received data", event.data);
};
};
At this point, the application effectively has a pipe between the two browsers.
Now we have to move the file through it.
Why You Should Not Send a Huge File at Once
Suppose the sender selects a 30GB file.
Obviously, this would be a terrible idea:
channel.send(entireThirtyGigabyteFile);
Instead, the file should be broken into chunks.
Conceptually:
30GB File
[chunk]
[chunk]
[chunk]
[chunk]
[chunk]
[chunk]
...
Each chunk might be something like:
64 KB
256 KB
1 MB
The exact chunk size depends on implementation and performance characteristics.
The sender can read chunks sequentially:
const CHUNK_SIZE = 256 * 1024;
let offset = 0;
while (offset < file.size) {
const chunk = file.slice(offset, offset + CHUNK_SIZE);
const buffer = await chunk.arrayBuffer();
dataChannel.send(buffer);
offset += CHUNK_SIZE;
}
This is only a simplified example.
A production implementation must also consider buffering and flow control.
Backpressure Matters
Network connections do not consume data infinitely fast.
If JavaScript pushes chunks faster than the browser can transmit them, the DataChannel's internal buffer grows.
WebRTC exposes:
dataChannel.bufferedAmount
which tells you approximately how much data is waiting to be transmitted.
A safer transfer system can pause when the buffer becomes too large.
Conceptually:
if (dataChannel.bufferedAmount > MAX_BUFFER_SIZE) {
await waitForBufferToDrain();
}
You can also configure:
dataChannel.bufferedAmountLowThreshold
and listen for:
bufferedamountlow
This allows the sender to resume after the browser has transmitted enough queued data.
Without proper backpressure handling, large transfers can consume excessive memory or become unstable.
Receiving the File
On the receiving browser, chunks arrive sequentially.
The application tracks progress:
Received: 1.4GB
Total: 10GB
Progress: 14%
For smaller files, chunks can potentially be assembled into a Blob:
const blob = new Blob(chunks);
and downloaded:
const url = URL.createObjectURL(blob);
const anchor = document.createElement("a");
anchor.href = url;
anchor.download = fileName;
anchor.click();
But this approach requires careful consideration for extremely large files.
Holding massive files entirely in memory is obviously undesirable.
Large-file browser applications may instead explore streaming techniques or browser file-system capabilities where available.
This is one of the engineering differences between a demonstration WebRTC file-transfer project and something designed to transfer very large files reliably.
Why P2P Can Remove Platform File-Size Caps
This is where peer-to-peer architecture becomes particularly powerful.
Traditional file-transfer infrastructure often behaves roughly like this:
User uploads 100GB
↓
Provider stores 100GB
↓
Provider serves 100GB
↓
Provider deletes 100GB later
The provider must handle storage proportional to the amount of data users send.
With direct P2P transfer:
Sender has 100GB
↓
DataChannel
↓
Receiver gets 100GB
The transfer provider does not necessarily need to allocate 100GB of cloud object storage.
That fundamentally changes the economics.
It becomes possible to design a service with no arbitrary platform-imposed file-size limit for direct transfers.
There are still real-world limits.
Transfer performance depends on factors such as:
Sender upload speed
Recipient download speed
Browser behavior
Available memory
Disk speed
Wi-Fi stability
Network restrictions
Whether relay infrastructure is required
How long both devices remain connected
So "no file-size limit" should not be interpreted as:
A browser can teleport infinite data instantly.
It means the platform does not need to impose a conventional storage quota such as 2GB, 5GB, or 10GB simply because the file must first fit into its cloud storage system.
The Sender Must Stay Online
P2P architecture also introduces an important trade-off.
Consider cloud sharing.
You upload a file tonight.
Then you turn your computer off.
Your friend downloads it tomorrow.
That works because the cloud server has a copy.
With a purely live P2P transfer:
Sender online + Receiver online
=
Transfer works
If the sender disconnects, there is no cloud copy waiting for the receiver.
This means P2P transfer and cloud sharing solve slightly different problems.
P2P is excellent for:
"I want to send this file to you now."
Cloud storage is excellent for:
"I want this file to remain downloadable later."
This distinction eventually becomes very useful when designing premium features.
A product can offer both experiences without pretending they are the same thing.
Privacy Benefits of Browser-to-Browser File Sharing
Traditional cloud file sharing creates another copy of your file.
Now there may be copies on:
Your computer
Cloud infrastructure
Recipient's computer
Depending on the provider, there may also be:
Replicated storage
Backups
Temporary processing files
Caches
Malware scanning pipelines
That is not automatically unsafe. Major cloud providers invest heavily in security.
But some users simply do not want another company storing their files.
P2P provides another option.
If the file can travel between devices without being permanently stored by the transfer service, the service holds less user data.
That reduces the amount of infrastructure that needs to retain the user's content.
WebRTC Transport Is Encrypted
WebRTC was designed with encrypted communication as a core part of the protocol stack.
For DataChannels, traffic is protected during transport rather than being sent as plain binary data over the internet.
That makes WebRTC suitable for privacy-focused communication.
However, security still depends on the entire implementation.
A secure file-transfer service must also think about:
Secure session IDs
HTTPS
Secure signaling
Session expiration
Unauthorized session access
Metadata exposure
Cross-site scripting
Replay attempts
Rate limiting
Abuse prevention
Encryption alone does not automatically make an application secure.
Security is a system property.
No Account Is Technically Required
Another interesting consequence of temporary P2P sessions is that a user account is not necessarily required.
Traditional cloud storage often needs accounts because the service must associate stored objects with users.
For example:
User
↓
Storage quota
↓
Stored files
↓
Download links
↓
Expiration
A temporary P2P transfer can be much simpler:
Temporary session
↓
Two browsers connect
↓
Transfer
↓
Session disappears
This creates a very lightweight user experience.
The sender can:
Select files.
Get a link.
Share the link.
Let the recipient connect.
Transfer the files.
No signup screen is inherently necessary.
Cross-Platform File Transfer Is Another Big Advantage
One surprisingly annoying problem is transferring files between ecosystems.
For example:
Windows → iPhone
Android → Mac
Mac → Windows
Linux → Android
Native ecosystem tools can be excellent when both devices belong to the same ecosystem.
The problem begins when they do not.
The web gives us something almost every modern device already has:
a browser.
Instead of requiring:
Install desktop client
Install phone app
Create account
Verify email
Sign in
Pair device
a browser-based workflow can potentially be:
Open link
Connect
Receive file
That is one of the reasons I find browser-based file transfer interesting.
The browser becomes the compatibility layer.
QR Codes Make Cross-Device Transfer Even Easier
Suppose a file exists on your laptop and you want it on your phone.
Typing a long URL is annoying.
QR codes solve that nicely.
The sender creates a session:
https://buttershare.com/receive/session
The application turns the link into a QR code.
The phone scans it.
Now the two devices can begin establishing the transfer connection.
This creates a workflow like:
Laptop
↓
Choose file
↓
QR code appears
↓
Phone scans
↓
Devices connect
↓
Transfer begins
No account synchronization is necessary.
Why I Built ButterShare Around This Model
I wanted file sharing to feel less like uploading something to a storage service and more like handing a file directly to another device.
That became the idea behind ButterShare.
The core workflow is intentionally simple:
Select files
↓
Get a share link / QR
↓
Recipient opens it
↓
Transfer begins
The goal is to remove as much friction as possible from live file transfers.
For the direct-transfer experience, ButterShare is built around a few ideas:
Browser-based file sharing
Peer-to-peer transfer
No account required for basic transfers
No permanent cloud storage for the direct transfer itself
Cross-platform usage
Shareable links
QR-based device transfer
Privacy-focused architecture
No arbitrary platform file-size cap for direct transfers
The bigger idea is not simply "another WeTransfer alternative."
It is a different transfer model.
Traditional services often optimize:
Upload now → Download later
P2P tools optimize:
Send now → Receive now
Both are useful.
They just solve different problems.
Practical Example: Sending a 50GB Video Project
Imagine you are a video editor.
You finish a project containing:
Project folder: 50GB
You need to send it to another editor.
A traditional cloud workflow might be:
1. Compress project
2. Upload 50GB
3. Wait
4. Generate link
5. Send link
6. Recipient downloads 50GB
7. Provider deletes it eventually
A live P2P workflow can be:
1. Select project
2. Generate connection link
3. Send link
4. Recipient connects
5. Data begins transferring
The second workflow removes the separate cloud-upload phase.
The limiting factor becomes the actual network connection between the participants rather than the time required to upload the file into storage first.
Photographers Are Another Interesting Use Case
Wedding photographers and event photographers can generate enormous collections.
A shoot might contain:
2,000 RAW photographs
At 30–60MB each, the project can quickly reach tens or hundreds of gigabytes.
Uploading that collection to temporary cloud storage just so another person can download it once can feel unnecessary.
If both users are available at the same time, P2P transfer becomes an interesting alternative.
Developers Often Need Large Transfers Too
Developers commonly exchange:
VM images
Database dumps
Docker exports
Datasets
Build artifacts
ZIP archives
Local backups
Game assets
Machine-learning datasets
Video assets
Large repository exports
GitHub, email, Slack, Discord, and other collaboration tools are not designed to transfer every type of huge file.
Sometimes you simply need:
"Here is this 15GB file. Get it onto your machine."
A temporary browser transfer can solve that without creating another permanent storage location.
What About Sending Files Over a Local Network?
An interesting scenario occurs when both devices are connected to the same network.
For example:
Laptop
|
Wi-Fi router
|
Phone
If WebRTC finds an appropriate local candidate and connectivity works, communication may take a very efficient network path.
That can make browser-based transfer useful even when the user's goal is simply moving a file between their own devices.
Instead of finding:
A USB cable
A flash drive
A cloud folder
A messaging application
you can potentially open the transfer page on both devices and move the file.
P2P File Sharing vs Cloud File Sharing
Neither architecture wins every scenario.
Here is the important distinction.
| Feature | P2P Transfer | Cloud Transfer |
|---|---|---|
| Sender must stay online | Usually yes | No |
| Recipient must be online simultaneously | Usually yes | No |
| Permanent cloud copy required | No | Yes |
| Storage infrastructure required | Minimal for direct transfer | Significant |
| Large files | Very suitable | Depends on plan |
| Delayed downloads | Poor fit | Excellent |
| Temporary direct sharing | Excellent | Good |
| Offline sender | No | Yes |
| Permanent links | Requires storage | Easy |
| Browser support | Yes | Yes |
The most interesting future may actually be combining both models.
P2P for Free Transfers, Cloud for Persistent Transfers
This is a product architecture I find particularly interesting.
Imagine two modes.
Direct Transfer
Sender online
↓
P2P
↓
Recipient
Characteristics:
Free
Temporary
No permanent storage
Large transfers
Sender stays connected
Then a premium mode:
Stored Transfer
Sender
↓
Cloud storage
↓
Permanent/private link
↓
Recipient downloads later
Characteristics:
Persistent share links
Download later
Password protection
Expiration controls
Storage quota
Transfer history
Custom branding
Now users can choose based on what they actually need.
Someone transferring 80GB to another computer right now does not necessarily need cloud storage.
Someone sending a proposal to a client who may download it three days later probably does.
Browser File Transfer Has Some Hard Engineering Problems
P2P file sharing sounds simple at the architecture level.
In production, however, there are plenty of problems.
1. Connection Reliability
Wi-Fi changes.
Mobile devices sleep.
Browser tabs get suspended.
Networks switch.
A serious file-transfer system should be designed with interruptions in mind.
2. Progress Tracking
For large transfers, users need clear information.
For example:
Transfer progress: 72%
Transferred: 36GB / 50GB
Speed: 18.4 MB/s
Estimated time remaining: 12 minutes
Progress reporting makes the system feel trustworthy.
3. Resumable Transfers
This is one of the harder problems.
Suppose this happens:
48GB / 50GB transferred
Wi-Fi disconnects.
Restarting 48GB from zero would be painful.
A sophisticated transfer protocol can track which chunks have been successfully received and potentially continue from an appropriate position after reconnection.
That requires protocol design beyond simply calling:
channel.send()
4. File Integrity
The recipient needs confidence that:
original file === received file
Applications can calculate cryptographic hashes or validate chunks to detect corruption.
For example, conceptually:
Original SHA-256
↓
Transfer
↓
Received SHA-256
↓
Compare
If they match, the user has stronger assurance that the file arrived intact.
5. Memory Management
A 500MB file and a 100GB file should not be handled identically.
You do not want this architecture:
Read 100GB into RAM
↓
Transfer
↓
Store 100GB in receiver RAM
↓
Create Blob
That obviously does not scale.
Streaming and incremental processing become increasingly important as files grow.
6. Multiple Files
Users rarely send exactly one file.
A transfer session might contain:
video.mp4
thumbnail.png
project.zip
notes.pdf
audio.wav
The protocol needs metadata indicating:
Number of files
File name
File size
MIME type
File identifier
Current file
Chunk number
Transfer completion
A message might conceptually look like:
{
"type": "file-meta",
"id": "file-123",
"name": "project.zip",
"size": 4283920402,
"mime": "application/zip"
}
Then binary chunks associated with that file follow.
Why WebRTC Is Particularly Good for This
WebRTC gives developers several useful capabilities in browsers:
Peer connectivity
It attempts to establish connectivity between endpoints.
NAT traversal
ICE and STUN help peers communicate across common network configurations.
Relay fallback
TURN can provide connectivity where direct routes fail.
Encryption
WebRTC communication uses encrypted transports.
DataChannels
Applications can transmit arbitrary binary data.
Browser availability
Modern browsers already implement the networking stack.
Together, these features make it possible to build applications that previously would have required dedicated native networking software.
You Do Not Need an App for Every Platform
This is one of my favorite things about the web.
Imagine building traditional native file-transfer software.
You might need:
macOS application
Windows application
Linux application
iOS application
Android application
That means:
Different distribution systems
Signing
App-store reviews
OS-specific bugs
Updates
Installation instructions
A web application changes the equation.
You primarily build:
https://yourapp.com
Then users on several operating systems can access it.
Of course, browsers have limitations compared with native applications.
But for many file-transfer use cases, the trade-off is extremely attractive.
What Happens to the File on the Server?
For a direct-transfer architecture, ideally:
File bytes
X
Application storage
The server should not need to save the whole file simply to make the transfer happen.
The backend can instead store temporary information such as:
Session ID
Connection state
Creation time
Expiration
Peer presence
For example:
{
"session": "7uwh82",
"createdAt": "2026-09-30T08:00:00Z",
"senderConnected": true,
"receiverConnected": false
}
This is tiny compared with storing a 100GB media file.
That difference is what makes P2P infrastructure economically interesting.
Does Peer-to-Peer Mean the Service Has Zero Infrastructure Cost?
No.
That is another misconception.
You may still need to pay for:
Signaling servers
TURN bandwidth
STUN infrastructure
API servers
Databases
Logging
Monitoring
Domain names
DDoS protection
Analytics
Abuse prevention
TURN traffic can become particularly important.
When direct connectivity fails, a relay may have to carry the file traffic.
If someone sends a massive file through a TURN relay, bandwidth costs can become meaningful.
So P2P dramatically changes infrastructure requirements, but it does not magically make networking free.
What About Transfer Speed?
A peer-to-peer application cannot make a user's internet connection faster than it actually is.
Suppose:
Sender upload = 40 Mbps
Receiver download = 500 Mbps
The transfer cannot sustainably exceed what the sender can upload.
Likewise:
Sender upload = 500 Mbps
Receiver download = 25 Mbps
the receiver becomes the bottleneck.
A simplified mental model is:
Transfer speed ≈ slowest relevant network bottleneck
Other factors can also reduce throughput:
Wi-Fi quality
Browser implementation
CPU load
Packet loss
Latency
Relay routing
Chunk handling
Buffer configuration
This is why responsible file-transfer products should avoid promising impossible speeds.
The architecture removes unnecessary upload-and-store steps.
It does not break the laws of networking.
Why Not Just Use FTP?
FTP and similar protocols are extremely capable.
But they solve a different UX problem.
To use traditional file-transfer protocols, users may need:
A server
Credentials
Firewall configuration
An FTP/SFTP client
Host information
Port configuration
That is completely reasonable for developers and infrastructure teams.
It is not ideal for someone who simply wants to send vacation photos to a family member.
The browser makes P2P much more accessible.
The user does not need to know anything about:
ICE
SDP
STUN
TURN
NAT
DataChannels
They should simply see:
Choose files → Share link
The complexity belongs inside the application.
Why Not Just Use Email?
Email was never designed for large binary transfers.
Attachments have relatively small limits and usually require encoding that introduces additional overhead.
For a document, email is convenient.
For:
25GB video.mp4
it clearly is not the right tool.
Why Not Just Use Messaging Apps?
Messaging applications are convenient but may:
Impose size restrictions
Compress media
Require accounts
Retain files on servers
Require both users to use the same platform
Again, they solve a different problem.
A dedicated browser file-transfer tool can remain application-agnostic.
Share the connection link through:
WhatsApp
Messenger
Telegram
Slack
Email
Discord
SMS
A QR code
The messaging platform transports only the link.
The actual file transfer happens separately.
A File-Sharing Link Can Be Tiny Even When the File Is Huge
This is one of the elegant parts of the architecture.
You could have:
File size: 120GB
yet the share message is only:
https://example.com/receive/abc123
The URL represents the session, not the file itself.
The recipient opens it and establishes the connection.
That means the communication channel used to share the link does not care how large the eventual file is.
Temporary Sessions Also Have Security Advantages
A permanent link expands the amount of time during which a resource can potentially be accessed.
Temporary P2P sessions can disappear when:
The transfer completes
The sender leaves
The session expires
The application closes
For appropriate use cases, ephemeral sessions reduce the lifetime of access.
A production application can make session identifiers difficult to guess and automatically invalidate them.
But Permanent Links Are Still Extremely Useful
Imagine sending a file to a client.
You do not know whether they will download it:
in 5 minutes
in 5 hours
tomorrow
next week
Keeping your computer online is unreasonable.
That is where cloud storage becomes useful again.
A persistent link requires some system to continue holding the data after the sender disappears.
This is why I do not think the future is necessarily:
P2P replaces cloud storage.
A more realistic model is:
Use P2P when both users are present. Use cloud storage when persistence is required.
That distinction can reduce unnecessary storage while preserving convenience.
The Browser Is Becoming a Serious Application Platform
Years ago, many developers would have assumed serious file-transfer software required native applications.
Modern browsers now provide APIs for:
Real-time communication
Binary data
File access
Streams
Cryptography
WebSockets
Workers
Local storage
Notifications
Progressive web apps
Not every native capability is available.
But the boundary continues moving.
WebRTC is one of the clearest examples.
A browser tab can establish an encrypted connection with another browser and exchange gigabytes of binary data.
That is pretty remarkable when you stop and think about it.
When Should You Use P2P File Transfer?
P2P file sharing is especially useful when:
Both people are online
The sender and recipient can stay connected during the transfer.
Files are very large
Avoiding an upload-to-storage stage can save time and infrastructure.
Privacy matters
You would rather avoid permanently storing the content with a third-party transfer provider.
You need cross-platform transfer
The devices use different operating systems.
You want minimal setup
Opening a browser is easier than installing applications.
You need temporary sharing
You do not need the file to remain available for days.
When Should You Use Cloud Storage Instead?
Cloud storage is usually better when:
The recipient is offline
You need to upload now and let them download later.
You need a permanent link
The file must remain available.
Multiple people need the same file
Uploading it once may be more efficient than repeatedly transferring it from the sender's device.
You want backups
P2P transfer is not a backup system.
You need asynchronous collaboration
People access the content at different times.
The important thing is choosing architecture based on the actual problem rather than treating one model as universally superior.
P2P File Sharing and the Future of Web Applications
File transfer is just one use case for browser-to-browser networking.
The same concepts can enable:
Multiplayer applications
Watch parties
Collaborative tools
Local device synchronization
Browser chat
Decentralized applications
Remote-control systems
Real-time collaboration
Screen sharing
Media streaming
WebRTC essentially gives browsers the ability to communicate with each other in ways that traditional request/response web applications cannot.
That opens a large design space.
Building ButterShare Changed How I Think About File Transfer
Before exploring this problem deeply, it was easy to think about file transfer as:
Upload file
Generate link
Download file
But that workflow exists largely because cloud storage sits in the middle.
Remove mandatory storage and the product can behave completely differently.
Now the mental model becomes:
Connect devices
Transfer bytes
Disconnect
That sounds like a small change.
Architecturally, it changes almost everything.
Storage costs change.
Privacy properties change.
File-size constraints change.
The sender experience changes.
The recipient experience changes.
The business model can change.
The infrastructure changes.
And suddenly a browser begins to look less like a document viewer and more like a networking application runtime.
Try Browser-to-Browser File Sharing
If you regularly need to send large files and both devices can remain online during the transfer, you can try the approach yourself with ButterShare — browser-to-browser file sharing at https://buttershare.com/.
The basic idea is simple:
Choose your files
↓
Create a share link or QR
↓
Open it on the receiving device
↓
Connect
↓
Transfer
No complicated setup should be required.
For me, that simplicity is the interesting part.
Users do not need to understand WebRTC.
They do not need to know what ICE negotiation is.
They should not care whether a DataChannel exists.
Great infrastructure disappears behind a simple interaction:
I have a file here. I want it over there.
Frequently Asked Questions
Can I send large files without uploading them to cloud storage?
Yes. Browser-based peer-to-peer technologies such as WebRTC can allow files to be transferred between connected devices without first permanently uploading the complete file to cloud object storage.
The sender and receiver generally need to remain connected while the transfer takes place.
Can browsers transfer files directly?
Yes.
WebRTC DataChannels allow modern browsers to exchange arbitrary binary data, making browser-to-browser file transfers possible.
A signaling service is normally used to help establish the connection.
Does WebRTC support large files?
WebRTC DataChannels can transmit binary data, but large-file applications should transfer data incrementally rather than trying to load and send an entire huge file at once.
Production implementations must handle things such as chunking, buffering, memory management, progress reporting, reconnect behavior, and browser limitations.
Is peer-to-peer file transfer secure?
WebRTC communication uses encrypted transport.
However, the security of a complete file-sharing application also depends on session design, HTTPS, signaling security, access controls, application vulnerabilities, and other implementation details.
Do P2P file transfers use cloud storage?
They do not necessarily need to.
A signaling server can help two devices establish a connection without storing the complete transferred file.
Some WebRTC connections may require relay infrastructure, but relaying traffic is different from storing the file as a persistent cloud object.
Does the sender need to stay online?
For a live P2P transfer, generally yes.
If the sender closes the browser or loses connectivity, there may no longer be a source from which the recipient can download.
If you need someone to download a file later while you are offline, cloud storage is the more appropriate architecture.
Can I transfer files between Android and iPhone?
Browser-based transfer can work across different operating systems as long as the browsers support the required technologies.
This is one of the main benefits of using web standards instead of building an ecosystem-specific transfer application.
Can I transfer files between Windows and Mac?
Yes.
The operating systems do not have to match when both devices communicate through compatible browsers.
Can I transfer files from a phone to a computer?
Yes.
A particularly convenient approach is generating a QR code on one device and scanning it with the other.
The QR code can contain the transfer-session URL.
Is peer-to-peer faster than cloud file sharing?
Not automatically.
The actual transfer speed depends heavily on the internet connections and network path.
The key difference is that P2P can remove a separate upload-to-cloud stage before the recipient begins receiving the content.
Is there really such a thing as unlimited file transfer?
"Unlimited" needs context.
No computer or network has infinite capacity.
A service can, however, avoid imposing an arbitrary platform storage limit on direct transfers because the entire file does not need to fit inside the provider's cloud storage.
Real-world limits still include connection speed, browser capabilities, disk capacity, memory, network stability, and available time.
What is the difference between P2P file sharing and cloud file sharing?
With cloud sharing:
Sender → Cloud → Recipient
With peer-to-peer sharing:
Sender → Recipient
The first model works extremely well for persistent, asynchronous downloads.
The second model works well for live transfers where both participants are online.
What is a WebRTC DataChannel?
A WebRTC DataChannel is a mechanism that allows two WebRTC peers to exchange arbitrary application data.
Unlike the media portion of WebRTC, which focuses on audio and video, DataChannels can carry custom binary or textual data.
That makes them useful for applications such as file transfer.
What is a STUN server?
A STUN server helps a device discover network information that can be used during WebRTC connectivity negotiation.
It is part of the mechanism used to establish connections between peers behind routers and NAT.
What is a TURN server?
A TURN server acts as a relay when peers cannot establish a suitable direct network path.
Instead of traffic flowing directly between the two devices, it passes through the TURN server.
TURN improves connectivity but increases server bandwidth requirements.
Does ButterShare store files?
The direct-transfer concept behind ButterShare is designed around transferring files between devices rather than requiring the entire file to be permanently uploaded to traditional cloud storage first.
That is what makes the architecture particularly suitable for large, temporary transfers.
Final Thoughts
Cloud storage solved one of the biggest problems of the early internet: making files accessible from anywhere.
It remains incredibly useful.
But not every file needs to live in the cloud.
Sometimes two devices are online at the same time.
One has a file.
The other needs it.
In that situation, uploading tens of gigabytes to a third location and then downloading those same tens of gigabytes again can feel unnecessary.
WebRTC gives web developers another architecture.
Instead of asking:
Where should we upload this file?
we can sometimes ask:
Can these devices simply send it to each other?
That small change in perspective is what makes peer-to-peer browser file transfer so interesting.
And as browsers continue becoming more capable application platforms, I suspect we will see many more products built around the same principle:
use servers to coordinate users when necessary, but do not make servers carry or store data that they do not actually need.
If you want to experiment with that model without installing an application, check out ButterShare at https://buttershare.com/.
The web browser may already be the file-transfer app you need.