Feature
Secure Link Sharing: Getting a Secret to Someone Else
Encryption solves storage. Sharing is the harder problem, because at some point a human has to receive something — and every channel available for that is imperfect. This page is about doing it as well as the constraints allow.
The short answer
# — browsers never send that part to a server, so we still store only ciphertext, but anyone holding the complete link can read the note. Set a share password instead and the password becomes the key: the link on its own retrieves nothing readable. Either way the link carries its own expiry and view limit.How a share link works
When you share a note, Inkrypt issues a token — a long, unguessable identifier — and serves an encrypted snapshot at /share/<token>. The token is an address, not a key: it retrieves ciphertext and nothing else. What decrypts that ciphertext depends on which of the two modes you used.
Without a share password, your browser generates a random key, encrypts with it, and appends it to the URL after a #. Fragments are never transmitted to a server, so the key stays out of our logs and our database — but it is in the link, and whoever has the whole link has the note. With a share password, that password is the key. Nothing in the URL can decrypt the snapshot, so the link and the password can travel separately.
| Link format | /share/<random token> |
|---|---|
| What the token grants | Retrieval of ciphertext only |
| Decryption key | In the link fragment (#key=…) by default, or the share password you set |
| Indexing | noindex, nofollow — excluded from robots.txt and the sitemap |
| Per-link controls | Expiry time and maximum view count |
Share pages are never indexed
The rule that matters most: split the channels
This rule applies once you have set a share password. Send the link and the password in the same message and you have built an elaborate machine that delivers a plaintext secret: the encryption, the key derivation and the expiry are all bypassed by that single convenience. If you did not set a password, there is nothing to split — the link is the secret, and it deserves the same care you would give the password itself.
Channel separation means an attacker has to compromise two independent things to get the secret. Compromising a mailbox is realistic. Compromising a mailbox and a phone simultaneously is a materially harder problem.
| Send the link via | Send the password via | Notes |
|---|---|---|
| Phone call or in person | Best general-purpose pairing; spoken passwords leave no written record | |
| Work chat | SMS to a known number | Good, provided the number is already known to you |
| Ticket or project tool | Password manager share | Strong for teams that already run a manager |
| A second email | Weak — same mailbox, same compromise | |
| Chat | The next message in the same chat | No separation at all; avoid |
A worked example
Create the note
Write the credential. Generate a four-word password in your password manager rather than inventing one.Set tight limits
Two-hour expiry, view limit of two — one spare for a mail scanner. See self-destructing notes for why two rather than one.Send the link by email
Say what it is and that the password follows separately. Do not describe the secret itself in the email.Call and read the password aloud
A phone call leaves no searchable artefact. Confirm the recipient has opened the note while you are still on the call.Delete immediately
Once confirmed, delete the note rather than waiting for expiry. Then rotate the credential on your next scheduled change if it is long-lived.
What to do when a link leaks
Assume it will happen eventually — a wrong autocomplete in an email client, a screenshare left running, a forwarded thread. A leaked link on its own does not expose the note, but it should still trigger a response.
- Delete the note immediately. This is the fastest, most complete action available and it is entirely in your control.
- Assume the password may have leaked too, especially if the leak was a forwarded thread that might have contained both.
- Rotate the underlying secret. This is the only step that actually restores your position.
- If the note had a view limit, check whether it had already been consumed — that tells you whether anyone fetched it.
Do not put secrets in the note name
/aws-prod-root-key tells an observer a great deal before anyone enters a password.Frequently asked questions
Is the share link itself enough to read my note?
Can share links appear in Google?
What is the safest way to send the password?
Should I use one link for several recipients?
What if a link is forwarded to the wrong person?
Related reading
Security architecture
The field-by-field specification of what a share upload contains, and how share links carry their key.
Read moreSelf-destructing notes
Expiry and view limits, and what they cannot do.
Read moreHow to share passwords securely online
The full guide to channel separation and rotation.
Read moreFor agencies and freelancers
Handing credentials between organisations that share no tooling.
Read moreHow Inkrypt works
The end-to-end walkthrough, from typing to reading.
Read moreWrite your first encrypted note
No account, no email address, no download. Type a note, set a password, share the link.
Open the notepad