Initializing Secure Environment…
Initializing Secure Environment…
Send any file directly from your browser to another browser — no server in between, no upload, no account, completely private. Built on WebRTC peer-to-peer technology. One person generates a share code; the other enters it. The file transfers directly between the two browsers without touching any server.
To send a large file without uploading it anywhere, use a peer-to-peer browser transfer that streams the data directly between two devices. On ihatepdf, drop in the file, share the generated code with the recipient, and the bytes travel straight from your browser to theirs over an encrypted WebRTC connection — no server storage, no account, no size limit.
When you share a file here, the two browsers first need to find each other. They use STUN servers to discover their own public network addresses and negotiate a route, then open a direct WebRTC data channel between the two devices. From that point the file is read in 64KB chunks and streamed straight across that channel. No copy is written to any server, which is why there is no upload progress bar before the recipient can start receiving — the transfer to them IS the upload. It is also why the file cannot be scanned, logged, retained or subpoenaed from a middleman: there is no middleman holding it.
Peer-to-peer is the better choice when the file is confidential, when it is too large for email or a free cloud tier, when you want no trace left behind, or when you simply want it to arrive now rather than uploading and then waiting for a download. It is the wrong choice when the recipient is not available at the same moment, when you need one file to reach many people over days, or when you are on a network that blocks direct connections. Those cases genuinely call for a cloud service — this is a different tool for a different job, not a universal replacement.
WebRTC data channels are already encrypted in transit using DTLS, so a passive observer on the network cannot read the contents. For anything genuinely sensitive you can add a second layer: set a password and the file is encrypted with AES-256-GCM before it ever leaves your device, using a key derived from your password with PBKDF2 at 200,000 iterations of SHA-256. The recipient cannot open the file without that password. Send the password through a different channel than the share code — if you paste both into the same chat, you have undone the point of it.
When you send a file via Google Drive, WeTransfer, or email, the file is uploaded to a server that stores it — sometimes permanently. Those services scan file contents, retain data after the transfer, and may share data with third parties. WebRTC P2P transfer eliminates the server from the equation entirely. The file travels directly from one browser to the other without being stored anywhere. This makes P2P transfer the most private way to send sensitive files to a colleague, client, or friend.
Open ihatepdf.cv/p2p-share, drop in the file, and share the generated code with the person receiving it. When they enter the code, the two browsers open a direct connection and the file streams straight from your device to theirs. Nothing is stored on a server at any point, so there is no upload wait, no download link that expires, and no copy left behind.
There is no limit imposed by us, because there is no server storing the file. The transfer is streamed in 64KB chunks directly between the two browsers, so the practical limits are the sender's available memory and both parties staying on the page until it finishes. People routinely move multi-gigabyte files this way.
Yes. Set a password before sending and the file is encrypted with AES-256-GCM before it leaves your device. The key is derived from your password using PBKDF2 with 200,000 iterations of SHA-256, and the recipient must enter the same password to decrypt. The password itself is never transmitted — share it through a different channel from the code.
Yes. This is the one real trade-off compared with cloud sharing. Because there is no server holding the file, both browsers must be on the page simultaneously for the connection to exist. If you need the recipient to collect the file later, use a normal cloud service — or send it while you are both available.
Different networks work. The browsers use STUN servers to discover how to reach each other across the internet, then connect directly. Same-WiFi transfers are simply faster because the data never leaves the local network.
Yes, and it is worth knowing why. The connection is established with STUN discovery and no TURN relay fallback, which is what guarantees the data never passes through a third party. Some strict corporate firewalls and a minority of carrier-grade NAT mobile networks block direct peer connections entirely. If the connection times out, try a different network — switching off a corporate VPN usually resolves it.
It is structurally safer than any upload-based service, because the file is never written to a disk you do not control. WebRTC data channels are encrypted in transit by default (DTLS), and you can add your own AES-256 password layer on top. There is no account, no log, and nothing to delete afterwards because nothing was ever stored.
Any file type, not just PDFs — documents, images, video, archives, code. The tool moves raw bytes and does not inspect or convert the content.
No. WebRTC establishes a direct peer-to-peer connection between the two browsers. Only the connection metadata passes through a signaling server momentarily; the file bytes go directly between the devices.
No server limit. Large files transfer as long as both devices maintain the connection. Network speed determines transfer time.
No. P2P file transfer works across different networks and over the internet.
More collaborate & share — all free, no upload.