password.link

Password.link protects a shared secret in three layers: the secret is encrypted in the sender's browser before it is sent, the recipient opens it through a link that self-destructs after a single view, and the sender can add expiration time, a link password, CAPTCHA, and an open-count limit. This suits anyone sending a password, API key, or confidential file through a channel where a plain message would linger — email, chat, or a ticket. It is not a replacement for a password manager; it is a way to move one secret to one recipient without leaving it in message history.

The mechanism, step by step

The security model rests on where encryption happens and what happens after the first open.

1. Encrypt in the browser. You enter the secret on the site, and it is encrypted in your browser before it leaves — the page states "Your secret is encrypted in this browser before it leaves." The site describes this as zero-knowledge and AES-256-GCM, hosted in the EU. In practice, the plaintext is not sent to the server as readable content.
2. Create the link. The site returns a shareable link (and optionally a QR code you can download). You send that link to the recipient through whatever channel you already use.
3. Recipient opens once. The link self-destructs after a single view, so a later click — by the recipient, a forwarded copy, or someone reading the message history — does not reveal the secret again.
4. Sender controls the window. Per-link settings let you set an expiration time, require a password to open the link, add CAPTCHA, and choose how many times the link can be opened.

The practical effect: the secret's exposure is bounded by time and by view count, not by whether the recipient remembers to delete a message.

A concrete example

Suppose an IT admin needs to hand a new hire's temporary credentials to a contractor. Instead of pasting the password into email, the admin creates a one-time link, sets it to expire in 24 hours, adds a password sent through a separate channel, and limits it to one open. If the email is later forwarded or the contractor's inbox is compromised after the first open, the link is already dead.

What each setting buys you

The combination matters more than any single setting: a link with a short expiration and a password is far harder to exploit than a one-time link alone, because the attacker needs both the link and the password within the window.

Receiving secrets and other uses

