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
Sorry to say but the scary part is how normal it's become to upload sensitive files somewhere and just hope the eventually disappear .
Tools like this make that problem feel a lot more real.
@charlotte_harris2 You are right , but now a days risk is everywhere, we have to survive because we are living in digital era , nothing is impossible to make things at stake.
@james_anderson77 Agree with you
BurnLink
@james_anderson77 True, risk is unavoidable in the digital era. But that's exactly why tools like this matter, we can't eliminate risk, but we can dramatically reduce it. BurnLink won't solve everything, but at least for sensitive file sharing, you get guarantees instead of hope.
@charlotte_harris2 This is not wrong to think first about our own security, but be positive.
BurnLink
@amelia_martin7 You're right, security doesn't have to be doom and gloom. BurnLink is actually pretty optimistic in a way: it's built on the idea that we can control our own security if we're thoughtful about tools. The positivity is in taking action, not ignoring the problem.
BurnLink
@charlotte_harris2 I completely get your point, and honestly that concern is valid. But the difference is in how we’re approaching it. We’re not trying to build another typical file-sharing platform that repeats the same cycle.
Our focus is on privacy between the users involved. When someone shares an important file, there shouldn’t be a third party sitting in between with potential access to it. That’s why we’re working toward a more end-to-end private sharing system where the shared files disappear after delivery and don’t stay on our system, while remaining secure throughout the whole process.
keep commenting, have a good day!
co-founder of @BurnLink
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?
BurnLink
@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.
BurnLink
@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.
BurnLink
@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!
BurnLink
@sk_uxpin Thanks! Really appreciate it