The problem with server-side encryption
Most "encrypted" web services encrypt your data in transit and at rest, but decrypt it on the server before serving it to you. That means the server operator can read everything. It also means a subpoena, a breach, or a rogue employee can expose secrets you thought were protected. The encryption is real, but it's doing less work than the marketing implies.
SecureNotes takes a different approach: the note is encrypted before it leaves your browser, the server only ever sees ciphertext, and the decryption key is never transmitted to the server at all. The mechanism that makes this possible is something browsers have supported since the early days of the web: the URL fragment.
What a URL fragment actually is
A URL fragment is the part after the # symbol. In a link like https://securenotes.net/note/abc123#k=somebase64key, the fragment is #k=somebase64key. Browsers treat this portion of the URL differently from everything before it.
Specifically, browsers do not send the fragment to the server when they make the HTTP request. The server receives a request for /note/abc123 and nothing else. The fragment exists only in the client — your browser — and stays there. This is not a clever hack; it's the specified behavior in the HTTP standard, and every browser follows it.
SecureNotes generates a random AES-256-GCM key in your browser, uses it to encrypt the note content, sends only the ciphertext to the server, and then appends the key to the share link as a fragment. When the recipient opens the link, their browser fetches the ciphertext from the server and decrypts it locally using the key from the fragment. The server never sees the key. Not during creation, not during retrieval.
If you want to understand how this fits into the broader zero-knowledge design — including what the server does and doesn't store — the post on zero-knowledge architecture in SecureNotes walks through the full picture.
What this actually protects against
The fragment-as-key approach closes off a specific set of attack vectors that conventional web encryption leaves open.
Server logs. Web servers log incoming request URLs by default. If the key were part of the path or query string, it would appear in those logs automatically. The fragment never does.
Server-side compromise. If an attacker gains access to the SecureNotes database or application servers, they get ciphertext. Without the key — which lives only in URLs you've already shared — the ciphertext is useless. A breach of the server infrastructure does not become a breach of your notes.
Operator access. The same logic applies to the people running the service. There is no administrative interface that would let someone at SecureNotes read your notes, because there is no key to retrieve. This isn't a policy promise; it's a consequence of the architecture.
Legal requests. A subpoena to SecureNotes for the contents of a specific note would yield ciphertext and metadata (creation time, expiry, whether the note has been read). Not plaintext. The key was never there to hand over.
Where the trick breaks down
Fragment-based key delivery is clever, but it's not magic. There are two categories of failure worth understanding before you rely on it.
Link forwarding. The link is the key. If the recipient forwards the link — pastes it into Slack, screenshots it, copies it into a doc — the key travels with it. Someone with access to the recipient's chat history, clipboard, or screen recording has the key. This is the most common real-world failure mode. One-time links help here: once the note is read, it's gone, so a forwarded link is useless after the first open. But the window between sharing and reading is still a risk.
For high-stakes secrets — a bank recovery code, a production database password — pairing the one-time link with an out-of-band passcode adds a second factor. Passcode-protected notes cover exactly when that extra layer is worth the friction.
Browser extensions and local compromise. The fragment stays out of server logs, but it does exist in the browser. A malicious browser extension with access to the current tab's URL can read the fragment. So can malware with access to the browser process, or someone looking over your shoulder. The threat model here is local device compromise, not server-side compromise. If the recipient's machine is already owned, no encryption scheme at the link layer saves you. This is a fundamental limit, not a flaw specific to SecureNotes.
The practical implication: fragment-based key delivery is strong protection against server-side threats and weak protection against endpoint threats. Know which threat you're actually defending against before you decide how much additional friction is warranted.
A concrete workflow that holds up
Say you're sending a new contractor their initial API key. You create a note with the key, set it to self-destruct on first read, and get a share link. You send the link over email or a project management tool. The contractor opens it, the note is destroyed, and no copy of the plaintext exists on the server from that point forward.
What you've eliminated: the API key sitting in email threads, Slack channels, or a shared doc. What you haven't eliminated: the risk that the contractor's machine is compromised, or that they copy the key somewhere else once they've read it. Sharing API keys with a contractor goes deeper on the full workflow, including what to do when the engagement ends.
For notes that carry especially sensitive material — credentials for a shared account, a recovery code for an important system — it's worth reading the threat model for sharing recovery codes, which applies the same kind of structured thinking to higher-stakes scenarios.
The honest summary
The URL fragment trick is a genuine architectural improvement over conventional web encryption. It eliminates server-side key exposure by design, not by policy. But it doesn't protect against a compromised endpoint, and it doesn't help if the recipient spreads the link around. Understand what it does and doesn't cover, use one-time links and expiry settings to minimize the exposure window, and add a passcode when the stakes are high enough to justify it.
Share one secret, then forget it ever existed
Now that you know how the key stays out of our hands, put it to use: compose a self-destructing note on SecureNotes the next time you need to pass a password, a key, or a recovery code to someone — and it will be gone the moment they read it.
