BurnLink – Share Files Like They Were Never There
The open-source file sharing tool for people who actually care about privacy.
Ever sent sensitive data through email? Or watched your files sit on someone's cloud forever? We built BurnLink because the alternative to privacy shouldn't be inconvenience.
The Problem
Most file sharing services are built for convenience - not trust. Your files sit on company servers, encrypted (maybe), logged (definitely), and stuck in someone's infrastructure indefinitely.
Meet BurnLink
Zero-knowledge, end-to-end encrypted file sharing. No accounts. No traces. 100% open source.
What makes it different:
Files burn after first download — single-use links that delete immediately after access
Client-side encryption — AES-256-GCM encryption happens in your browser before upload. Server sees zero.
No accounts needed — Click, upload, share, done
Password protection — Add an extra security layer
View-once mode — Recipients have 60 seconds to view before auto-deletion
Download mode - Automatically delete after one time use
Brute-force protection — Built-in defense against attacks
Fully open source — Audit the code, self-host it, modify it—it's yours
Up to 1GB files — Direct uploads, no slowdowns
Who Uses It?
Sending API keys and credentials safely
Sharing confidential documents with clients
Team members exchanging sensitive configs
Anyone who wants their data to actually disappear
What's New in v1.2.0?
Improved performance, enhanced security audits, and better self-hosting documentation. Full transparency—all changes reviewed by the community.
Try it: burnlink.page
Self-host: https://github.com/paperfrogs-hq/burnLink/
MIT License — deploy it anywhere, modify it freely.
Replies
That's a great idea. We are building products in a similar space.
I'm curious do you require accounts for sending and receiving files? How do you control who can have access to a specific file?
@diego_2r87 No accounts required for either side, that's core to our design philosophy.
Access control works like this:
Each file gets a unique share link (URL with an embedded encryption key)
Only people with that link can access the file
Optional password layer on top if you want extra security
Single-use only—once downloaded, the link dies permanently
The server never sees the decryption key (it's in the URL fragment, never sent to us)
So access control is purely URL-based + optional password. No user management, no permission systems, no databases tracking "who has access to what." If you don't want someone accessing a file, you just don't send them the link.
@diego_2r87 Thanks so much! You nailed the risk assessment perfectly.
Exactly, the URL interception + timing requirement makes it practically unfeasible. And the beauty is, if someone does somehow intercept it, they still can't decrypt the content (they'd need the encryption key, which is different from the URL fragment in actual deployment).
The trade-off is intentional:
Most competitors add database tracking "for convenience," which defeats the purpose.
@diego_2r87 The short answer: Yes, the client needs everything to decrypt, so it's in the URL. The key detail is that it never touches our servers, it stays in the browser.
But I don't want to dive too deep into architecture here. The full technical breakdown is in our GitHub repo if you want to audit the code directly. That's actually the best way to verify how it works, way better than me explaining it in comments.
What I can say: we've designed it so the server genuinely cannot decrypt files, and the trade-off is that URL security matters. That's why we recommend HTTPS, password protection, and single-use links.
Check the code if you want the full picture, that's the whole point of being open source.
Sounds impressive, thanks for sharing - will give it a shot!
@sk_uxpin Thanks! Really appreciate it