About Burnvelope

A secure, open-source way to share sensitive information. Built with privacy as the foundation, not an afterthought.

The Problem

We've all been there. You need to share a password, an API key, or some sensitive information with a colleague or friend. What do you do? Email it? Send it over Slack or Discord? Text it?

All of these options have the same fundamental problem: the message persists. It sits in inboxes, chat logs, and text histories indefinitely. It gets backed up, synced, and potentially exposed in data breaches.

Even "encrypted" messaging apps often store message history on their servers. And let's be honest—we've all scrolled through old conversations looking for that password someone sent us months ago.

The Solution

Burnvelope takes a fundamentally different approach. Instead of trying to secure persistent messages, we eliminate persistence entirely. Your secret exists only until it's viewed—then it's gone forever.

But more importantly, we designed Burnvelope so that we can never see your secrets. Even if our servers were compromised, even if we were compelled by law enforcement, we literally cannot access the plaintext of your sensitive information.

How It Works

1

Client-Side Encryption

When you enter a secret, your browser generates a random 256-bit encryption key and encrypts your secret using AES-256-GCM—the same encryption standard used by governments and banks worldwide.

This happens entirely in your browser. The plaintext never leaves your device.

2

Server-Side Double Encryption

The already-encrypted data is sent to our server, where we encrypt it again with our own key using HKDF key derivation and AES-256-GCM with a unique salt per secret.

This double encryption means that even if either key is somehow compromised, your data remains protected by the other layer.

3

The Magic of the URL Hash

Here's the clever part: the client-side encryption key is placed in the URL hash (the part after the #). For example:

https://burnvelope.com/view/abc123#YourSecretKey

By design, browsers never send the hash fragment to the server. This is a fundamental part of how URLs work. The key travels with the link but never touches our servers.

4

Retrieval & Destruction

When someone opens your link, they retrieve the double-encrypted data from our server. At that moment, we immediately and permanently delete it—no backups, no logs.

Their browser then decrypts the server layer (using data in the response) and the client layer (using the key from the URL hash) to reveal the original secret.

Security Model

Zero-Knowledge Architecture

We cannot read your secrets. The encryption key never touches our servers. We only ever see encrypted ciphertext that is meaningless without the key embedded in your link.

AES-256-GCM Encryption

We use authenticated encryption that provides both confidentiality and integrity. Any tampering with the ciphertext will be detected during decryption.

Immediate Deletion

Secrets are deleted from our database the instant they're retrieved. There's no grace period, no soft delete, no way to recover. When it's gone, it's gone.

Automatic Expiration

Unviewed secrets automatically expire after your chosen time limit (up to 7 days). We use Cloudflare KV's TTL feature, so expiration happens at the storage level—not via a cleanup job that might miss something.

Data Lifecycle

Created

Double-encrypted secret stored in Cloudflare KV with TTL

→

Waiting

Secret exists until viewed or TTL expires

→

Deleted

Immediately and permanently removed—no traces

What we don't store:

  • Your plaintext secrets (we never see them)
  • The encryption keys (they stay in the URL hash)
  • Access logs with IP addresses
  • Backups of deleted secrets
  • Any personally identifiable information

Open Source

Burnvelope is completely open source. You can review every line of code, verify our security claims, and even host your own instance if you prefer.

We believe that security software should be transparent. "Trust us" isn't good enough when it comes to your sensitive data. You should be able to verify.

View on GitHub

About the Creator

Shawn Lehner

I built Burnvelope because I was tired of the friction and risk involved in sharing sensitive information. As a developer, I frequently need to share API keys, credentials, and other secrets with team members—and I wanted a solution I could actually trust.

This project is a labor of love, built with security and privacy as the core principles. It's free, open source, and always will be.

Visit my website →

Ready to share securely?

Create a secret link in seconds. No signup required.

Create a Secret Link