How do encrypted notes work? They scramble your text with a secret key so it reads as gibberish to anyone without that key. Good tools protect the note in transit with HTTPS and encrypt it at rest on the server; some also encrypt end-to-end. Self-destructing notes add deletion after reading, so nothing is left to steal later.
Key takeaways
- Encryption turns your text into unreadable ciphertext. Only someone with the matching key can turn it back.
- In transit, at rest and end-to-end encryption each protect against different threats. Check which ones a tool actually uses.
- SecureNotes encrypts each note at rest with its own AES-256 key and sends it over HTTPS. The service manages those keys, so you are trusting it with the note.
- Self-destruction matters as much as encryption. A note that no longer exists can't leak later.
- Send any passcode through a different channel than the link, and never assume 'encrypted' means nobody else can read it.
How do encrypted notes work?
Every encrypted note starts as plain text: a Wi-Fi password, an alarm code, a sentence you'd rather not leave in a chat history. Encryption runs that text through a mathematical recipe called a cipher, together with a secret value called a key.
The output is ciphertext, a block of characters that looks random. Without the key, nobody can turn it back into your message in any practical amount of time. With the key, it decrypts in a fraction of a second.
Most note encryption today uses AES-256, a widely used and heavily studied standard. The 256 refers to the key length in bits. Guessing a key that long by brute force isn't realistic.
So when you compare encrypted notes online, the useful question isn't whether a tool is encrypted. Nearly everything is. The questions are: where does the encryption happen, who holds the key, and how long does the encrypted copy stay around?
Encryption in transit, at rest and end-to-end: what's the difference?
Note encryption can happen at three different points. Each one protects against a different kind of snooping, and tools often mix them.
Encryption in transit
This protects your note while it travels between your device and the service. On the web, that means HTTPS, the padlock in your browser's address bar.
It stops someone on the same café Wi-Fi, or anyone along the network path, from reading your note as it passes. It does nothing once the note arrives at the server.
Encryption at rest
This protects the note while it sits in storage. The service encrypts it before writing it to disk, so a stolen drive or a leaked database backup shows only ciphertext.
The catch: the service manages the keys, so it can decrypt notes when it needs to, such as when your recipient opens the link. You're trusting the operator to handle those keys well. OWASP's cryptographic storage guidance covers what doing that properly involves.
End-to-end encryption
Here the note is encrypted on the sender's device and decrypted only on the recipient's. The service in the middle stores and passes along ciphertext it can't read.
That protects you even from the service itself. It doesn't protect you from a compromised phone, a screenshot, or sending the note to the wrong person.
| Layer | Protects against | Doesn't protect against |
|---|---|---|
| In transit (HTTPS) | Eavesdroppers on public Wi-Fi or the network path | Anyone with access to the server once the note arrives |
| At rest | Stolen disks, leaked database copies, backup exposure | The service operator, who manages the keys |
| End-to-end | The network and the service itself | Compromised devices, screenshots, wrong recipients |
| Self-destruct / expiry | Old copies being found or breached months later | Whatever the recipient does with the text after reading |
How does SecureNotes encrypt a note?
When you create a note on SecureNotes, it travels to the service over HTTPS. Before it's stored, it's encrypted with AES-256 using a random key generated for that note alone.
One note, one key. If a single key were ever exposed, it would open that note and nothing else.
The encryption is applied by the service when the note is stored, so you're trusting SecureNotes with your note in the same way you trust an email provider or a cloud drive.
For most everyday secrets, such as a door code, a temporary password or a booking reference, that trade-off is reasonable. The bigger protection comes from the next layer: the note doesn't stick around.
Why does self-destruction matter as much as encryption?
Encryption protects a copy. Deletion removes it. A password sitting encrypted in an inbox for three years is still a password sitting in an inbox.
With SecureNotes, you choose when the note is destroyed: after 1, 3, 5 or 10 views, after 1 hour, 24 hours, 7 days or 30 days, or whichever comes first. After that, the link stops working.
Most people pick the strictest setting. In SecureNotes data, 70% of notes are set to self-destruct after a single view, and 17% add a passcode on top.
Single-view links have a useful side effect. If someone else opens the note first, your recipient finds a dead link, and you know something went wrong. This is the core idea behind any one-time secret link: it can't stop interception, but it makes interception visible.
How to send an encrypted note online, step by step
Here's the safe way to send a secret with a self-destructing note.
- Paste your text. Go to SecureNotes and create a self-destructing note. No account is needed. Notes can be up to 10,000 characters of text.
- Choose when it self-destructs. For a one-off secret, pick 1 view. Add a time limit too, such as 24 hours, so an unopened link doesn't sit live for weeks.
- Optionally add a passcode. The recipient must enter it before the note opens. Use one for anything you'd hate to see leak.
- Turn on read notification if you want it. SecureNotes can email you when the note is opened, so you know it arrived.
- Send the link. Copy it into a message, or let SecureNotes email it to the recipient for you.
- Send the passcode another way. If the link went by email, read the passcode out on a phone call or send it by text. Never put both in the same message.
What does this look like in a real situation?
Priya is going away for a week. Tom, a pet sitter she found through a neighbour, needs her house alarm code and the code for the key lockbox by the back door.
She doesn't want those codes sitting in her text history with someone she's only met once. So she pastes both into a new note with a short line: "Alarm panel is in the hallway. Lockbox is left of the back door."
She sets it to destroy after 1 view or 7 days, whichever comes first. She adds a passcode, has SecureNotes email the link to Tom, and turns on the read notification.
Then she calls Tom and tells him the passcode out loud. Tom opens the email, sees a page asking for a passcode, types it in and reads the note. He saves the codes in his phone's notes before closing the page.
Priya gets an email saying the note was read. The link is now dead. If Tom had told her it wasn't working, she'd know someone else had opened it and would change the alarm code before leaving. There's more on this pattern in our guide to passcode-protected notes and how to send the passcode safely.
What can still go wrong with encrypted notes?
Encryption is rarely the weak point. People are. These are the mistakes that actually cause leaks.
- Sending the passcode with the link. If both sit in the same email, anyone who reads that email gets everything. The passcode only helps when it travels separately.
- Assuming "encrypted" means end-to-end. Many tools encrypt only in transit and at rest. Check what a service actually says before trusting it with something it shouldn't be able to see.
- Choosing loose settings. Ten views and 30 days means a forwarded link stays useful for a month. Use the fewest views and shortest time that will realistically work.
- Sending to the wrong person. No cipher protects a link pasted into the wrong chat. Double-check the recipient before you hit send.
- Forgetting what happens after reading. The recipient can screenshot, copy or write down the note. Self-destruction removes the link, not their copy.
- Not acting on a dead link. If your recipient says the note was already gone, treat the secret as exposed and change it.
- Infected devices. Malware on either end can read the note as it's displayed. Encryption can't help there.
When is an encrypted note the wrong tool?
A self-destructing note is built for one job: getting a secret from one person to another once, without leaving a copy behind. It's not the answer to everything.
- Logins you share for months. If a team uses the same account every day, a password manager with shared vaults is better. See one-time links vs password vaults for how to choose.
- Ongoing private conversations. For back-and-forth chat where you want the service itself locked out, use an end-to-end encrypted messenger such as Signal.
- Paying someone. Don't send card numbers in any note if a payment link, invoice or phone call to a verified number will do.
- Files. SecureNotes handles text only, with no attachments. Documents need a different tool.
- Secrets that must be hidden from every provider. If your threat model includes the service itself, choose a tool that is genuinely end-to-end encrypted and says so clearly.
For everything in between, such as a code for a contractor, a temporary password for a relative or a recovery phrase you need to hand over once, an encrypted note that destroys itself is a simple, sensible fit.
Frequently asked questions
Can encrypted notes be hacked?
The encryption itself, such as AES-256, isn't realistically breakable by guessing the key. Real-world leaks happen around it: a link forwarded to the wrong person, a passcode sent in the same message, malware on a device, or a service mishandling its keys. Short expiry, single-view links and a separately sent passcode reduce those risks far more than a stronger cipher would.
Is AES-256 encryption secure enough for personal notes?
Yes. AES-256 is a widely used, heavily studied standard, and there is no practical way to brute-force a 256-bit key. For personal notes, the cipher is not the weak point. What matters more is who holds the key, how long the encrypted copy is kept, and whether the link and any passcode reach only the person you intended.
Can the recipient save an encrypted note after reading it?
Yes. Once the note is displayed, the recipient can copy the text, take a screenshot or write it down. Self-destruction removes the link and the stored note, not anything the recipient chooses to keep. Only send secrets to people you trust with them, and change passwords or codes later if that trust changes.
What happens to an encrypted note after it expires?
On SecureNotes, a note is destroyed once it hits the view limit or time limit you chose, whichever comes first. After that, the link stops working and shows the note is no longer available. If your recipient reports a dead link they never opened, assume someone else viewed it and change the secret.
Is a password-protected note the same as an encrypted note?
Not quite. Encryption scrambles the stored text so it's unreadable without a key. A passcode is an extra check the recipient must pass before the note opens. On SecureNotes every note is encrypted, and the passcode is an optional extra layer. It helps most when you send it through a different channel than the link.
Do I need an account to send an encrypted note?
Not with SecureNotes. You can paste up to 10,000 characters of text, choose when the note self-destructs, add an optional passcode and get a link without signing up. Developers can also create notes from scripts using the free public REST API. Some other encrypted note tools do require accounts, so check before you start.
