Bitwarden Send and 1Password sharing alternative

The sharing gap in password managers

Password managers store credentials for your team. But when you need to send a password to a client, a contractor, or someone who isn't in your vault, the sharing features have limits. Bitwarden Send requires a Bitwarden account to create a send. 1Password sharing requires both people to have 1Password or use a Psst! link, which is time-limited and tied to the account.

The person receiving the credential doesn't always use the same password manager you do. Sometimes they don't use one at all. You need a way to get the credential to them without requiring them to sign up for anything.

How Bitwarden Send works

Bitwarden Send lets you create a link to text or a file. The recipient doesn't need a Bitwarden account to open the link. It uses server-side AES-256 encryption. The data is encrypted on the server, not in your browser. Send is included in the free tier for text; file sends require a paid plan.

You set an expiry and an optional password on the send. Once the expiry passes, the data is deleted. The encryption is solid, but it happens server-side. Bitwarden's server handles your secret in readable form during the encryption step.

How 1Password sharing works

1Password lets you share items via Psst! links. The recipient doesn't need a 1Password account. Links expire after a set time. The item stays in your vault. This works well within teams that already use 1Password.

It doesn't help when you need to send something to someone outside your organisation. The sharing flow is built around the vault model. If you're onboarding a contractor who won't be in your vault, you're working around the tool rather than with it.

Client-side encryption without an account

Secret.Broker encrypts in your browser before anything reaches the server. No account needed on either end. The decryption key stays in the URL fragment. The server stores ciphertext it can't read. After the view limit or expiry, the data is deleted.

The protocol page documents the full stack: XChaCha20-Poly1305, Argon2id key derivation, and domain binding. For a deeper look at why the encryption location matters, see client-side vs server-side encryption.

When to use each

Use the password manager for storage and team access. That's what it's built for. When you need to hand a credential to someone outside your vault, use a self-destructing link. The credential gets there, they save it, and the link goes dead.

See sharing passwords for the full walkthrough, or sharing API keys if you're sending service credentials.

Also compare: vs Privnote, vs OneTimeSecret, and vs Password Pusher.

Common questions