Secure Note — Encrypted, No Server
Write a note, encrypt it with AES-256, get a shareable link. The note lives only in the URL fragment — never on any server. Self-destructs after reading.
AES-GCM 256-bit
Note encrypted in browser before the link is generated. Unreadable without the password.
Lives in URL Fragment
The # fragment is never sent to servers. Your note data never reaches our infrastructure.
Self-Destructs on Read
Fragment cleared from URL immediately on open. The link stops working after first view.
How it works — technically
Most "secure note" services store your note on their server (encrypted or not). You trust them not to read it, not to be hacked, and not to hand it over if asked. This tool works differently — there is no server storage at all.
- 1
You write the note and set a password
Your note text is typed locally — nothing is sent to a server at this stage.
- 2
The note is encrypted in your browser
AES-GCM 256-bit encrypts the note using a PBKDF2-derived key. The ciphertext is base64url-encoded.
- 3
A shareable link is generated
The ciphertext is appended to the URL as a fragment: /privacy-tools/secure-note#<ciphertext>. The # fragment is never sent to our server by the browser — it's HTTP spec behaviour.
- 4
The recipient opens the link
Their browser decrypts the ciphertext using the password you share separately. The fragment is immediately cleared from the URL.
- 5
The link is now dead
Without the fragment, the URL is just a blank note page. The note existed only in the URL — it's gone.
Always send the password separately
The security of this tool depends entirely on separating the link and the password. If you send both in the same email, Slack message, or text, anyone who intercepts the message can read the note. Send the link via one channel and the password via another — phone call, Signal, in person.
Frequently asked questions
How is the note stored if there's no server?
The note is encrypted in your browser and the ciphertext is embedded in the URL fragment (the part after the # symbol). URL fragments are never sent to the server by browsers — they exist only in the client. This means the note data never touches our servers at any point.
What does 'self-destruct' mean here?
When someone opens the secure link, the tool immediately clears the fragment from the browser's URL bar using history.replaceState(). The link is now broken — anyone who opens it again sees an empty page. The recipient should copy the note text before closing the tab.
Is the note truly secure?
The ciphertext in the link is protected by AES-GCM 256-bit encryption with PBKDF2 key derivation. Without the password, the note is computationally unreadable. However, security depends on sharing the password through a separate channel — never send the password and the link in the same message.
What should I use this for?
One-time passwords, Wi-Fi passwords, API keys, short confidential messages, temporary credentials, bank account numbers, or any text you want to share securely without it persisting in email threads, Slack, or other message histories.
Can the recipient forward the link?
If the recipient copies the link before opening it, yes. Once they open the link, the fragment is cleared and the link stops working. For maximum security, instruct the recipient to open the link only once and copy the note immediately.
What happens to the note after the link expires?
The encrypted note only exists in the URL — there is no database, no server, no storage. When the fragment is cleared from the URL, the data is gone. There is no way to recover it. The ciphertext was never stored anywhere.