Textunnel transfer guide: Wi-Fi sharing, limits and recovery

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.

Use a temporary file share link

Create a share link from the transfer tool and send that link to the intended recipient. Keep the source tab open and connected until the receiver finishes. Links accept up to 256 MiB and use their own secret; anyone with the link may be able to access the offered transfer.

A link is not a permanent cloud upload. If direct transfer is unavailable, both peers must approve internet relay; MQTT fallback is limited to 25 MiB. Sender refresh does not restore the full share session: reselect the source and recreate the link when necessary.

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

Physical test results and scope

The following physical sessions were recorded on October 18, 2026. Exact browser and OS versions were not recorded, so these results are not a browser-version certification.

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.

Cloud Windows browser test — October 22, 2026

Windows Server 2025 Datacenter (10.0.26100, x64), Chrome 155.0.8059.85. Published October 23, 2026.

GitHub-hosted Windows virtual machine, two isolated browser contexts on one host. Native WebRTC host-candidate route; ICE servers were cleared in the test harness. This verifies the recorded OS/browser workflow, not default STUN traversal, a physical Windows PC, Windows 11, iPhone-to-Windows, Android, or a same-Wi-Fi phone/PC session.

The 1 MiB and 64 MiB files were downloaded and sent back with matching hashes. The 64 MiB refusal reached the sender without a success receipt. This is a maintainer-run functional test, not an independent security audit.

Original workflow attachment SHA-256: 6c846f6de0f4f2dc825040779d3dc2abe5c97924b6e4e108e6dc8c1f2428d09f