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.
How the transfer methods actually compare
The reason peer-to-peer exists is that every other option makes a copy of your document somewhere you do not control. It is worth seeing the trade-offs side by side rather than in the abstract.
Email attachment. Gmail caps attachments at 25MB and Outlook at 20MB. Your file is stored on both mail providers' servers indefinitely, is scanned, and sits in the recipient's mailbox and your Sent folder forever. Convenient, and the least private option on this list.
Cloud link (Drive, Dropbox, WeTransfer). Handles large files well and the recipient can collect whenever they like. In exchange, a full copy is stored on a third-party server, the link can be forwarded to anyone, and deleting the file later does not retract the copies already downloaded. Free tiers also expire links, which is why so many shared documents are dead within a fortnight.
Peer-to-peer. No copy is stored anywhere, there is no size cap, and nothing expires because nothing persists. The cost is that both people must be present at the same time. That single constraint is the whole trade-off — everything else about it is better.
What "private" means here, precisely
It is easy to write that a transfer is secure and much more useful to say what is actually protected and from whom. The data channel between the two browsers is encrypted in transit using DTLS, which is part of the WebRTC standard rather than something bolted on. That means someone sharing your WiFi, your network administrator, or an intermediate network operator cannot read the contents as it passes.
What DTLS does not do is protect the file from the person you sent it to, or from anyone with access to either device. And a small amount of connection metadata — the IP addresses the two browsers use to find each other — is necessarily exchanged, which is how any direct connection works. If you want the file itself to be unreadable even to someone who somehow intercepted the stream, set a password: the file is then encrypted with AES-256 on your device before it is sent, and the recipient cannot open it without that password. Send the password by a different route than the share code, or you have wrapped the key around the parcel.
When the connection will not establish
Direct connections fail sometimes, and the reason is almost always the network rather than the tool. The two browsers discover a route to each other using STUN, and there is no relay server fallback — that absence is exactly what guarantees your file never touches third-party infrastructure, but it also means that when a network refuses direct peer connections, there is no plan B.
In practice three situations cause this. Corporate networks frequently block the UDP traffic WebRTC needs; if you are on a work VPN, disconnecting it usually fixes the problem immediately. Some mobile carriers use carrier-grade NAT that prevents inbound connections entirely — switching one device to WiFi normally resolves it. A few countries and institutions filter WebRTC deliberately. If a connection times out, the fastest diagnostic is to put both devices on the same WiFi network and try again; if that works, the problem was the route between networks, not the browsers.
Practical notes for large transfers
Because the file streams directly rather than uploading first, a large transfer takes exactly as long as the slower of the two connections allows, and it is your upload speed that matters — which on most home broadband is far lower than the download figure the provider advertises. Keep the tab open and visible on both devices; browsers aggressively throttle background tabs, and on phones a locked screen will suspend the transfer. For anything very large, plug into power and use WiFi rather than mobile data on both ends. And if the document is a PDF, running it through the compressor first is often the single biggest saving available — a scanned document commonly drops by half or more before you send a single byte.
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.
Can I password-protect the file before sending it?
Yes. Set a password before sharing and the file is encrypted with AES-256-GCM on your own device before transmission, using a key derived from your password. The recipient must enter the same password to open it. Share that password through a different channel than the transfer code.
Why did my transfer fail to connect?
Almost always a network restriction rather than a fault in the tool. Corporate VPNs and firewalls commonly block the direct peer connections this relies on, and some mobile carriers prevent them too. Disconnect from a work VPN, or put both devices on the same WiFi network, and try again.
Can I send files other than PDFs?
Yes. Any file type works — images, video, archives, spreadsheets, code. The transfer moves raw bytes and does not inspect or convert what you send.
Does the transfer resume if my connection drops?
No. Because there is no server holding a partial copy, an interrupted transfer has to be restarted from the beginning. For very large files on an unreliable connection, a cloud service with resumable uploads is the more practical choice.