How the Secret Key Works — and How to Use It

When you share a secret through ShareZT with zero-knowledge turned on, the thing that actually protects it is a key — and the whole design hinges on where that key lives. It isn't stored in our database, it isn't sent to our servers, and it isn't tied to your account. It lives in the link itself. This guide explains how that works in plain terms, then walks you through creating a secret, sharing it, and opening one on the other end.

The key, in one sentence

When you create a zero-knowledge secret, your browser generates a fresh random key, encrypts the secret locally, and places that key in the fragment of the share link — the part after the #. Browsers, by long-standing design, never send the fragment to a server. So we receive and store only the encrypted blob; the key rides along in the link and reaches whoever you send the link to, without ever touching our infrastructure.

That's the entire trick. A ShareZT secret link looks like this:

https://sharezt.com/t/8eRB6hL#aB3xK9d2…

Everything before the # is the token — what our server uses to find the ciphertext. Everything after the # is the key — what a browser uses to decrypt it. We see the first half. We never see the second.

Two locks, not one

It helps to think of a protected secret as sitting behind two separate locks, and we only ever hold one of them.

The gate is the first lock: the checks that run on our servers — expiry, view limits, a password, IP and country rules — that decide who is allowed to receive the encrypted bytes. The key is the second lock: it decides who can actually read them. They're independent. Clearing the gate gets someone an encrypted blob and nothing more; holding the key without clearing the gate gets them nothing to decrypt. You can require both at once, and for anything sensitive you should — the gate decides who's let in, the key decides who can read, and the key never lives on our side.

Walkthrough: creating and sharing a secret

1. Start a text secret. From your dashboard, open New link and choose Text secret.
2. Add your secret. Paste or type the value into the box — or click Generate to mint a strong random one right in your browser (you can pick the character set and length, and you'll see its strength in bits).
3. Leave Zero-knowledge on. It's on by default. With it on, the encryption happens in your browser and we never get the key. (Turn it off only if you specifically want to be able to read the secret back from your own dashboard.)
4. Add gate protections if you want them. A password, an expiry, a one-time burn after reading, IP or country rules — any combination. These are the first lock.
5. Create the link. On the result screen you'll get the full share URL, ending in #…. That tail is the key.
6. Copy the entire URL. Use the copy button on that screen — it grabs the whole thing, key included. This is the one habit that matters most.
7. Send it over a channel you trust. Because the key is in the link, the complete link is the secret.

Walkthrough: opening a secret

There's nothing to install and no account needed on the receiving end. Whoever you send the link to simply opens it:

1. Their browser requests the link from us. The fragment — the key — stays on their device and is never sent.
2. The gate runs on our side. If the secret has an expiry, view limit, password, or IP/geo rule, those are checked first. Fail any, and the request stops there.
3. On a pass, our server hands their browser the encrypted blob.
4. Their browser reads the key from the link's fragment and decrypts the secret locally, right on the page. They see the plaintext and can copy it.
5. If you set burn after reading, that single open consumes it — reload, and it's gone.

This works across devices and browsers for one simple reason: the key travelled inside the link you sent. It reached the recipient because you shared the whole URL with them — not because it was stored anywhere they could fetch it.

What the key means in practice

A few truths follow directly from "the key lives in the link," and they're worth internalizing:

The complete link is the secret. Anyone who can see the full URL — and who clears the gate — can read it. That includes the messaging app it passed through and the recipient's browser history. Share it somewhere you trust, and lean on the gate (a password, an IP or country limit) as your second lock so an intercepted link still isn't enough on its own.

We can't recover it. Because the key never reaches us, a lost link means a lost secret. There's nothing on our side to recover it with. That's not a gap — it's the direct cost of us being unable to read your secret, and we think it's the right trade.

Your dashboard can't show you the key again. This is the one that surprises people. The full, key-bearing URL exists only on the screen right after you create the secret. If you come back later and copy the link from your dashboard, you'll get the part before the # only — a link that passes the gate but can't be decrypted, because we never had the key to put back. So capture or send the full URL at creation time. (We can't reproduce what we were never given.)

Zero-knowledge or server-side?

Zero-knowledge is the default, and it's the stronger guarantee: not even we can read the secret. The one reason to turn it off is if you need to view the secret yourself from your dashboard later — in that mode we encrypt it with our own key, which means we can decrypt it to show you. You're trading "we can't read it" for "you can read it back." Pick per secret; the default leans toward privacy on purpose.

That's the whole model in one habit: generate or paste your secret, let your browser lock it, and share the entire link — including the key on the end — with someone you trust. The gate controls who reaches it; the key controls who can read it; and the more sensitive of the two never leaves your side.

Want the deeper security picture? See how zero-knowledge encryption works and the full set of gate layers. New to ShareZT? Start with creating and protecting a link.