🔥 Frequently Asked Questions

Burning Notes is a self-destructing, encrypted message and file sharing service. You create a note or upload a file — it gets encrypted and stored on the server. You receive a one-time link. When the recipient opens the link, the content is decrypted and immediately and permanently deleted from the server. Nobody — not even the server operator — can read it again.

Anyone who needs to share sensitive information once without it persisting anywhere:

• Passwords, API keys, or credentials
• Private messages you don't want stored in email or chat history
• Confidential files or documents
• Screenshots containing sensitive data
• One-time authentication codes or secrets

The moment the recipient clicks "Open & Destroy", the server performs three steps atomically in a single database transaction:

1. Reads and decrypts the content
2. Deletes the database row permanently
3. Returns the decrypted content to the browser

The deletion uses a FOR UPDATE lock to prevent race conditions — even if two people open the link at the exact same millisecond, only one will succeed. The other sees "Note not found."

Yes. When creating a note, you can set Max reads from 1 to 10. The default is 1 (single-read, classic behaviour). With a higher value, the same link can be opened multiple times — the server decrements the counter on each read and deletes the note only when the counter reaches zero.

The recipient sees how many reads remain both on the warning screen and after opening.

By default, encryption happens server-side using AES-256-CBC:

1. A 64-character random hex token is generated (bin2hex(random_bytes(32)))
2. The first 32 characters are the lookup key — its SHA-256 hash is stored in the database
3. The last 32 characters are the AES key — never stored, only in the link
4. A random 16-byte IV is generated for each note
5. Content is encrypted with AES-256-CBC using the AES key and IV
6. Only the ciphertext and IV are stored in the database

The decryption key exists only in the URL. Without the link, the stored data is meaningless.

Zero-Knowledge mode goes one step further: encryption happens entirely in your browser before any data is sent to the server.

• Your browser generates a random AES-256-GCM key using the WebCrypto API
• The text is encrypted locally — the server only receives unreadable ciphertext
• The decryption key is embedded in the URL fragment (#k=...)
• Fragments are never sent to the server by browsers (it's part of the HTTP standard)
• Even a full server compromise cannot expose the content

Important: When sharing the link, always share the complete URL including the #k=... part. If the fragment is missing, decryption is impossible — there is no recovery.

Standard mode: In theory, yes — the server performs decryption and briefly holds the plaintext in memory before sending it to the browser. A malicious operator with server access could log the plaintext at that moment. In practice, this server is self-hosted and privately operated with no third-party access.

Zero-Knowledge mode: No. Decryption is entirely client-side. The server stores only ciphertext and an IV. The decryption key never touches the server. Even with full database access, the content cannot be read.

Over HTTPS: The link is always transmitted encrypted via TLS, so it's protected from network interception.

Over plaintext channels (email, SMS): Anyone who intercepts the link can open the note before the intended recipient. For maximum security, share the link via one channel and confirm delivery via another (e.g., share over email, confirm arrival by phone).

The one-time nature is also a detection mechanism: if your recipient says they never received it but the note shows "already read", someone intercepted it.

Any file type is accepted. There is no restriction on format. The maximum size is 10 MB per upload (or combined if bundling multiple files).

You can also drag & drop files directly onto the file zone, or paste a screenshot with Ctrl+V — the image is automatically converted to a clean PNG via canvas before upload.

Multiple files are automatically bundled into a ZIP archive server-side using PHP's ZipArchive. The ZIP is then encrypted as a single unit, just like a single file. When the recipient opens the link, the ZIP is downloaded — they can then extract all the original files.

Images (image/* MIME types) are displayed inline in the browser after decryption — no download required. Other file types trigger a direct binary download with the original filename preserved.

For clipboard screenshots, the image is passed through a canvas element before upload to guarantee it's always a valid PNG, regardless of the clipboard format used by the operating system.

No. Notes are deleted the moment they are read (or when the read counter hits zero). There is no backup, no log of note contents, and no way to recover deleted notes.

Only metadata that cannot be avoided is stored: a SHA-256 hash of the lookup key (not the note content), the encrypted content, the IV, optional MIME type and filename, and a creation timestamp. None of this reveals the content without the URL token.

The note remains on the server until someone opens it — there is no automatic expiry by default. However, without the link, the stored data is encrypted and cannot be recovered.

If you lose the link, create a new note. The old encrypted entry will remain in the database until it is read by whoever eventually has the link (or potentially forever if no one does).

No cookies. No analytics. No tracking pixels. No external resources except the QR code library loaded from a CDN (Cloudflare cdnjs) — and only when you click the QR button. That CDN request contains no note content; it only fetches a JavaScript file.

Zero-Knowledge notes do not involve any external requests at all.