Textunnel transfer guide: Wi-Fi sharing, limits and recovery
Textunnel is a free browser tool for sharing files and text between devices, with direct WebRTC preferred. Online discovery needs internet; TURN and MQTT content relay require explicit permission. File limits and clipboard access depend on the route and browser.
Maintained by Textunnel maintainers. Reviewed .
Understand privacy and internet relay permission
Browsers encrypt WebRTC data-channel transport, including when TURN forwards it. Public-room MQTT payloads need a room password for application-layer encryption against the broker. Share links use their own secret. Treat codes, passwords and links as private.
TURN and MQTT content relay require explicit permission in each tab. Permission resets after reload or tab closure, and can be revoked. Revocation stops new relay work, but cannot recall bytes already sent. The Direct only preference can persist; it does not remove the internet dependency of online discovery and signaling.
History, preferences, optional temporary recovery and system-share handoff data use device storage. Third-party analytics and advertising scripts run on the site. Browser and device security matter as well; see the privacy policy for data handling.
Connect devices on the same Wi-Fi
Open Textunnel on both devices, use the same room code and wait for File channel ready in the device panel. Presence alone does not mean the file channel is ready. Choose a file, accept it on the receiver if prompted, then wait for the receiver completion receipt.
DIRECT means a selected non-relay WebRTC route. It does not prove a shared Wi-Fi network: VPNs may change routing. Online discovery and signaling need internet. For a local connection without online signaling, load/cache the site first and use Offline Connect: the guest scans the host Offer QR, then the host scans the guest Answer QR.
Room codes and links should be shared only with intended recipients. Reopen the same room to reconnect; do not assume a remembered room guarantees permanent pairing or background availability.
Save received files and use automatic saving
A completed receipt means the receiving app verified the file. It does not mean a download was saved to disk. Use the completed card download action, then the browser or system save flow. On iPhone, save to Files before selecting the file again to send it back.
Automatic directory saving depends on a supported browser disk-saving API and permission to choose a destination. Where unavailable, use the browser download flow. Default received file bytes live in the open page; after refresh a card can be history only, with an unavailable-file explanation.
Send multiple files, folders and dropped files
Use the attachment/file picker to select files, or drag files into the desktop transfer area. Folder selection and drag-and-drop availability depend on the browser. Folder packing runs locally, preserves relative paths and produces a downloadable archive; it is limited to 256 MiB and uses browser memory.
Check each file receipt and save received content before closing or refreshing the page. The open room keeps a bounded 512 MiB received-download cache; save and clear the receiving stream when it is full.
Copy, paste and sync text between devices
For manual sharing, paste text into the composer and press Send. On the receiver, use Copy on the message. For Auto-Sync, enable it on both devices, grant browser clipboard permissions where requested and keep the pages active.
Browser focus, user gestures and operating-system background rules can prevent automatic reading or writing. A sent/shared notice does not prove the other system clipboard changed. If automatic copying is unavailable, use manual copy and paste.
Recover after lock screen, background or network interruption
Keep both browser pages in the foreground. Wake lock is best effort; iPhone lock-screen or background transmission can stop. Return to Safari, wait for File channel ready, then ask the sender to Retry and accept the retry if prompted. Reconnection alone does not restart a failed file automatically.
Eligible verified prefixes can resume within 10 minutes, up to 256 MiB. To retain checkpoints across refresh, enable Recover interrupted files after refresh in receiver Preferences before transfer. It temporarily stores incomplete bytes locally, unencrypted at rest. After refresh, reselect the original source on the sender and the destination on disk receivers as needed. Larger interrupted files retry from the beginning.
If a device is missing, first confirm the room code and password. Check VPN local-network routing, guest Wi-Fi/AP isolation and firewall rules. Do not assume a DIRECT badge means traffic stayed on your LAN. Direct only prevents content relay but still allows online discovery/signaling.
Configure an optional custom TURN relay
TURN is optional for networks where a direct route cannot be established; it is not needed for every same-Wi-Fi transfer. In Preferences, open Advanced: Custom TURN Server, enter a valid TURN URL and the provider-issued username and password, then save. Never publish credentials in a page or repository.
Saving a TURN address does not authorize relay. Both peers must explicitly allow relay in the current tab; Direct only disables it. TURN forwards encrypted WebRTC transport, while MQTT is a separate fallback. A public TURN deployment is not part of the physical LAN acceptance, and no public relay availability or speed guarantee is made.
File limits by route
| Route | Limit | Conditions |
|---|---|---|
| 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 | Not an unlimited multi-gigabyte iPhone browser path; no 50 GB transfer is claimed. |
| 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. |
Physical test results and scope
These are functional acceptance observations from the October 18, 2026 test record, not speed benchmarks or proof for every browser, VPN or router. Desktop reads were deliberately slowed for interruption tests. In-flight refresh recovery, iOS process eviction and physical Android/Windows coverage remain unverified.
- iPhone Safari ↔ Mac on the same Wi-Fi, at least one VPN enabled
- 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.
- iPhone lock screen and background
- Uninterrupted transfer did not pass. Returning to Safari reconnected; manual sender Retry resumed verified prefixes, and complete 64 MiB return hashes matched.
- Physical network interruption
- After Wi-Fi and cellular were disabled for about 20 seconds and restored, reconnection plus manual Retry resumed a retained prefix; the full 64 MiB return hash matched.
- Offline QR connection
- Both real cameras exchanged Offer/Answer QR codes. With desktop WebSocket signaling blocked from context creation, a native host-to-host channel transferred a 1 MiB file with matching return hash. This does not prove an uncached offline first visit.
Evidence basis: repository acceptance reports for modules 67 and 68; source reports include receiver receipts and SHA-256 checks. Acceptance report sources. This guide summarizes a dated test scope, not an independent certification.