Why we put the key after # — and how it actually works

In Secure Link we say: the key stays in URL after the hash symbol.

So what? In practice it means one simple thing. Server doesn't see anything that comes after #. Only your browser knows about this part.

Let's say someone intercepts the request to server. They'll see encrypted gibberish, but not the key.

Yes, sounds boring. However this tiny detail turns regular link into secure one. Well, mostly secure.

How URLs work

Any internet address splits into chunks:

https://createsecurelink.com/page?search=hello#section1
                     ^^^^^^^^^^^^^^^^^^^^
                     query    fragment

The ?search=hello part is called query. It goes to server with the request.

But #section1 is fragment. It stays in browser.

We put encryption key exactly in fragment. Server gets request, returns encrypted note. Browser takes key from address bar and decrypts locally. Server doesn't even know about the key.

What actually flies over the network

I'll show with example. Here's the bad way (don't do this):

GET /note/abc123?key=SuperSecretKey HTTP/1.1
Host: createsecurelink.com

Key in query — server will see it. Bad.

Here's the right way:

GET /note/abc123 HTTP/1.1
Host: createsecurelink.com

key=SuperSecretKey ← server doesn't get this

Server logs will only show /note/abc123. Key never leaves your computer.

Simple scheme. And it works.

Why bother with this mess

We have three rules:

1. 1
   Server only stores encrypted garbage
2. 2
   Key never reaches server
3. 3
   Decryption happens in your browser

Something like:

[Your browser] --encrypts--> [Garbage] --sends--> [Server]
^                                              |
|                (no key)                      |
+------------- key in URL# ------------------+

Result: server physically cannot read your note. It doesn't have the key.

By the way, I thought at first — why such complications? But when I figured it out, I understood. This system is pretty solid.

What preview bots do

Telegram, Slack and other messengers show link previews. Their bots visit links but without fragment.

Bot will request https://Secure Link.com/note/abc123 and simply ignore everything after #.

Our server in such cases:

• Returns safe description (without revealing content)
• Doesn't try to be too clever
• Sets proper cache headers

Note stays intact. Preview doesn't "burn" it.

Mistakes that ruin everything

Here's where people usually mess up:

1. 1
   Redirect breaks the key

Was: /note/abc#key=123 Became: /note/abc?key=123 (after redirect)

Key ended up in query. Don't do this.

1. 1
   Analytics logs everything

Google Analytics or other trackers might accidentally record full URL. Need to configure them properly.

1. 1
   Weak encryption

Don't save money on crypto, seriously. We use AES-GCM — proven stuff.

1. 1
   Screenshots

Screenshot with key in address bar is like tattoo. Forever. Better avoid.

1. 1
   Everything in one channel

If you set password on link — send it separately. SMS, different chat, whatever.

How to use it right

Few simple rules:

• Set "one view" and short lifetime
• For important stuff add password (and send it separately)
• Warn recipient: "Link is one-time, don't forward"
• Not sure — burn note manually after reading

I usually set maximum one hour for passwords. For regular notes — day is enough.

Bottom line

URL fragment — simple idea with big consequences.

Key with recipient, ciphertext on server. That's it.

Want to share secrets without traces? Try one-time links. No harder than regular texting, but more peace of mind.

Though... maybe regular chat is fine for you. Everyone decides for themselves.