Language: English | ไธญๆ | ะ ัััะบะธะน | Portuguรชs | Espaรฑol | Deutsch | Franรงais | ๆฅๆฌ่ช | ํ๊ตญ์ด | Polski | ุงูุนุฑุจูุฉ
A free and open-source file transfer tool that harnesses the power of cutting-edge peer-to-peer networking, letting you transfer files directly without storing them on cloud servers.
Why rely on WeTransfer, Dropbox, or Google Drive when you can reliably and easily transfer files directly, end-to-end encrypted and without revealing any personal information?
Pick whichever route is closest to hand: send a link or a QR code that opens on any device, send to a device you paired once, or send to a device already on your network. All three move the same bytes the same way - directly, encrypted end to end.
- Cross-platform - Desktop, Android, CLI, and browser - no install on the web
- Any file, any size - Files or folders, BLAKE3-verified
- Multi-gigabit speeds - Saturates fast connections
- Nearby - LAN auto-discovery; Pair & Send
- Paired devices - Pair once with a code (remote) or Nearby; send without tickets
- Resumable & multi-peer - Resume interrupted transfers; share to many at once
- Dial by key - Connect by device identity, not IP address
- Roaming - Switch Wi-Fi, cellular, or networks mid-transfer without dropping
- Code, Link or QR - Receiver needs no install (browser or app)
- Preview & history - See before download; local transfer log
- Advanced debug mode - Opt-in diagnostics for under the hood transparency
- Private - No accounts, tracking, or ads; direct device-to-device
- Encrypted - TLS 1.3 end-to-end; authenticated tickets
- Self-host relays - Unthrottled remote transfers via your own relay (Settings โ Infra)
- Always reachable - Background tray/service, notifications, start at login
- Lightweight & free - Small installs; open source, no limits
| Metric | Reported |
|---|---|
| Largest transfer | 452 GB |
| Fastest large transfer | 54 GB @ 123 MB/s (~1 Gbps) |
| High-speed bulk transfer | 328 GB @ 93 MB/s |
| Peak speed measured | 125 MB/s (1 Gbps) |
Transfer throughput depends on your device, network, and connection path.
The easiest way to get started is by downloading one of the following versions for your respective operating system:
| Platform | Recommended | Other formats | Size |
| ๐ป Windows (x64) | Setup.exe | MSI, Portable ZIP | ~10 MB |
| ๐ป macOS (Universal) | DashBeam.dmg | Apple Silicon, Intel | ~15 MB |
| ๐ป Linux (amd64) | DashBeam.deb | .rpm, AppImage | ~13 MB |
| ๐ฑ Android (arm64) | DashBeam.apk | armv7, universal | ~50 MB |
| โจ๏ธ CLI | Downloads | - | ~4-5 MB |
| ๐ Web (Limited throughput) | app.dashbeam.net | - | ~2 MB |
More options at GitHub Releases or in Downloads page.
Running into problems? See Troubleshooting for common issues and how to collect logs.
We're looking for Partners to join our mission! Partner with us and support while we push the boundaries of peer-to-peer file transfer.
๐บ๐ธ ๐ท๐บ ๐ซ๐ท ๐จ๐ณ ๐ฉ๐ช ๐ฏ๐ต ๐ฎ๐ณ ๐น๐ญ ๐ฎ๐น ๐จ๐ฟ ๐ช๐ธ ๐ง๐ท ๐ธ๐ฆ ๐ฎ๐ท ๐ฐ๐ท ๐ต๐ฑ ๐บ๐ฆ ๐น๐ท ๐ณ๐ด ๐ง๐ฉ ๐ญ๐บ ๐ท๐ธ ๐น๐ผ ๐ฐ๐ญ ๐บ๐ฟ
Same-network apps appear under Nearby in Settings โ Devices and in the Send to a device list while you're sharing. Pick a nearby device and Pair & Send to pair and start the transfer in one step - you can also pair from Settings without sharing. First contact shows a verification code on both screens. Set who can find you in Settings โ Network โ Your discoverability.
Uses mDNS - often blocked on guest Wi-Fi and VPNs. See Troubleshooting if the list stays empty.
Pair in Settings โ Devices with a pairing code (works remotely, over the internet) or via a Nearby request on the same network. After pairing, Send appears next to that device while sharing - no ticket to copy. The receiver gets an in-app prompt. Desktop can keep running in the background and show online paired devices in the tray (Settings โ General โ Startup & background). Manual tickets and the sendme CLI still work.
While sharing: QR for a camera scan, Share for the system sheet, Copy for the raw ticket. Links use https://app.dashbeam.net/receive?ticket=โฆ - on Android they open the app; elsewhere the web app, so nothing to install (large files are better in the native app). Paste a ticket, link, or full share message into Receive.
| DashBeam | Blip | LocalSend | Magic Wormhole | PairDrop | |
|---|---|---|---|---|---|
| Networking | QUIC via Iroh | Unknown | HTTPS/REST over TCP | encrypted TCP | WebRTC/DTLS (SCTP) |
| Works over the internet | โ | โ | LAN only | โ | โ |
| Saturates gigabit connections | โ | โ | LAN only | โ | โ (SCTP/browser ceiling) |
| Discover devices on LAN | โ | โ | โ | โ | โ |
| Persistent paired devices | โ | โ (account) | โ | โ | โ |
| Send folders | โ | โ | โ | โ | โ (CLI only, not in browser) |
| Resumable transfers | โ | โ | โ | โ | โ |
| Roaming mid-transfer | โ | โ | โ | โ | โ |
| Send to multiple receivers | โ (broadcast) | โ | โ | โ | โ |
| Unlimited file size | โ | โ | โ | โ | Limited by browser memory |
| Open source | โ | โ | โ | โ | โ |
| No account required | โ | โ | โ | โ | โ |
| End-to-end encryption | โ | โ | โ | โ | โ |
| Platforms | CLI + desktop + mobile + web | Desktop + mobile (no web/CLI) | Desktop + mobile (no web/CLI) | CLI only | Web/PWA + Android app + CLI |
| The catch | WIP | Closed source; data handling cannot be audited | Same-network only, no resume | CLI-only; GUI front-ends are separate, community-maintained | WebRTC/SCTP throughput ceiling; browser memory limits |
DashBeam is built on Iroh, a modern peer-to-peer networking stack that simplifies direct device-to-device communication. In practice, that means devices talk over encrypted QUIC, files move with content-addressed blobs, and relays help when a direct path isnโt available.
The long version: Under the hood walks the same architecture as a narrative - fingerprints instead of filenames, names instead of addresses, hole punching, roaming, and what each intermediary can and cannot see.
| Piece | What it does here |
|---|---|
Blobs (iroh-blobs) |
Store and stream file data; every chunk is verified with BLAKE3 |
| Tickets | One string that tells a peer who to dial and what to fetch |
| Endpoints | Each deviceโs Iroh identity (Ed25519 key โ endpoint id) |
| QUIC + TLS 1.3 | Encrypted transport; multiplexing without head-of-line blocking |
| Relays + hole punching | Bootstrap connections across NATs; the relay carries data while a direct path is negotiated |
| Control protocol (pairing) | Long-lived channel to remember devices and deliver share invites |
| Local discovery (mDNS) | Optional LAN advertising so Nearby devices can find each other without a ticket |
| Receive links | A ticket wrapped in an ordinary https URL - an App Link on Android, the web app everywhere else |
Files arenโt uploaded to a server. Theyโre published as blobs: opaque byte sequences addressed by a BLAKE3 hash.
- A link is that 32-byte hash: if the hash matches, the content matches.
- Folders and large files use a HashSeq (a blob that points at other blobs).
- The sender is the provider; the receiver is the requester. Either side can do both.
Because that hash is a BLAKE3 tree rather than one digest over the whole file, every chunk verifies on its own against the root. That is what makes resume cheap: a receiver coming back after a dropped connection knows exactly which chunks it already holds and has verified, so it asks only for the gap. Nothing already received is re-sent, and nothing arriving is taken on trust.
A share ticket is a single token that packs:
- The senderโs endpoint id (so you know youโre talking to the right device)
- Enough address / relay info to dial them
- The blob hash to download
You only connect to people you share a ticket with: no broadcasting your IP to strangers. Thatโs the default โcozy networkโ model Iroh encourages, vs. flooding discovery to the whole swarm.
Tickets that carry only an endpoint id lean on public-key discovery (Pkarr) to find current addresses. Those records are signed by the endpoint key itself, so a tampered one fails verification rather than misdirecting you - the lookup service is trusted for availability, not integrity.
When two devices need to meet:
- Each registers with a public (or self-hosted) relay so peers can find a path through firewalls and NATs.
- Iroh tries QUIC hole punching to upgrade to a direct peer-to-peer link.
- If a direct path works, traffic moves over to it. If not, the relay stays in the path as a fallback UDP hop.
Those steps overlap rather than queue. The relay is already carrying your data while hole punching negotiates, so nothing waits on the direct path to succeed - the transfer just gets faster if and when it does. Roughly one transfer in ten never gets a direct path at all (symmetric NAT, locked-down corporate networks) and rides the relay start to finish.
Either way, the payload is end-to-end encrypted. Relays see ciphertext, not your files. More on Iroh relays โ
A connection is bound to the peerโs key, not to its IP address, so changing networks does not end it. Switch from Wi-Fi to cellular mid-transfer and iroh notices the address change, learns the new candidates, and republishes them to the peer. The relay carries the data throughout, and hole punching simply runs again on the new path.
Addresses are disposable hints, not identity. That is the practical payoff of naming devices by key instead of by location.
QUIC (UDP-based, same foundation as HTTP/3) brings TLS 1.3 into the transport. For DashBeam that buys encryption and authentication, multiple streams with shared congestion control, and fast reconnects when youโve talked to a peer before.
Pairing doesnโt replace tickets; it delivers them for you.
- Devices exchange a short pairing code (the hostโs endpoint id) over a dedicated control ALPN.
- Each side proves identity by signing connection-bound keying material with its device secret, then remembers the peer locally.
- A persistent control connection keeps presence (online/offline).
- When you share, DashBeam still creates a normal one-time blob ticket; choosing a paired device ships that ticket as an in-app invite instead of making you copy-paste it.
Manual tickets and the sendme CLI keep working exactly as before.
On the same local network, DashBeam can advertise and browse peers with mDNS (desktop and Android; not the web app).
- When discoverability is Everyone, the device publishes enough metadata for others to show its name in Nearby.
- Paired only still announces presence without exposing the display name to strangers on the LAN.
- Off stops advertising; you can still browse and send to others who remain discoverable.
- First-contact file invites show a short verification code derived from both devices' public keys so each side can confirm they're talking to the intended peer before accepting.
- Accepting a Nearby pair request or file invite creates the same local paired-device records as code-based pairing.
For how to run your own iroh relay and discovery server, configure DashBeam to use them, and how mixed public/self-hosted setups behave, see infra/README.md (relay: infra/relay/README.md, discovery: infra/dns/README.md).
For the illustrated version of everything above - including a full account of what a relay operator, your ISP, and the lookup service each learn from a transfer - read Under the hood.
See CONTRIBUTING.md for prerequisites, local setup, build instructions, and testing.
Join our Discord to contribute
The best way to contribute is to join our Discord and say hi. Introduce yourself and share what skills or interests you have - whether thatโs coding, testing, design, or something else. You can also raise issues, suggest fixes, or pitch ideas. Maintainers are there to guide you every step of the way.
Itโs the best place to get context, align on direction, and collaborate with the community.
AGPL-3.0
See PRIVACY.md for information about how DashBeam handles your data and privacy.
Reach me here for suggestions, feedback or media related communication.
Thank you for checking out this project! If you find it useful, consider giving it a star and helping spread the word.
