Share credentials securely

    Scope the login, send it once through a link that burns, and rotate it when the work is done.

    Step by step

    1. 1

      Create a credential that is only as wide as the job

      Give the client or contractor their own login where the system allows it, with the least access that gets the work done. A credential you can revoke on its own is far easier to retire than a shared admin password.

    2. 2

      Put the username and password in separate places

      Send the username in the email or ticket where the conversation already lives. Keep the password for the secret link, so a message on its own is not a working login.

    3. 3

      Send the password through a one-time link

      Paste it into the creator below. The link is encrypted in your browser and burns after the first view, so nothing usable is left in the thread.

    4. 4

      Ask them to open it now and store it in their own manager

      The link works once. If they report it was already burned, someone else opened it first: rotate the credential and send a new link.

    5. 5

      Set an end date and rotate

      When the engagement ends, change or disable the credential. On Pro, the audit timeline shows when each link was opened, which helps when you need to say who had access and when.

    Send it with a one-time link

    0/10,000 characters

    Passphrase protection is available on Pro ($29/mo). See plans

    Burn after read is always on for anonymous secrets. The link self-destructs after one view.
    Burn after read
    Encrypted in your browser
    Never expires (until read)

    No account needed. Free forever plan.

    How it works

    1. 01

      Paste a password, a key, or a file

      Encrypted in your browser before anything is sent. Burn after read is on for every anonymous secret.

    2. 02

      Send the link

      One URL. The key after the # stays in the browser and never reaches our servers.

    3. 03

      The stored secret is gone

      The first open burns the ciphertext. A second visit, by anyone, meets the destroyed page.

    Browser-side encryption shipped on 29 September 2026. Secrets created before that date were stored as plaintext until they expired, and a file's name, size and type are still visible to us. Read the full security model.

    How to share login credentials with a client or contractor

    The steps above cover the common case: an agency handing a client their new site's admin login, a firm giving a contractor a database or VPN credential, or an IT team onboarding a vendor. The principle is the same each time. The message in the inbox should never be a complete login, and the password should exist in only one place after it has been read: the recipient's password manager.

    Why a one-time link beats email, chat and shared documents

    Email is forwarded, searched and backed up. Chat history is exported. A shared document keeps every version. A one-time link is different in kind: it carries ciphertext that only the key in the link can open, the first reveal destroys the stored copy, and a link found later leads to a burned page. With a free account you can also revoke it before it is opened, which no email can do.

    Credentials that are more than a password

    Connection strings, SSH keys and .env files are credentials too. Text of any kind fits in the creator. With a free account you can attach a file, encrypted the same way, so a key file or a config travels behind the same burn and expiry controls. For keys specifically, see how to share API keys securely.

    Frequently asked questions

    Pro, $29 a month, adds a passphrase on every secret, a custom expiry date and time, and the audit timeline that records each view, burn and revoke. See plans.

    Related

    All use cases