One-Time Secret Security Benchmark: 9 Tools Tested (2026)

We make SnapPwd, so start with the bias disclosure: we are not pretending to be a neutral lab. We are publishing this benchmark because one-time secret tools are often compared by vibe - "simple", "secure", "open source", "zero knowledge" - when the details that matter are more concrete.

For this benchmark, we evaluated nine tools people commonly use or consider for one-time password, API key, and sensitive note sharing:

• SnapPwd
• 1Password Item Sharing
• Bitwarden Send
• OneTimeSecret
• Password Pusher / PwPush
• PrivateBin
• Yopass
• Cryptgeon
• scrt.link

This is not a formal cryptographic audit. It is a product-security benchmark based on official documentation, public source repositories where available, local SnapPwd code, and a point-in-time HTTP security header sweep on April 26, 2026.

What We Tested

We scored each tool on the questions a security-conscious team should ask before sending a password or API key through a link:

1. Is the secret encrypted in the browser before upload?
2. Is the decryption key kept away from the server?
3. Does the link support one-time access or view limits?
4. Does it support time-based expiration?
5. Does the sender need an account?
6. Can it share files, not just text?
7. Is there a self-hosted option?
8. Is the implementation publicly auditable?
9. Do the public hosted endpoints expose basic web hardening headers?

The most important split is client-side encryption vs server-side encryption.

Client-side encryption means the sender's browser encrypts the secret before upload and the server stores only ciphertext. In the common URL-fragment design, the decryption key is placed after # in the shared URL. Browsers do not send the fragment to the server during normal HTTP requests, so the service receives the object ID but not the key.

Server-side encryption means the service receives the secret, encrypts it before storage, and deletes it after the configured view or expiration event. That is still much better than email or chat, but the service handles plaintext at some point and controls the storage encryption key.

Executive Findings

The strongest zero-knowledge-style designs in this benchmark are SnapPwd, PrivateBin, Yopass, Cryptgeon, scrt.link, 1Password Item Sharing, and Bitwarden Send. Each documents or implements client-side encryption where the server should not receive the plaintext secret.

The clearest server-side encryption tools are OneTimeSecret and Password Pusher / PwPush. Both are useful, mature tools, but their trust model is different: the server is part of the plaintext or key-handling path.

The best self-hosting choices are PrivateBin, Yopass, Cryptgeon, Password Pusher, Bitwarden, OneTimeSecret, and SnapPwd's self-hosted web/API stack. Among those, PrivateBin, Yopass, Cryptgeon, and SnapPwd's self-hosted stack keep the key out of the backend by design.

The lowest-friction hosted options for a recipient are SnapPwd, scrt.link, OneTimeSecret, Password Pusher, PrivateBin public instances, Yopass demo/public instances, and Cryptgeon demo/public instances because recipients do not need accounts. 1Password and Bitwarden are stronger fits when the sender is already inside the password-manager ecosystem.

Benchmark Matrix

Tool	Encryption model	Server gets key/plaintext?	One-time/view limit	Expiration	Sender account	Files	Self-hostable	Public source
SnapPwd	Client-side AES-GCM, key in URL fragment	No	Yes	Yes	No	Yes	Yes	Yes
1Password Item Sharing	Client-side item-copy encryption with share secret	No	Optional	Yes	Yes	Limited	No	No
Bitwarden Send	End-to-end encrypted Send object	No	Yes	Yes	Yes	Paid	Yes	Yes
OneTimeSecret	Server-side encryption	Yes	Yes	Yes	Optional/no	No	Yes	Yes
Password Pusher / PwPush	Server-side database encryption	Yes	Yes	Yes	Optional/no	Hosted paid/self-host	Yes	Yes
PrivateBin	Client-side AES-GCM paste encryption	No	Optional burn-after-reading	Yes	No	Optional/self-host	Yes	Yes
Yopass	Browser OpenPGP encryption	No	Yes	Yes	No	Yes	Yes	Yes
Cryptgeon	Client-side AES-GCM, server never sees key	No	Yes	Yes	No	Yes	Yes	Yes
scrt.link	Client-side AES-256-GCM, key in secret link	No	Yes	Yes	No	Yes	No/unclear	Yes

Tool Notes

SnapPwd

SnapPwd's current app generates a random browser-side key, encrypts text secrets with the Web Crypto API using AES-GCM, uploads only ciphertext, and puts the key in the URL hash fragment. The file-sharing path also encrypts files in the browser with AES-GCM before upload.

