A password share link is a web address that opens a secret once, and then destroys it. Instead of pasting Hunter2! into an email, you paste it into a form, get a link back, and send the link. When the recipient opens the link, they see the password and the service deletes it. If anyone clicks the link later, they find nothing. This guide explains why that is better than email or chat, how to tell a trustworthy tool from a risky one, and how to avoid the handful of mistakes that undo the benefit. If you only want the quick version of the process, our guide to sending passwords to clients covers the handoff step by step.
What a password share link is
The problem it solves is persistence. A password sent by email or chat sits in both mailboxes, in backups, on every synced device and in search indexes, usually for years. Anyone who later gains access to either account can search for the word "password" and find it. A one-time link separates two things: the message (which must be delivered once) and the record (which should not exist afterwards). The link carries the first and deletes the second.
How it works under the hood
A well-built tool encrypts the secret on your own device before anything is sent. The steps look like this:
- Your browser generates a random encryption key and encrypts the secret with a modern cipher such as AES-256-GCM.
- Only the encrypted blob is uploaded. The server stores ciphertext with an expiry and a view counter, and never sees the key.
- The key is placed in the link after a
#character, likehttps://example.com/s/abc123#KEY. Browsers never send the part of a URL after the#to the server. That is a long-standing rule of how URL fragments work. - When the recipient opens the link, their browser fetches the ciphertext, uses the key from the fragment to decrypt it locally, and tells the server to delete it.
The effect is that the service holding the data cannot read it, and the people who can read it are only the ones who hold the full link. This is often called end-to-end or zero-knowledge encryption. It does not make the link itself secret, which is why the habits below matter.
What to check before you trust one
- Encryption happens in the browser. The service should say that the key stays in the link fragment and never reaches the server. If a tool says only "encrypted" without saying where, assume the server can read it.
- A view limit and an expiry. You want the secret to vanish after the first view and after a set time even if nobody opens it. A day or a week is typical.
- An optional passphrase. This adds a second factor so the link alone is not enough. See the next section.
- No account needed and no tracking of contents. Reading the privacy policy for what is logged is worth the minute it takes.
- Plain statements about what the service cannot do. Honest tools say that a screenshot, a copy-paste or a compromised device defeats any link, and that they cannot recover a destroyed secret.
- An open, working destroy-on-read. Test it yourself with a dummy secret. Open the link twice. The second time it should fail.
How to use one well
- Generate a strong password first. Use the Password and Key Generator and paste the result into the share form, so the secret has never been typed into a chat or a note.
- Set one view and a short expiry. If the recipient is online now, an hour is plenty.
- Add a passphrase for anything sensitive and send it through a different channel from the link: the link by email and the passphrase by text message or a phone call.
- Tell the recipient to change it. Treat the shared password as temporary. The new owner should change it on first login and store it in a password manager.
- Confirm receipt. If the recipient says the link is already used or gone, assume it was opened by someone else, delete the account access and start again.
Tip: for two-factor setup keys, treat them exactly like passwords. The Auth Key Generator makes TOTP secrets, and those should also go through a one-time link rather than a screenshot in chat.
Mistakes that defeat the protection
- Link preview bots. Chat apps, email scanners and security gateways sometimes fetch links to check them. If a bot opens a one-time link first, it is used up before your recipient clicks. Tools that require a click on a "reveal" button, rather than showing the secret on page load, avoid most of this.
- Sending link and passphrase together. If both go in the same email, anyone reading that email has everything.
- Posting the link in a shared channel. A team channel keeps history, and the link may be visible to people who should not have the secret. Use a direct message at the least.
- Sharing a master password. A password manager master password or a recovery code should never travel this way. Use the manager's own sharing feature or hand it over in person.
- Treating the link as safe forever. A link that has not been opened is still a live secret. If it was sent to the wrong address, you cannot recall it. Set a short expiry for this reason.
Share link vs other methods
| Method | Leaves a copy? | Good for |
|---|---|---|
| Yes, in both mailboxes and backups | Nothing sensitive | |
| Chat message | Yes, in history and exports | Low-risk, short-lived items only |
| Password manager sharing | Yes, in a vault both people control | Ongoing shared logins inside a team |
| One-time share link | No, deleted after viewing | One-off handoffs to clients and contractors |
| Phone call or in person | No digital copy | Master passwords and recovery codes |
For client work, a one-time link followed by a password change gives you a clean record: you can show exactly when access was handed over, and nobody is left holding a plain-text copy.
Frequently asked questions
What is a password share link?
It is a web address that reveals a secret once and then deletes it. You paste the password into a form, get a link, and send the link instead of the password, so no copy stays in anyone's email or chat history.
Can the service that creates the link read my password?
Not if it is built correctly. The secret is encrypted in your browser and the key is placed after the # in the link, which browsers never send to the server. The server stores only ciphertext it cannot decrypt.
What happens if someone opens the link before my recipient?
The secret is shown to them and then deleted, and your recipient finds nothing. That is why you should add a passphrase sent through another channel and ask the recipient to confirm they could open it.
Why did my one-time link stop working before the recipient used it?
Email scanners and chat apps sometimes open links to check them, which counts as the one view. Use a service with a click-to-reveal step, or send the link through a channel that does not preview links.
Are password share links safe for clients?
They are much safer than email, as long as you set one view and a short expiry, send any passphrase through a separate channel and ask the client to change the password after first login.