How to Send Large Files Securely — No Limit, E2E Encrypted
Most services cap free file transfers at 2 GB (WeTransfer) or 25 MB (email). Even paid tiers rarely exceed 100 GB and require your file to sit on their servers. DropLink has no limits and never uploads anything to the cloud — files go directly from sender to receiver, end-to-end encrypted.
Quick answer
DropLink has no imposed file size limit and we have tested single transfers up to 100 GB. Files transfer peer-to-peer (LAN via QUIC, internet via iroh with DERP fallback) with end-to-end encryption (TLS 1.3 on LAN, Noise IK + curve25519 + BLAKE3 verified streaming on the internet). Add an optional password and you get a second access layer. No cloud, no size limit, no expiration because nothing is stored server-side.
Step-by-step
- 1
Install DropLink on the sender
Download the free DropLink app for macOS or Windows. It's under 50 MB and works without an account.
- 2
Enable password protection (optional but recommended)
In DropLink, toggle Proteggi con password. Set a strong password — the receiver will need it to unlock the transfer. This adds another layer on top of the built-in end-to-end encryption.
- 3
Drag your large file or folder
DropLink has no file size limits. Drag a 50 GB video or an entire project folder — it's all fine. Folders are automatically compressed to ZIP with adaptive compression.
- 4
Select the recipient
If the recipient is on your LAN, pick them from the DropLink Vicini list. If they are remote, they can receive via the Web UI — just send them the link.
- 5
Transfer happens P2P with E2E encryption
Files transfer directly between the two devices. QUIC + TLS 1.3 on LAN, or the Noise protocol with curve25519 keys on remote transfers. No server ever sees your files.
- 6
Receiver gets the files — verified
DropLink uses BLAKE3 hashing to verify file integrity in real-time. If anything is tampered with or corrupted during transfer, the recipient will know immediately.
Common issues with large files
- Disk runs out during zip
DropLink pre-checks destination disk space (total size + 100 MB buffer) before creating the zip. If you see the pre-check fail, free up space on the target drive (not source). For very large folders, consider sending uncompressed by selecting individual files rather than the parent folder.
- Transfer slows down after a while
This is usually thermal throttling on the sender or receiver CPU (encryption is CPU-intensive). On laptops, ensure adequate cooling. Check also that no backup process kicks in mid-transfer (Time Machine, Windows Backup) — it will compete for disk I/O.
- Internet transfer drops mid-file
Large internet transfers are more sensitive to routing changes. DropLink uses QUIC's connection migration where possible; if the connection fully drops, you can restart the share — the receiver will re-download remaining chunks only (BLAKE3 verified streaming means already-received chunks do not need re-downloading on retry within the same session).
How very large transfers work
Streaming, not uploading
Unlike WeTransfer or cloud services, DropLink does not upload the file anywhere — it streams chunks directly from sender to receiver. The relay server only coordinates the handshake. On LAN this uses QUIC; on the internet iroh opens a QUIC connection (direct P2P after NAT hole-punching, or via DERP relay if hole-punching fails). In both cases the bytes pass through at network speed; there is no 'upload complete then download' cycle.
BLAKE3 verified streaming (Bao tree)
For iroh-based transfers, every file is identified by its BLAKE3 hash. The sender advertises the hash; the receiver downloads blocks and verifies each block against the hash tree before accepting it. This is called 'verified streaming' (via the bao-tree 0.16 library) — integrity is checked incrementally, not at the end. A malicious relay cannot tamper with bytes without the receiver detecting it immediately and aborting the transfer.
Compression is adaptive
For folders, DropLink zips on the fly with adaptive compression: Deflate level 6 for text/code, Deflate level 1 (fast) for files larger than 10 MB, and Stored (no compression) for file types that would not compress (jpg, mp4, zip, mp3, etc.). This avoids wasted CPU on already-compressed data. The IO buffer is 1 MB to reduce syscalls on large files. Before creating the archive, DropLink checks the destination has enough disk space (total bytes + 100 MB buffer) via statvfs (Unix) or GetDiskFreeSpaceExW (Windows).
Progress, ETA, and cancellation
The progress tracker is lock-free (AtomicU64 / AtomicBool) for zero-overhead updates. Velocity is computed with EWMA (exponentially weighted moving average), sampled every 200 ms or more, which gives smooth, non-oscillating speed and ETA readings. Cancellation is instant: an AtomicBool flag flips, the CountingReader returns Interrupted, and the QUIC stream is reset with CANCEL_BY_LOCAL = 1.
What speed to expect for very large files
On a Gigabit Ethernet LAN, sustained 100+ MB/s is typical — a 50 GB file transfers in roughly 8 minutes. On Wi-Fi 5/6 LAN, expect 50+ MB/s (50 GB in ~17 minutes). On internet P2P transfers, the sender's upload speed is usually the bottleneck: at 100 Mbit upload, 50 GB takes ~75 minutes. QUIC resumes with 0-RTT on reconnection, so brief network blips do not restart the whole transfer.
- 50 GB on Gigabit Ethernet
- ~8 minutes
- 50 GB on Wi-Fi 6 LAN
- ~17 minutes
- 50 GB on 100 Mbit upload (internet)
- ~75 minutes
- Session resume handshake
- 0 RTT
- Max single file tested
- 100 GB
How large transfers stay secure
The same encryption layers apply regardless of size: TLS 1.3 on LAN with TOFU fingerprint verification, Noise (IK) + ed25519 + curve25519 on the internet, BLAKE3 verified streaming on iroh transfers. BLAKE3 is especially important for large files: it ensures every chunk is exactly what the sender authored — zero byte-level tampering is possible, even by the relay. Optional password protection adds access control: the relay holds a SHA-256 hashed session token (UUID) with a configurable TTL (default 3600 s), protected by rate limiting and brute-force metrics.
Technical FAQ
Is there really no size limit?
No imposed limit. The practical limits are: the receiver's free disk space, the sender's willingness to keep the app open, and for internet transfers, the slower side's bandwidth. We have tested 100 GB single-file transfers successfully.
Is it safer than uploading to a cloud?
Generally yes. Cloud uploads are encrypted in transit and at rest on the provider's servers, but the provider can technically access the files. DropLink transfers are end-to-end encrypted and nothing is stored server-side — the relay only sees Noise-encrypted QUIC packets when direct P2P fails, and cannot decrypt them.
Should I enable password protection for large transfers?
For a one-on-one share over the internet, password protection is recommended. It adds a shared secret that the receiver must enter before the relay grants a session token, which is useful if the share link is sent through a less-secure channel (SMS, email). The password is hashed with SHA-256 server-side; the token TTL is 3600 s by default.
What happens if the transfer gets interrupted?
QUIC tries to migrate the connection transparently on brief network changes. For full disconnections, you can restart the share: on iroh transfers, BLAKE3 verified streaming lets the receiver keep the bytes it already verified and re-fetch only the missing chunks within the same session. For LAN transfers with an HTTP fallback, range requests enable resumable downloads.