The public self-hosted frontend documents the same model: generate a browser key, encrypt locally, upload ciphertext, then share a URL containing the object ID in the path and the key in the hash fragment. The public backend service describes itself as zero-knowledge storage that receives already encrypted data, stores it with Redis TTLs, and deletes secrets/files after retrieval by default.

Sources: SnapPwd self-hosted web, SnapPwd service

1Password Item Sharing

1Password's item-sharing feature is not a generic pastebin, but it is relevant because many teams use it for temporary password handoff. 1Password documents that a copied item is encrypted on the sender's device, decrypted on the recipient's device, and protected by a share secret that is not sent to the server. The sender can choose expiration and recipient availability, and SDK parameters include a one-time-only option.

The tradeoff is account dependency: the sender must already use 1Password. This is excellent for teams already in 1Password and less useful as a no-account public drop-in.

Sources: 1Password sharing security, 1Password SDK item sharing

Bitwarden Send

Bitwarden Send is an encrypted text and file-sharing feature inside Bitwarden. Bitwarden documents that Send data is encrypted on creation, decrypted when the recipient opens the link, and stored encrypted in Bitwarden systems. Sends can expire, reach access-count limits, be disabled, or be deleted.

The sender needs a Bitwarden account. Text Sends are broadly available, while file Sends require a premium user or paid organization. That makes Send a strong answer for existing Bitwarden users, but not the lowest-friction option for someone who wants a standalone one-time secret page.

Sources: About Bitwarden Send, Create a Send

OneTimeSecret

OneTimeSecret is the category veteran. It remains a simple, recognizable way to create a self-destructing secret link. Its own documentation describes server-side encryption: secrets are encrypted on OneTimeSecret's servers, then deleted after view or expiration.

That server-side model is the key distinction. OneTimeSecret is useful and open source, but it does not provide the same "server never receives the plaintext" property as client-side encrypted tools.

Source: OneTimeSecret documentation

Password Pusher / PwPush

Password Pusher is transparent about its model, which is good. Its documentation says sensitive push data is encrypted in the database using AES-GCM with 256-bit keys, and it explicitly says Password Pusher does not provide custom client-side encryption where the browser encrypts with a key unknown to the service.

That makes Password Pusher a strong open-source, self-hostable, operations-friendly tool, especially for teams that want audit logs, request flows, and internal hosting. It is not the best fit if your requirement is zero-knowledge-style client-side encryption.

Source: Password Pusher security documentation

PrivateBin

PrivateBin is the strongest mature self-hosted pastebin-style option in this benchmark. It documents a zero-knowledge design where data is encrypted and decrypted in the browser using AES-GCM, and the server stores encrypted data without knowing the contents.

PrivateBin is broader than a credential-sharing tool. It supports pastebin workflows, optional discussions, syntax highlighting, markdown, file uploads depending on configuration, and burn-after-reading behavior. That breadth is useful for self-hosters, but it can be more interface than a non-technical recipient needs for a password handoff.

Source: PrivateBin project site

Yopass

Yopass is a minimal, self-hostable secret-sharing service with a strong developer audience. The public README says secrets, passwords, and files are encrypted in the browser using OpenPGP before they are sent to the server, and that the decryption key does not leave the user's machine. It supports one-time viewing, expiration, optional password protection, files, and a CLI.

Yopass is one of the best choices when you want a small, auditable, self-hosted service and a CLI-friendly workflow.

Source: Yopass GitHub repository

Cryptgeon

Cryptgeon is a modern self-hosted note and file-sharing service. Its README documents a 256-bit ID and 256-bit key design, client-side AES-GCM encryption, and a server that never sees the encryption key. It also stores data in memory rather than persisting it to disk by default, with view and time constraints.

Cryptgeon is a strong fit for self-hosters who want a modern Rust/Svelte stack and file support.

Source: Cryptgeon GitHub repository

scrt.link

scrt.link documents client-side AES-256-GCM encryption, a key added to the secret link, permanent deletion after view, optional additional password encryption, and open-source code. The hosted product also supports text, file, redirect, snap, neogram, and request flows.

The main tradeoff is positioning and packaging. scrt.link is a broader hosted product, while tools like SnapPwd, Yopass, and Cryptgeon are more directly centered on password/API-key handoff or self-hosted secret sharing.

Source: scrt.link security

HTTP Header Sweep

We also ran a simple header sweep against public hosted endpoints on April 26, 2026:

curl -sSI -L --max-time 15 <url>

This is not a vulnerability assessment. It only checks whether common defense-in-depth headers are visible on the tested public endpoint.

