People reach for whichever of these three they already have open. That is how a production API key ends up in a personal password vault, and how a one-time handover password ends up stored forever in a system built for permanence.
The three categories look similar from the outside — all of them encrypt things, all of them have a sharing feature of some kind — but they were built to solve different problems, and the mismatch usually shows up later, at rotation time or during an incident.
Summary
Match the tool to the lifespan and the consumer of the information. Something a person needs once and then never again suits an encrypted note. Something a person reuses suits a password manager. Something a machine reads at runtime belongs in a secrets manager. Storing the third kind in the first two is the most common and most expensive mistake.
What Each Category Is Actually For
Encrypted notes
A transport mechanism. You have a piece of text that needs to reach someone, and the ordinary channels — email, chat, a ticket comment — all keep permanent, searchable copies. An encrypted note moves the text across that gap without leaving one.
Its defining property is that it is designed to stop existing. Nothing about it assumes you will come back to it.
Password managers
A personal or team credential store, built around the assumption that you will use the same credential repeatedly for years. The encryption is table stakes; the value is everything built on top of it — autofill, generation, breach warnings, organised vaults, and increasingly passkey storage as sites move away from passwords.
Its defining property is durability. A password manager is designed so that you can still get in three years from now, including after you lose a device, which is why account recovery mechanisms exist in most of them.
Secrets managers
Infrastructure. The consumer is usually a program, not a person: a deployment pipeline, a running service, a scheduled job. The credential is fetched at runtime rather than typed.
Its defining property is that access is a policy question. Which workload can read which secret, under what identity, is configuration — and the system records who or what read it and when. Rotation is a routine operation rather than an event.
Encrypted Notes: When They Make Sense
The pattern that fits is a one-off handover to a human.
A contractor needs a login for a system they will use once. Someone needs the Wi-Fi password for the office. A colleague needs a database credential for an afternoon of debugging. In each case the recipient needs the text now, and nobody needs a permanent record afterwards.
The other case is where an account requirement is itself the obstacle. If the recipient is outside your organisation and does not use your tooling, asking them to sign up for something before they can read one line of text is a poor trade. Tools in this category generally work without an account on either side.
Where they fit badly: anything you will need again. A note that expires is exactly wrong for a credential the team will need next month, and the absence of an account cuts both ways — most encrypted note tools have no list of your notes, no search, and no recovery. If you forget the password, the content is gone. That is the direct cost of the provider not holding a key, and it is not a flaw to be engineered around.
Password Managers: When They Make Sense
If a human types it more than once, it belongs here.
This is the default for personal logins, and it should be the default for shared team credentials too — the ones that cannot be replaced with individual accounts. A shared vault gives you rotation without a scavenger hunt, revocation when somebody leaves, and a record of what exists.
Two capabilities are worth being explicit about, because they are the actual reason to prefer this category over an encrypted note for anything recurring:
- Recovery. Most password managers have some path back in after a lost device. That is a deliberate trade-off — recovery generally implies the provider holds something that can restore access — and for a store of hundreds of credentials it is usually the right trade.
- Sharing that persists. When a manager shares a credential with a colleague, the credential remains under management. Rotate it and the recipient sees the new value. Send the same credential in a note and you have created an untracked copy that goes stale silently.
Where they fit badly: feeding secrets to machines. Applications need programmatic retrieval, per-workload identity and rotation without a human in the loop. Some managers offer automation features, but the design centre is a person at a keyboard.
Secrets Managers: When They Make Sense
The signal is that something other than a person needs to read it. Database connection strings, API keys used by a service, signing keys, certificates, credentials injected into a CI pipeline.
What you get that the other two categories cannot provide:
- Access bound to a workload identity rather than a shared password, so a compromised service can be scoped to only what it needed
- An audit trail of retrievals — often the only way to answer "what could this have reached?" during an incident
- Rotation as a routine operation, sometimes automated against the upstream system
- Short-lived credentials, where a secret is issued for minutes rather than held indefinitely
Where they fit badly: ordinary human workflows. Nobody wants to authenticate to a secrets manager to get the office Wi-Fi password, and setting one up for a two-person team with no infrastructure is overhead without benefit. Where the boundary falls day to day is worked through in handing credentials between developers.
What Actually Changes the Decision
Four questions settle most cases. They are about the information, not the tool.
How long does it need to exist? Days or less points to a note. Indefinitely points to a manager of one kind or the other.
Who or what reads it? A person, once — note. A person, repeatedly — password manager. A machine — secrets manager. This single question resolves more cases than any other.
Does it need to be rotated? Rotation implies a system that knows where the credential lives. A note does not, and cannot: once sent, it is a copy nobody tracks.
Does access need to be tied to an identity? If you need to answer "who could read this, and who did," you need a system with identities and logs. Neither encrypted notes nor most consumer password managers are built to answer that at the granularity infrastructure requires.
Two further factors change the answer more often than people expect. Whether recovery is acceptable — if losing the content would be a serious problem, a tool with no recovery path is a risk you are accepting, not a security feature you are gaining. And whether an account is acceptable — sometimes the recipient simply cannot or will not create one, which rules out otherwise better options.
If you have settled on a category and now need to pick a product within it, the questions worth asking are different again — how to judge an encrypted note service covers those.
Practical Examples
| Situation | Better fit | Why |
|---|---|---|
| Office Wi-Fi password for a visitor | Encrypted note | Needed once, by a person, with no reason to persist |
| Your own login for a site you use weekly | Password manager | Reused indefinitely, and autofill is a real defence against phishing |
| API key read by a production service | Secrets manager | A machine consumes it; rotation and an audit trail matter |
| A credential a contractor needs for one afternoon | Encrypted note, then rotate | The handover is the problem; the credential should change afterwards |
| A shared vendor login the team uses monthly | Password manager (shared vault) | Recurring human use; needs to survive staff changes |
| Two-factor recovery codes | Password manager, or offline | Long-lived and high-consequence; an expiring note is the wrong shape |
| Sensitive text that is not a credential at all | Encrypted note | Nothing to rotate — it just should not sit in a mailbox forever |
Two of these deserve more than a row.
The contractor credential is the case people get wrong in an interesting way. The note is the right tool for the handover, but it does not finish the job. Once someone else has held a credential, the only thing that fully restores your position is changing it. Treat the note as a way to avoid a permanent copy in a chat log, not as a way to make the sharing risk-free.
Recovery codes look like a natural fit for an encrypted note — they are text, they are sensitive, you rarely touch them. But the moment you need them is the moment something has gone wrong, and a note with a forgotten password or a lapsed expiry is worse than useless then. Long-lived, high-consequence, needed under stress: that combination argues for durable storage, or paper in a drawer.
When an Encrypted Note Is the Wrong Tool
Worth stating plainly, since this site is in the encrypted-note category.
Use a password manager for anything a person will use more than once. It handles the recurring case better on every axis that matters — rotation, revocation, recovery, and knowing what you have.
Use a secrets manager for anything an application reads. Encrypted notes are not designed for programmatic retrieval, and pasting a production key into any browser tool means the key now exists in a place your infrastructure does not know about. Inkrypt has no public API for exactly this reason: an API that accepted plaintext would defeat the browser-side encryption the tool is built on.
Use something else entirely when the requirement is really about identity, authorisation or collaboration. Encryption protects content. It does not establish who someone is, does not enforce who may act, and does not give you the audit trail a compliance obligation asks for. If the real question is "who is allowed to see this, and can I prove who did," you need a system built around identity, not a system built around a password.
There is also the case where none of the three fits. If your concern is not that someone reads the content but that anyone learns the exchange happened, none of these categories addresses that — they hide what was written, not that a record exists.
How Inkrypt Fits
Inkrypt sits in the first category and nowhere else. Notes are encrypted in the browser with AES-256-GCM using a key derived from your password, so what reaches the server is ciphertext; there are no accounts; and shares can carry an expiry and a view limit. The security architecture documents the parameters.
The limits are the ones the category implies, plus some of our own. There is no password recovery, no list of your notes and no search — all three would require us to be able to read them. There is no file support and no API. Expiry and view limits stop a share link from working, though the encrypted record is not automatically purged from our database. There has been no third-party security audit, and our threat model is explicit that browser-delivered encryption cannot defend against an attacker able to compromise the code we serve.
Two details matter specifically for the credential-handover case, because they cut against the intuition the word "note" creates. First, expiry belongs to the share link, not to the note: a share stops resolving on schedule, but the note behind it has no expiry mechanism at all and persists until someone opens it and overwrites it. If you are using this pattern to hand over a credential, the durable artefact is the note, and rotating the credential afterwards remains the actual control. Second, if you password-protect the share, we store that password as an unsalted SHA-256 hash — a fast one — so it should be long and random rather than memorable, or you should use a passwordless share where the key is generated in your browser and never reaches us. Both points are documented in the threat model.
None of that makes Inkrypt an alternative to a password manager or a secrets manager. It is a way to move a piece of text to a person without leaving a permanent copy behind, which is a narrower job than either.
Frequently Asked Questions
Q1. Can I just use my password manager for everything, including one-off sharing?
Often, yes — if both people already use the same one. A manager's own sharing keeps the credential under management, which is better than an untracked copy. The gap appears when the recipient is outside your organisation or does not use a manager, which is the situation encrypted notes exist for.
Q2. Is it ever acceptable to keep an API key in a password manager?
For a personal project or a key nothing automated consumes, it is a reasonable place to keep a copy. Once a running service depends on that key, the important properties are programmatic retrieval, workload identity and rotation, and those are what secrets managers provide. The risk is not that the vault is insecure — it is that nothing knows the key is in use.
Q3. Do I need a secrets manager for a small team with one server?
Probably not at first. The cost is real and the benefit scales with the number of services and people. A reasonable interim position is credentials in a shared password-manager vault, individual accounts wherever the system supports them, and a note only for the moment of handover. Revisit when you have more than a couple of services or anyone joins or leaves.
Q4. If an encrypted note has no recovery, is that a security feature or a limitation?
Both, and they cannot be separated. A provider who can restore your content after you forget the password is a provider who holds a key. Choosing a tool with no recovery means accepting permanent loss as the price of the provider being unable to read it. That is a good trade for a note that lives a day, and a bad one for something you may need next year.
Q5. What should I do after sharing a credential through any of these tools?
Rotate it where you can. A credential that has been shared, however carefully, exists in more places than one — a screenshot, a clipboard history, a synced device. Rotation is the only step that returns you to a known state, and it is the step people skip.
Final Takeaway
Ask what the information is for rather than how sensitive it feels. Lifespan and consumer will point at the category, and the category matters more than the product inside it — a well-chosen tool used for the wrong job creates work that surfaces months later, usually at the worst moment.
For more on the encryption model these tools share, see client-side vs server-side encryption.
Technical claims here follow the primary references for the mechanisms discussed: NIST SP 800-38D for AES-GCM, NIST SP 800-57 Part 1 for key-management lifecycle including rotation, and the OWASP Secrets Management Cheat Sheet for the operational practices that separate a secrets manager from a note tool.