SlothBox seals your file in your browser before it leaves your machine. The unlock key lives in the part of the URL after # — which browsers never send to any server. Audited libsodium primitives only. No telemetry. No accounts.
Drop a file, a folder, or many — encrypted before upload
Up to 1.0 GB · sealed in your browser before upload
Any file type — images, video, docs, .zip & other archives. Everything's accepted.
When this timer runs out, the share link stops working and the encrypted blob is deleted from the server. Pick the shortest window that still gives the recipient time to download.
Self-destructs the moment the FIRST complete download finishes. The link still works for whoever opens it first — but anyone clicking it after, including a forwarded copy, sees a “doesn't exist” page. Two people opening the link in the same instant can race and both succeed; treat this as one-shot delivery to a trusted channel, not an unbreakable single-recipient lock.
Adds a second factor on top of the URL fragment. The recipient needs both the link AND the password to decrypt. The server never sees the password — wrong guesses look identical to a corrupted file, so there is no online brute-force oracle. Send the password through a different channel (Signal, SMS, in-person) than the link.
Against the alternatives
Every option below is a fine product for what it does. None of them gives you confidentiality the operator can't break — that's the gap SlothBox fills.
When you'd reach for this
If any of these match the file you're about to send, SlothBox is the right tool. If none do, email or WeTransfer is probably fine — pick what fits the threat.
An email attachment lives in both inboxes forever. WeTransfer keeps a copy on US infrastructure for seven days. Turn on burn-after-read and SlothBox destroys the share the moment the recipient finishes downloading — the encrypted blob is gone, and because the decryption key never reached the server, even a future backup restore returns ciphertext.
Anything you don't want sitting on US infrastructure for seven days, indexed by an advertising graph, or read by a content-moderation pipeline. EU-hosted by infrastructure choice — not by a region label on a US cloud. The operator cannot decrypt what you upload. A subpoena returns ciphertext.
API keys for a one-time client setup. Infrastructure config. Pre-release builds you don't want a Slack history to retain. No DM kept forever, no GitHub gist that's accidentally public. With burn-after-read on: one link, one download, gone.
No account, no signup. The server hashes the upload IP for rate-limiting and forgets the rest. The recipient gets the URL through whatever channel makes sense. Neither side has an account; the server has no idea who either party is.
Trust comes from architecture
XChaCha20-Poly1305 in your browser, before any byte leaves your device. The key lives in the URL fragment — browsers never send it to any server.
Hosted on Hetzner Cloud in Falkenstein, Germany. Hetzner is a wholly EU-incorporated German company — no US parent, no CLOUD Act exposure. No CloudFront, no Vercel edge, no CDN. Schrems II is not a concern because no part of the data path crosses US jurisdiction.
This repository is the entire production stack. `docker compose up -d` brings the whole thing online on your own machine. Every claim is auditable.
v0.5 ships RFC 3161 timestamped delivery receipts. v1.0 adds verifiable burn-after-read via a public hash chain and an offline `slothbox-verify` CLI.
How it works
Pick or drag a file. Up to 1 GiB per share. Nothing has left your machine yet.
Your browser generates a 256-bit key, slices the file into 5 MiB chunks, and seals each chunk with XChaCha20-Poly1305.
Send the share link over any channel you trust. The decryption key rides in the URL fragment — your recipient's browser unlocks the file on their side.
Every layer, every primitive, every server, every byte — the complete walk-through with an ASCII diagram and the grep commands to verify each claim against the source.
What you give up
Every architectural decision trades something. These are the ones a visitor evaluating SlothBox should know up front.
If their chat client strips fragments (old Outlook, certain compliance scanners, some forum software), they get nothing decryptable. Test with a small file first if you're not sure your channel preserves fragments.
Maximum seven days in v0.2. Expired shares are gone, not soft-deleted — the encrypted blob is removed from MinIO and the share row is destroyed. If the recipient hasn't downloaded by then, you re-send.
The cryptographic primitives — libsodium and age — are battle-tested upstream. The SlothBox glue around them has not yet been independently audited. Independent cryptographer review and a third-party pen test gate v1.0 before any “production-grade” framing.
A one-gigabyte file downloads from one server in Falkenstein, Germany. WeTransfer downloads from two hundred edge points of presence. If your recipient is on a 200 ms link from Tokyo, they will feel it. The trade is bandwidth for jurisdiction — pick what matters more for the file in your hand.
Built to be inspected
Tamper-evident delivery receipts arrive in v0.5: an RFC 3161 timestamp signed over the file hash, anchored in a public Merkle chain. The full source is open — read it before trusting it.