Public endpoint	HSTS	CSP	Referrer-Policy	Permissions-Policy	X-Content-Type-Options	X-Frame-Options
snappwd.io	Yes	Not observed	strict-origin-when-cross-origin	Not observed	nosniff	DENY
onetimesecret.com	Yes	Not observed	Not observed	Not observed	Not observed	Not observed
pwpush.com	Yes	Yes	strict-origin-when-cross-origin	Not observed	nosniff	SAMEORIGIN
privatebin.info	Yes	Yes	no-referrer	browsing-topics=()	nosniff	DENY
yopass.se	Yes	Yes	no-referrer	Not observed	nosniff	DENY
cryptgeon.org	Not observed	Not observed	Not observed	Not observed	Not observed	Not observed
scrt.link	Yes	Not observed	Not observed	Not observed	Not observed	Not observed
bitwarden.com/products/send	Yes	Yes	strict-origin-when-cross-origin	microphone=(), camera=()	nosniff	SAMEORIGIN

The cleanest header posture in this narrow check was PrivateBin's project site and Yopass's public frontend. Password Pusher and Bitwarden also expose broad CSP policies, though Bitwarden's marketing/product page necessarily allows a larger set of third-party services than a single-purpose secret-sharing app.

For SnapPwd, the missing CSP and Permissions-Policy headers are practical hardening opportunities. They do not change the encryption model, but a tight CSP matters more for browser-encrypted apps than for normal marketing pages because malicious JavaScript is the primary way to defeat client-side encryption.

Rankings by Use Case

Best hosted, no-account password/API-key handoff

1. SnapPwd
2. scrt.link
3. OneTimeSecret
4. Password Pusher / PwPush

SnapPwd and scrt.link have the stronger client-side encryption model. OneTimeSecret and Password Pusher remain useful because they are familiar and simple, but their server-side encryption model requires more trust in the operator.

Best self-hosted zero-knowledge-style option

1. PrivateBin
2. Yopass
3. Cryptgeon
4. SnapPwd self-hosted web/API stack

PrivateBin is the most mature general-purpose encrypted pastebin. Yopass is the cleanest small secret-sharing service with CLI ergonomics. Cryptgeon is a good modern-stack choice. SnapPwd's public self-hosted stack is promising, but the public repos are newer and much less battle-tested.

Best for existing password-manager teams

1. 1Password Item Sharing
2. Bitwarden Send

If your team already standardizes on 1Password or Bitwarden, their sharing features are usually the first place to look. The account requirement is a feature, not a flaw, when the workflow is internal and governed. It becomes friction when the recipient is an outside contractor, agency, or one-off collaborator.

Best for transparent server-side operations

1. Password Pusher / PwPush
2. OneTimeSecret

Password Pusher deserves credit for documenting exactly where its client-side encryption limitation is. If your organization prefers self-hosting with server-side controls, audit logs, and mature operational docs, it is still a reasonable choice.

Key Takeaways

Client-side encryption is becoming the category baseline. For a modern one-time secret tool, the strongest default is browser encryption plus a key that never reaches the server.

Self-hosting and zero knowledge are not the same thing. A self-hosted server-side encryption tool can be operationally trustworthy because you run it yourself, but it still does not have the same cryptographic trust boundary as client-side encryption.

Password managers are strong but not universal. 1Password and Bitwarden are excellent when the sender already has an account and the organization wants governance. They are less ergonomic for one-off external sharing.

Browser-encrypted apps need strict web hardening. If the server ships the JavaScript, then CSP, dependency control, build provenance, and script integrity become part of the security model. Client-side encryption protects stored ciphertext, but it cannot protect users from malicious JavaScript served at access time.

Recommendation

Use SnapPwd or scrt.link when you want a hosted, no-account, client-side encrypted one-time secret link.

Use PrivateBin, Yopass, or Cryptgeon when self-hosting and public source auditability matter most.

Use 1Password Item Sharing or Bitwarden Send when your team already pays for and governs one of those password managers.

Use Password Pusher or OneTimeSecret when simplicity, familiarity, or self-hosted server-side operations matter more than keeping plaintext away from the server.

Methodology and Limitations

This benchmark was created on April 26, 2026. We reviewed official product documentation and public repositories, then checked public HTTP response headers with curl. For SnapPwd, we also reviewed the current application code in this repository and the public self-hosted frontend/backend repositories.

We did not perform a formal cryptographic audit, dynamic browser instrumentation of every app, penetration testing, paid-plan testing, or source-level review of every dependency. If a vendor's documentation and source diverge, source and runtime behavior should win. If a hosted service changes headers, pricing, file limits, or encryption implementation after publication, this report may become stale.