Privacy services love the phrase "no logs." VPNs plaster it across their marketing. Secure messaging apps claim it. Note-sharing tools use it. But "no logs" is one of the most abused claims in the privacy space — because logging is not binary. A service can claim no logs while still recording quite a lot.
Here's what logging actually means in the context of secure notes, what responsible services do and don't record, and how to think about it when choosing a tool.
When you create or read a secure note, a surprising amount of data touches the server. Any of the following could theoretically be logged:
Note what's not on this list: the actual content of your note. If encryption is done properly client-side, the server never sees plaintext. The content is encrypted before it leaves your device. But everything else above is metadata — and metadata can be remarkably revealing.
A responsible "no logs" claim for a secure note service should mean:
It does not and cannot mean that your IP address never touched a server — it did, because you made a network request. What matters is whether that address was logged and retained.
The single most important technical distinction in secure note services is where encryption happens.
| Factor | Client-side encryption | Server-side encryption |
|---|---|---|
| Who encrypts | Your browser | The server |
| Who holds the key | You (in the URL) | The service |
| Can service decrypt stored content | Not from ciphertext alone, if implemented correctly | Potentially |
| Server breach exposure | Ciphertext and metadata may be exposed | Plaintext may be exposed |
| Data available for legal process | Ciphertext and metadata | Potentially plaintext and metadata |
With sound client-side encryption, a service should not be able to decrypt stored ciphertext without the key. That protection depends on the implementation, the security of the browser and device, and whether the key is ever transmitted. Metadata can still remain available.
One elegant solution used by privacy-conscious note services involves putting the decryption key in the URL fragment — the part of a URL after the # symbol.
In ordinary browser navigation, the URL fragment is not included in the HTTP request. When you visit https://example.com/note/#decryption-key-here, the server ordinarily receives a request for /note/ without the fragment. The key can still be exposed through unsafe client-side code, browser extensions, copied links, screenshots, clipboard history, or a compromised device.
Burn Note’s current privacy practices are described in the Privacy Policy. The service avoids advertising trackers and encrypts shared note content in the browser before upload. Cloudflare still processes limited network and security data needed to deliver and protect the service.
Create a client-side encrypted temporary note on Burn Note — no account required.
Write a secure note →