The same mechanism runs in reverse. A Secret Request link lets you ask someone else to send you credentials or documents; they reply through a one-time link only you can open. The site also offers an end-to-end encrypted chat that disappears when closed, bulk link creation from a CSV file (parsed in the browser, so the service does not access the file's contents), and team features such as separate member accounts, centralized settings, and single sign-on.

Limits worth knowing before you rely on it

• One view is one view. If the recipient opens the link and the page fails to load properly, or they close it before saving the secret, the link is spent. For anything the recipient must keep, they should store it in a password manager on first open.
• The link is a bearer token. Anyone who has the link and, if set, the password can open it first. Send the link and the password through different channels.
• Free-tier limits exist. The page shows a "Limit for new Secrets reached" message and notes that creating a free account (no credit card required) unlocks all features, including attachments, branding, and notifications. Plan details are on the site's Plans page; check current terms there rather than assuming a free tier covers volume use.
• It is a transfer tool, not storage. Nothing in the described model suggests the secret remains retrievable after the view limit — which is the point, but it means you cannot recover a secret you sent if the recipient loses it. Keep your own copy.

Password.link is a service for sending and receiving sensitive information—passwords, API keys, confidential files—through one-time links that self-destruct after a single view. It fits situations where email or chat feels too exposed for the content being shared, and it offers three modes: sending a secret, requesting a secret from someone else, and a one-time encrypted chat. Secrets are encrypted in the browser with AES-256-GCM before they leave it, and the service describes itself as zero-knowledge and EU-hosted.

How the core mechanism works

The important detail is where encryption happens. When you create a link, the secret is encrypted in your browser before transmission, so the plaintext is not sent to the server. The recipient opens the link, views the secret once, and the link self-destructs.

A concrete example: you need to hand a database password to a contractor. Instead of pasting it into email, you create a one-time link, send the URL through whatever channel you already use, and the contractor opens it once. After that view, the link no longer works—so a forwarded email or a later inbox compromise doesn't expose the password.

Per-link settings let you configure expiration time, an additional password, CAPTCHA, and how many times the link can be opened. Those controls matter when the recipient may be slow to act or when you want a second factor beyond possession of the URL.

The three ways to use it

The Receive mode is the less obvious one and often the more useful: instead of waiting for someone to send you a password insecurely, you give them a structured way to submit it that only you can open.

Features worth knowing before you choose

• Attachments and branding are available to registered users; the site notes that creating an account is free and requires no credit card, and that registered users get access to all features and can create more Secrets.
• Bulk Secrets lets you generate many one-time links from a CSV file. The CSV parsing happens in the browser, so the service states it doesn't have access to the data in the file—relevant if you're provisioning credentials for many users at once.
• Teams features include separate accounts for team members, centrally managed settings, and single sign-on (SSO), which is the main reason an IT team would pick this over ad hoc link tools.
• Notifications keep you informed of updates, such as when a link has been viewed.
• QR codes can be generated for a link and downloaded as an image, useful for sharing to a phone or in person.

Limits and practical caveats

The free tier is not unlimited: the interface shows a "Limit for new Secrets reached" error when you hit the cap, with the guidance that registered users can create more. If you plan to use this regularly, check the Plans page for current tiers rather than assuming the free allowance covers your volume.

There is also a length limit on secrets—the tool returns "Length exceeded, please use a shorter Secret"—so very large files should go through the attachment feature rather than being pasted as text.

Finally, the one-time design is a strength and a constraint: if the recipient never opens the link before it expires, or opens it and loses the content, you need to create a new one. Set the expiration window with the recipient's actual availability in mind.

Is it the right tool for you?

Use Password.link if you regularly exchange credentials or confidential files with individuals or a team and want a self-destructing, browser-encrypted link rather than plain email. The Secret Request mode is particularly worth adopting if you collect sensitive data from clients. If you only need to share a secret once or twice, the free allowance and one-time links are enough to try it; if you need SSO, centralized management, or high volume, look at the team plans before committing.

Yes. Password.link supports both team use and bulk link creation. For teams, it offers separate accounts for team members, centrally managed settings and single sign-on (SSO). For larger volumes, its Bulk Secrets feature lets you create many one-time links from a CSV file, with the CSV parsed in the browser so the service does not access the data it contains. Both capabilities sit alongside the core one-time-link model, where a shared secret self-destructs after a single view.

Team Features

Password.link describes team support as designed for collaboration and integration. Based on the site's feature description, team use covers three things:

• Separate accounts for team members — each member gets their own account rather than sharing one login.
• Central settings management — settings are managed from one place instead of per person.
• Single sign-on (SSO) — secure access through your organization's identity provider.

The site positions the product as "ideal for IT teams of all sizes" and notes it has been trusted since 2016, with BioNTech shown as a customer logo. If your team needs shared administration and SSO-based access control, these are the features to evaluate.

What to check before rolling out to a team

The site does not publish per-seat limits, SSO configuration steps or admin console details in the available material. Before committing, confirm with the vendor:

• Which plan tier includes SSO and centralized settings (see the Plans page).
• How member accounts are provisioned and deprovisioned.
• Whether team settings can enforce link defaults such as expiration time or open limits.

Bulk Link Creation with Bulk Secrets

The Bulk Secrets feature creates many one-time links at once from a CSV file. The important mechanism: CSV parsing happens in the browser, so Password.link states it does not have access to the data in the file. That matters because bulk files typically contain many credentials at once — the same zero-knowledge approach the product applies to individual secrets.

A practical workflow, based on how the product describes its one-time links:

1. Prepare a CSV where each row holds one secret (for example, a username/password pair or an API key) plus any per-link settings you want to apply.
2. Upload it through the Bulk Secrets feature; parsing occurs locally in your browser.
3. Generate the links and distribute each one to its intended recipient.
4. Each link self-destructs after a single view, subject to the expiration, password, CAPTCHA and open-count settings you configure.

Limits and account requirements

The site's interface text shows a "Limit for new Secrets reached" message for users who hit a cap, and states that registered users "have access to all our features and can also create more Secrets." In other words, anonymous use is capped, and creating a free account (no credit card required, per the site) raises that ceiling and unlocks features like attachments, branding and notifications. The exact bulk limits per plan are not published in the available material — check the Plans page or ask the vendor if you expect high volume.

How This Fits the Rest of the Product

Teams and bulk creation extend the same one-time-link core rather than replacing it:

All of this runs on AES-256-GCM encryption with a zero-knowledge design, hosted in the EU, per the site.

Bottom Line

If your need is "many links at once," Bulk Secrets with in-browser CSV parsing is the direct fit. If your need is "many people, governed access," the team features — separate accounts, central settings and SSO — are the ones to confirm against your plan. The main open questions are plan-level limits and SSO availability, which the Plans page and the vendor can answer.

Creating a free Password.link account (no credit card required) unlocks the full feature set and removes the cap on how many new Secrets you can create; using the site without registering still lets you make one-time links, but you may hit a limit on new Secrets and won't have access to attachments, branding, or notifications. Choose the no-account path for a quick one-off share, and register when you need volume, file attachments, or a recognizable branded experience.

What you can do without an account

The core one-time link flow is available on the site itself. You create a link, the secret is encrypted in your browser before it leaves, and the link self-destructs after a single view. You can also configure per-link settings such as expiration time, a password, CAPTCHA, and how many times the link can be opened.

The constraint is volume. The page shows an explicit error state: "Limit for new Secrets reached. You have reached your limit for new Secrets. Please try again later. Registered users have access to all our features and can also create more Secrets." So the no-account path is best treated as a trial or occasional-use mode rather than a daily workflow.

What a free registered account adds

According to the site, creating an account is free and requires no credit card, and registered users "have access to all our features and can also create more Secrets." The features called out as account-gated include:

• Attachments — send files alongside passwords and other confidential data through the same self-destructing link.
• Branding — present links with your own branding rather than the default look.
• Notifications — stay updated on link activity, such as when a secret is viewed.
• Higher Secret volume — the per-period limit on new Secrets no longer blocks you.

The site also points to a Plans page, which implies paid tiers exist beyond the free account. The page evidence does not state prices or what each paid tier includes, so check the Plans page directly before assuming a paid plan is needed for your use case.

Side-by-side comparison

Which should you pick

Use it without an account if you need to send a single password, API key, or short confidential note once, and you don't need files or activity updates. The browser-side encryption and one-view self-destruct behavior are the same either way.

Register a free account if any of these apply: you share secrets regularly and keep hitting the new-Secret limit, you need to send documents or files with the secret, you want recipients to see your branding, or you want to know when a link has been opened. Registration costs nothing and removes the main friction point.

Look at the Plans page if you need team features. The site describes separate accounts for team members, centrally managed settings, and single sign-on (SSO) for secure access — these are positioned as team capabilities, and the page evidence does not confirm they are included in the free tier. Bulk link creation from a CSV file is also described as a distinct feature ("Bulk Secrets"), with CSV parsing done in the browser so the service doesn't access the file contents; confirm tier availability on the Plans page.

Practical notes before you decide

• Encryption happens client-side. The secret is encrypted in your browser before it leaves, using AES-256-GCM with a zero-knowledge design, and the service is EU-hosted. This applies to the link-creation flow generally, not just paid users.
• The guest limit is time-based, not permanent. The error text says "Please try again later," so the cap appears to reset; registering is the way to avoid waiting.
• Secret Request links work in reverse. Instead of sending data, you send a request link and the other person replies through a one-time link only you can open — useful for collecting credentials from clients. The page does not specify whether this requires an account, so test it as a guest first if that's your main need.
• Chat is separate from links. The site also offers end-to-end encrypted chat that disappears when closed; treat it as a different tool from one-time links rather than a substitute.

Password.link's Secret Request feature flips the usual one-time-link flow: instead of you sending a secret outward, you create a request link and send it to the person whose data you need. That recipient submits passwords, API keys, or files through a one-time link that only you can open. Use it when you need credentials or documents from clients, users, or colleagues but don't want them sent over email or chat in plain form.

What a Secret Request link is

A normal Password.link share works like this: you enter a secret, the browser encrypts it, and you send the resulting self-destructing link to a recipient. A Secret Request reverses the direction. You generate a link that invites someone to submit information; when they do, the data is encrypted and packaged into a one-time link addressed to you.

The site describes it as working "the same way as sharing data with a one-time link, except that the end result is that you will receive the one-time link containing the data you have requested." The intended uses it names are collecting credentials or documents from clients and users.

Step by step

1. Create the request. In your Password.link account, start a Secret Request link rather than a standard share link. The site presents Send, Receive, and Chat as the three main modes; Receive is the Secret Request path.
2. Send the request link to the person you need data from. Any normal channel works for delivering the link itself, since the link carries no secret — it only opens a submission form.
3. The recipient submits their data. Their browser encrypts the secret before it leaves their machine, consistent with the zero-knowledge design described on the site.
4. You receive a one-time link. Open it once to retrieve the submitted credentials or files. As with all Password.link links, it self-destructs after a single view by default.

What you can configure

Password.link states that each link supports settings including expiration time, an optional password, CAPTCHA, and how many times the link can be opened. These settings apply to the link you generate, so you can tighten access on the retrieval side — for example, requiring a password you share with the recipient through a separate channel, or shortening the expiration window.

Where the security properties come from

• Encryption happens in the browser. The site says secrets are encrypted in the browser before leaving, using AES-256-GCM, and describes the service as zero-knowledge.
• One-time viewing. Links self-destruct after a single view, which limits exposure if a link is forwarded or intercepted.
• EU hosting. The site states data is EU hosted.
• Track record. Password.link says it has been trusted since 2016 and lists teams such as BioNTech as users.

These claims come from the vendor's own pages; they describe the design rather than an independent audit, so weigh them accordingly for high-sensitivity use.

When Secret Request is the right tool

Choose it when the data flow is inbound and one-off: onboarding a client who needs to hand over account credentials, collecting an API key from a contractor, or receiving a signed document you'd rather not have sitting in an inbox. For outbound sharing — sending a password to a colleague — use the standard one-time link instead. For back-and-forth sensitive discussion, the site offers an end-to-end encrypted chat that disappears when closed.

Practical caveats

• Account limits. The site's interface shows a message that a limit for new Secrets can be reached, with registered users able to create more. Creating an account is described as free with no credit card required, and registration unlocks features such as attachments, branding, and notifications. Check the Plans page for current tiers before relying on volume use.
• Delivery of the retrieval password. If you protect the returned link with a password, send that password through a different channel than the request link itself.
• Recipient cooperation. The security depends on the recipient submitting through your link rather than emailing the data directly, so say so explicitly in your request message.