Tutorial
How Blixt works.
A Blixt transfer is three moves: create a code, share it, verify six digits. This page walks through each step — what you see on screen, what the code actually is, and what the security check protects you from. The desktop app is the primary interface; the local web UI and the blixt CLI follow the same flow.
Pick files, press Send, get a code.
The sender chooses what to move — one file, a batch, or whole folders — and presses Send. In the desktop app that is the first button on the first screen; in the local web UI it is the same action, and in a terminal it is blixt send dataset.tar.
Blixt immediately creates a transfer code — a private invitation that looks like ocean-vivid-eager-…. It is not a password you chose and not a link to an upload: the code is generated from at least 130 bits of cryptographically secure randomness, so guessing a live code is not a practical attack. Nothing has been uploaded anywhere at this point — the app simply shows the code (with a copy button and a QR) and waits for the other side.
Share the code over any channel.
Send the code however you like — chat, email, a voice call, or show the QR when you are in the same room. Blixt does not care which channel you use: the code is only the invitation that lets the two apps find each other. Treat it like one — share it with the person you actually mean to receive the files.
The receiver enters the code and presses Receive — in the desktop app, in the local web UI, or with blixt recv --code "ocean-vivid-…". The two apps then coordinate the route: a direct peer-to-peer path first (QUIC over UDP), direct HTTPS when UDP is blocked, and an encrypted relay only when the networks allow nothing better.
Compare six digits, then watch it move.
Once the connection is established, both screens show the same 6-digit security code (SAS). It is derived from the encrypted session itself, so both sides can only see matching digits if the session really ends at each other’s device. Read it to each other over a channel Blixt’s servers never touch — voice, chat, in person. If anyone sits in the middle, even a compromised signaling server, the digits diverge and you hang up before any file data moves.
With the digits confirmed, the transfer runs end-to-end encrypted — AES-128-GCM, AES-256-GCM or ChaCha20-Poly1305 over TLS 1.3 — while the app shows progress, speed and time remaining. Every block is verified with BLAKE3 as it arrives, and if the connection drops, Blixt reconnects and continues with only the verified blocks still missing.
Get the most out of Blixt
Direct paths, QUIC and a couple of settings decide how fast a transfer runs. Tips for fast transfers →