What is BurnLink

Share files that self-destruct.

BurnLink is a zero-knowledge file sharing tool. Your files are encrypted entirely in your browser before leaving your device. We store only the encrypted payload — and delete it the moment it's accessed.

Four steps, zero exposure

The entire encryption and decryption process runs locally in your browser. The server never touches your plaintext data.

Step 01

Encrypt in-browser

Your file is encrypted in your browser with AES-256-GCM before a single byte leaves your device.

Step 02

Upload ciphertext only

Only the encrypted payload is uploaded. The decryption key never reaches our servers.

Step 03

Share the link

You receive a one-time link. The decryption key travels only in the URL fragment — invisible to servers and logs.

Step 04

Auto-destruct

The encrypted file is permanently deleted the moment the recipient accesses it. The link is dead forever.

Built for security

Every feature exists to protect your privacy, not compromise it.

Encryption AES-256-GCM

Industry-standard authenticated encryption. Files are encrypted in your browser using the Web Crypto API — no third-party libraries involved.

Access One-time links

Each link is invalidated after a single access. Subsequent visits return a permanent 410 Gone — the file simply no longer exists.

Modes Download & View-once

Download mode saves the file to your device. View-once mode renders it in a protected in-browser viewer and destroys it when closed.

Auth Password protection

Add an optional password. Wrong guesses trigger a 10-minute lockout after 3 attempts. The raw password never leaves your browser.

Privacy Zero knowledge

The decryption key is embedded in the URL fragment. Fragments are never sent to servers, never logged, never seen by us.

Limits Up to 1 GB

Share files up to 1 GB. Large files upload directly to encrypted cloud storage, bypassing any serverless size cap.

What actually happens

  • Files are encrypted using AES-256-GCM via the browser's native Web Crypto API. A random 96-bit IV is generated per file.
  • For link-key mode, a 256-bit random key is generated in-browser. The key is encoded as a URL fragment so it never reaches any server.
  • For password mode, a key is derived using PBKDF2-SHA256 with 210,000 iterations and a random 128-bit salt stored in the envelope.
  • Encrypted data is stored with a custom binary envelope header that the server validates before accepting any upload.
  • Database records are deleted atomically before the file is served, preventing race conditions on concurrent download attempts.
  • Storage objects are deleted immediately after successful download. No retention, no archiving, no backups of your content.

Why the URL fragment?

HTTP specifications define the URL fragment (#…) as client-side only. Browsers never include it in requests to servers. This means the decryption key in your BurnLink URL is structurally invisible to our servers, CDNs, and access logs — by protocol design, not by policy.

Even if our entire infrastructure were compromised, an attacker cannot recover your plaintext without the key, which exists only in the URL you shared.

Why we built it this way

These aren't marketing claims — they're constraints that shaped every technical decision.

01
Encryption is not optional

Data is always encrypted before upload. There is no "unencrypted mode", no admin override, no backdoor. If you lose your link key, the file is unrecoverable — by anyone, including us.

02
One access, then gone

The database record is deleted atomically before the file is delivered. Subsequent requests return 410 Gone. There is no concept of multiple downloads per link.

03
Minimal footprint

We store exactly what we need: the encrypted payload and a salted hash of your server auth token (not your password). No analytics on file content, no IP logging tied to files.

04
Security by design

Rate limiting, brute-force lockouts, strict security headers, and input validation aren't features — they're baselines. Responsible disclosure is always welcome via our security policy.

256
AES key bits
210k
PBKDF2 iterations
1 GB
Max file size
0
Files retained after access
Share a file Security policy Hall of fame