P2P Transfer is a fast, secure, peer‑to‑peer file sharing web app. Send files directly between devices via WebRTC—no accounts, no uploads, no storage. Share an 8‑digit code or QR, connect, and transfer instantly. Works across networks with STUN/TURN for reliable connections. Optional password encryption and checksum verification. Limit: 100MB per transfer.
No reviews yetBe the first to leave a review for P2P Transfer
Maker
📌
I built P2P Transfer because I kept hitting the same pain: I just wanted to send a file from one device to another (often Mac → Android) without signing in, uploading to a cloud drive, or losing quality via chat apps. Most “quick” options either require accounts, compress media, or leave files sitting on someone else’s server.
The goal became simple: direct device‑to‑device transfer in the browser, with a frictionless “share a code and go” flow.
During development the biggest evolution was reliability. The first prototype worked on the same Wi‑Fi, then I ran into real-world networks (NATs, mobile hotspots, corporate routers). That pushed me to harden the WebRTC setup (better ICE handling, clearer connection states) and add TURN support so it can connect across networks. I also focused on UX: progress/status steps, a mobile‑friendly UI, and an onboarding slideshow so anyone can use it in seconds. Finally, I added optional password encryption + checksum verification and a clear 100MB-per-transfer limit to keep it fast and predictable.
Report
I've dealt with the same Mac → Android transfer pain. The WebRTC + TURN implementation is smart for NAT traversal, but I'm curious about one specific scenario: if both devices are behind symmetric NAT (common in corporate networks), does the TURN fallback handle that reliably? Also, how do you handle partial transfers when connections drop mid-file—does it support resume, or does the 8-digit session expire?
Report
Maker
@easytoolsdev TURN: Yes—TURN relay works with symmetric NAT because it relays all traffic. Reliability depends on the network allowing outbound UDP/TCP to the TURN server; some corporate firewalls block it, which will still fail.
Resume: At the moment, only a lightweight sender‑side checkpoint exists (sessionStorage, ~30 minutes). There’s no full receiver‑side resume, and the 8‑digit code is one‑time/short‑lived after being claimed. If the connection drops mid‑file, users should create a new code and resend.
I've dealt with the same Mac → Android transfer pain. The WebRTC + TURN implementation is smart for NAT traversal, but I'm curious about one specific scenario: if both devices are behind symmetric NAT (common in corporate networks), does the TURN fallback handle that reliably? Also, how do you handle partial transfers when connections drop mid-file—does it support resume, or does the 8-digit session expire?
@easytoolsdev
TURN: Yes—TURN relay works with symmetric NAT because it relays all traffic. Reliability depends on the network allowing outbound UDP/TCP to the TURN server; some corporate firewalls block it, which will still fail.
Resume: At the moment, only a lightweight sender‑side checkpoint exists (sessionStorage, ~30 minutes). There’s no full receiver‑side resume, and the 8‑digit code is one‑time/short‑lived after being claimed. If the connection drops mid‑file, users should create a new code and resend.