The problem with "sharing" a PDF online
Every mainstream way of sharing a PDF involves your file touching a third-party server. Email providers scan attachments. Google Drive, Dropbox, and WeTransfer store your file on their infrastructure — sometimes indefinitely. WhatsApp Web and Telegram upload files to their servers before delivering them. For confidential documents — contracts, medical records, financial statements, personal IDs — this creates a trail of copies on servers you don't control, subject to data retention policies you probably haven't read.
ihatepdf's P2P Share tool solves this using WebRTC — the same browser technology that powers video calls. Your file travels directly from your browser to the recipient's browser, with no server in the middle. The file bytes never touch any storage system outside the two devices.
How to share a PDF directly browser-to-browser — step by step
- Open ihatepdf.cv/p2p-share — no sign-up required
- Click Send a File and select your PDF (or any other file)
- A unique share link is generated — copy it
- Send the link to the recipient via any channel (WhatsApp, email, Slack, SMS)
- When the recipient opens the link, the direct transfer begins automatically
- Both sides see a live transfer progress bar — no waiting for a server upload first
- The recipient's browser downloads the file directly from your browser
The link becomes inactive once the transfer completes or either browser closes the tab. No file is ever stored on ihatepdf's servers.
How WebRTC peer-to-peer transfer works
WebRTC (Web Real-Time Communication) is a browser standard originally designed for video calling. It establishes an encrypted data channel directly between two browsers, using a process called ICE (Interactive Connectivity Establishment) to negotiate the most direct path — ideally a direct device-to-device connection on the same network, or a TURN relay server for connections across different networks. The TURN relay only handles routing metadata, not file content. The file bytes themselves travel through the encrypted direct channel.
This is the same technology used by file-sharing tools like Snapdrop, ShareDrop, and Wormhole — ihatepdf's implementation is built directly into the tool suite so you don't need to switch to a separate service.
When to use P2P Share vs email vs cloud storage
- Use P2P Share — for confidential documents where you want no server copies, large files that exceed email attachment limits, one-time sends where you don't want a persistent shareable link, and transfers between two devices you control (e.g. your phone and your laptop)
- Use email — for small files where a persistent copy in the recipient's inbox is acceptable and useful
- Use cloud storage — for files you want to share with multiple people over time, or where the recipient needs permanent access
Prepare your PDF before sharing privately
Before sharing a sensitive document via P2P, consider two additional steps. First, use the Privacy Scanner to check for and remove hidden metadata — author names, GPS coordinates, and software version data — that you may not want the recipient to see. Second, use Encrypt PDF to add a password. Even though P2P transfer is direct and encrypted in transit, a password means the recipient needs the correct password to open the file — providing a second layer of protection if the file is forwarded.
Compress large files before transferring
P2P transfer speed depends on both parties' internet connections. For large PDFs (over 10MB), compress the PDF first to reduce transfer time. A 25MB scanned document can typically be compressed to 4–6MB without any visible quality loss, reducing transfer time significantly on slower connections.
Frequently asked questions
Does ihatepdf see my file during the transfer?
No. ihatepdf's servers only handle the initial WebRTC signaling — exchanging the connection metadata needed to establish the direct channel. The file data itself travels through the encrypted peer-to-peer connection and is never accessible to any server.
What happens to the share link after the transfer?
The link is tied to the active browser session on the sender's side. Once the sender closes the tab or the transfer completes, the link becomes invalid. There is no persistent file hosted anywhere.
What if the recipient and sender are on different networks?
WebRTC negotiates the best connection path automatically. For connections across different networks, a TURN relay handles the routing — the transfer still works, though speed depends on both parties' upload/download bandwidth.
Is there a file size limit?
No server-imposed limit. The practical constraint is the available RAM on both devices and the speed of both connections for large files.
Does it work on mobile browsers?
Yes. WebRTC is supported in Chrome and Safari on both iOS and Android. Both sender and receiver can be on mobile devices.