Secret Share
Share passwords through a self-destructing link — unreadable even to the server.
Visible before the secret is revealed.
Shown as "[name] shared a secret".
Also visible before revealing.
Extra password required to open the secret — agree on it through another channel; it is not part of the link — 0/128
How Secret Share works
When you generate the link, your browser creates a random key and encrypts everything locally with AES-256-GCM — the secret and also the title, description and signature, when filled in. Only then are the encrypted blocks sent to the server, which keeps them until they expire or are viewed. The generated link combines two things: the secret's address (which the server knows) and the decryption key in the fragment, after the # (which the server never sees). Whoever opens the link decrypts everything in their own browser — the plaintext never crosses the network and never touches the server.
Why Nexinon cannot read your secret
The part of an address after the # symbol (the "fragment") is, by web specification, processed only by the browser — it is never included in any request. Since the decryption key lives exactly there, the server receives only undecipherable encrypted blocks: without the key, it has no way to read anything — not the secret, not the title or description — even if it wanted to; and neither would an eventual server breach. This design is known as zero-knowledge: the trust lies in the math, not in a promise.
Expiration and views
Every secret has a lifetime (15 minutes to 7 days) and a number of views: from 1 to 10, or unlimited — in which case the link works until it expires. Revealing the content consumes one view; on the last one (when there is a limit), the encrypted record is erased from the server immediately — what used to be "burn after reading" in old spy tricks is literal here. An expired secret is treated as nonexistent right away, regardless of cleanup: expired means gone. Opening the link page or getting the passphrase wrong never consumes a view — only a successful reveal counts.
When to use the passphrase
Without a passphrase, whoever has the complete link can read the secret — which is already safe when the sending channel is trustworthy. The passphrase adds a second factor for less trustworthy channels: it takes part in deriving the decryption key (PBKDF2, also in the browser), so the link alone becomes insufficient. Send the link through one channel and agree on the passphrase through another — e-mail + message, for instance — and intercepting a single channel is no longer enough. The passphrase is verified in the recipient's browser, before any view is consumed — getting it wrong never wastes the link.
Frequently asked questions
No — and that is not a policy, it is the technical design. Encryption happens in your browser and the key travels only in the link fragment (after the #), which browsers never send to any server. What the server stores are encrypted blocks without the corresponding key — including the title, description and signature.
Every secret is born with a number of views (1, by default — or unlimited, if the creator prefers). Revealing the content consumes one; when the last one is consumed, the encrypted record is erased from the server at that very moment. That consumption is what guarantees that a link intercepted after the legitimate read delivers nothing.
No, in both cases. The link page shows the title, description, deadline and remaining views without consuming anything — a view is only consumed when the secret is actually revealed. And the passphrase is verified in your browser, before any reveal: getting it wrong any number of times never wastes the link. That is also what prevents link-preview bots (WhatsApp, Slack, Teams) from burning the secret before you open it.
They are visible to anyone holding the complete link — that is their purpose: giving context before revealing. But they remain encrypted with the link key, so the server cannot read them. The secret itself gets one extra layer of protection when there is a passphrase.
No — the signature is a courtesy from whoever creates the link (any text can be typed there), not an authenticated identity. Treat it like the sender of a greeting card: useful for context, not proof of origin. When in doubt, confirm with the person through another channel.
No, by design: the server never had the key, and an expired or fully viewed secret is physically erased. The only way out is for the creator to generate a new link. That irreversibility is what makes the tool trustworthy.
A secret pasted into a chat stays there forever: in backups, in history, on every synced device — readable indefinitely by whoever gains access to the conversation one day. A Secret Share link delivers the content a few times and disappears; what remains in the history is a dead link.