Browser sharing · No account required
P2P file sharing between your devices
Open Textunnel on both devices, enter the same room code and wait for File channel ready. Choose a file, accept it on the receiver and save it after verification. Online rooms need internet for discovery and signaling; file content prefers direct WebRTC.
Choose files to share
Choose files or connect your devices to begin. Keep both pages open during transfer.
Share links and folder packing: up to 256 MiB. For larger single files, and select the file there. The receiver needs supported disk saving.
Direct-first · Internet relay needs permission
How to use it
- Open the same room on both browsers. Check that the room password matches if one is set.
- Wait for File channel ready in the device panel. A listed device alone is not a ready file connection.
- Choose your file and accept it on the receiving device if prompted. Keep both pages active.
- Wait for the receiver completion receipt, then download and save the received file.
What to check in the room
Limits and connection conditions
If the file channel is unavailable, check guest Wi-Fi isolation, firewall rules and VPN access to the local network. Retry after reconnecting. Do not assume a text message proves a large file can use the same route.
- Text and clipboard messages: 64 KiB encoded message limit
- Use a file for larger content. Clipboard permissions and foreground access still apply.
- MQTT file fallback: 25 MiB per file
- Both peers must explicitly allow relay in their current tabs.
- Share links and folder packing: 256 MiB
- Keep the source page open. Browser memory, storage and network limits apply.
- Room reception above 256 MiB: Supported disk-saving API required
- Choose a receiving browser with disk-saving support for larger files, and check available storage before starting.
- Interrupted-file checkpoints: Up to 256 MiB for 10 minutes
- Return to the page, reconnect, then sender Retry. Cross-refresh recovery requires opting in before transfer; four temporary records maximum, unencrypted at rest.
WebRTC transport is encrypted. Public-room MQTT content needs a room password for encryption against the broker. Internet content relay requires explicit permission in each tab. History and optional recovery use device storage; the site also uses analytics and advertising scripts.
Privacy, relay permission and full transfer guideVerified transfer workflows
Maintained by the Textunnel team · Content reviewed October 23, 2026 · Physical acceptance record: October 18, 2026
In same-Wi-Fi tests between iPhone Safari and Mac: 1 MiB and 64 MiB saved and returned over WebRTC; returned SHA-256 matched the source. A 64 MiB rejection also reached the sender correctly.
These checks confirm the tested workflows, rather than a fixed transfer speed. For interrupted transfers, return to the page, reconnect and ask the sender to Retry.
A separate cloud Windows Server 2025 / Chrome 155.0.8059.85 check passed 1 MiB and 64 MiB file round trips with matching download hashes and a refusal check. It used two browsers on one virtual machine; it does not establish an iPhone-to-Windows or Android physical-device result. Windows environment and results.
Detailed transfer test resultsFrequently asked questions
Does P2P mean files always stay on my Wi-Fi?
No. DIRECT identifies a non-relay WebRTC route, not a proven local-network route. VPN routing can change the path. Online discovery and signaling use internet services even when file content travels directly.
Can I send a file without uploading it for later storage?
Direct transfers send content between the open browsers. The sender must remain online. Optional internet content relay requires permission; a share link is not permanent cloud storage.
How do I know a file actually arrived?
Received by 1/1 means the receiving app verified the complete file. It does not mean a person read it or saved a download. Use the receiver download action and system save flow.