Encrypt locally
TunnelTransfer creates an AES-GCM key in your browser before the first byte leaves your device.
P2P file transfer with end-to-end encryption
Send files directly between browsers, the TunnelTransfer extension, Android and Windows apps.
Your file is encrypted on your device, sent over a direct WebRTC tunnel, and unlocked only with the share code you choose to pass along.
Create a code
Send
Drag and drop file(s) here
Use a code
Receive
How it works
A private tunnel, without storing your file.
Share the code
The code contains the peer ID and encryption key. Send it only to the person receiving the file.
Transfer P2P
Browsers connect through WebRTC and move encrypted chunks directly whenever the network allows it.
Download safely
The receiver decrypts chunks locally and saves the completed file. TunnelTransfer does not keep a copy.
What is TunnelTransfer?
A private transfer layer that keeps file sharing simple without handing your files to cloud storage.
TunnelTransfer creates a direct WebRTC data channel whenever possible instead of uploading a file to a storage server first. The website, Chrome/Brave extension, Android and Windows apps work together with the same share-code format.
Why it exists
Everyday file sharing is often heavier than it needs to be: accounts, uploads, links, and repeated downloads. TunnelTransfer reduces that flow to one temporary code and an end-to-end encrypted P2P transfer.
How it is different
File contents are encrypted before leaving the device. When a direct path is available, the file does not pass through TunnelTransfer storage. Multiple selected files are packed into a standard ZIP on the sender device and sent through the same secure channel.
When it works best
It is fastest when both sides are online at the same time, especially on reliable modern networks. The extension can keep transfers more resilient by running the transfer outside the popup.
Core principle
Convenience and security are treated as one workflow. Pick files, share the code, complete the transfer. The key that can decrypt the file exists only in the complete share code.
FAQ
Frequently asked questions
Does TunnelTransfer upload my files to a server?
The web transfer is designed for P2P delivery. The file is sent directly to the receiver and this site does not use cloud storage for file contents. PeerJS signaling only helps devices find each other; contents are encrypted before transfer.
Do both devices need to stay online?
Yes. In the web version, sender and receiver pages must remain open until the transfer finishes. The extension is more resilient because it can continue transfer work in its background/offscreen context.
Can I send multiple files?
Yes. If you select more than one file, the browser packages them into a standard ZIP and sends that ZIP as one encrypted transfer. The first implementation stores files in the ZIP without compression, which is fast and dependable for every file type.
Why can Brave, Firefox, or mobile browsers behave differently?
WebRTC depends on browser privacy and network settings. Brave Shields, WebRTC IP policies, enterprise firewalls, or strict UDP blocking can prevent direct connections. Adjusting site shields or WebRTC policy may be required.
How sensitive is the share code?
The code contains both the peer ID and the encryption key. Anyone with the complete code can connect and decrypt the file during the transfer. Treat it like a temporary password.
Is there a file size limit?
The practical limit is set by browser memory, device performance, and network stability. For very large transfers, keep both devices awake and use a stable network.
Security design
File contents are encrypted on your device and remain unreadable in transit.
TunnelTransfer is built around end-to-end encryption. Every send operation creates a fresh AES-GCM key. Files are split into chunks, each chunk is encrypted, and the receiver decrypts them only with the correct key.
Key handling
The encryption key is generated locally and carried inside the share code. The signaling service does not need the key. The peer ID connects devices; the key decrypts chunks.
Encryption
The web version uses the Web Crypto API with AES-GCM 256-bit keys. AES-GCM protects confidentiality and integrity: altered encrypted data fails to decrypt.
Transport layer
WebRTC data channels use the browser's secure transport mechanisms. TunnelTransfer adds its own file encryption on top, creating independent transport and content protection layers.
Signaling
PeerJS signaling helps devices discover each other. Signaling alone cannot decrypt file contents. Without the exact share code, encrypted chunks are not meaningful.
Multiple files
When several files are selected, the ZIP is created on the sender device. That ZIP is then encrypted and transferred like a normal file.
Responsible use
The share code is the sensitive part. Do not post it publicly, leave it visible in screenshots, or share it through an untrusted channel for sensitive files.
Privacy and terms
File transfer without accounts, ads, or content scanning.
This static website does not require an account to send files. TunnelTransfer is designed so the service provider cannot read file contents.
Content handled
In the web version, file contents are not uploaded to server storage. The sender reads and encrypts the file locally, sends it to the receiver, and the receiver downloads the completed file.
Technical data
WebRTC and PeerJS signaling may temporarily process peer IDs, connection states, and network candidates. These technical details are not enough to decrypt file contents.
Ads and tracking
The interface is not built around advertising or behavioral tracking. Store and social links may point to third parties, whose own privacy policies apply.
Acceptable use
Use TunnelTransfer only for files you are legally allowed to share. Content that violates rights, contains malware, or supports unauthorized access is outside acceptable use.
Service limits
P2P transfer depends on browser, device, network, and privacy settings. Connections may be blocked, interrupted, or slower than expected. Closing the web page ends the active transfer.
Your control
Who can receive the file is determined by who receives the share code. Closing the page or deleting the code prevents future attempts, but someone who already has the code may receive the file during an active transfer.
Anonymous usage counters
The apps and this page count, without identifying anyone, how often they are opened and, in the apps, whether a transfer starts, finishes or fails (with a short fixed error class such as connection failed). A count carries only the platform, the version and that event, never file names, sizes, share codes or any identifier. The server does not store IP addresses; it only counts distinct visitors per day, using a hash that is discarded every day. You can switch the counters off with the switch in the footer or in the app.