Almost every encrypted note tool encrypts your notes. The claim is usually true and rarely useful, because it leaves out the part that decides whether the service can read what you wrote.
What follows is how to work that out from the outside, in the order that gets you an answer fastest. At the end, the same questions are put to Inkrypt, including the answers that are not flattering.
Summary
The question that matters is not whether a service encrypts your note but who holds the key. If the provider can show you your note after you have forgotten your password, they hold it. Algorithm names and key sizes are secondary to that one fact.
The question that does most of the work
One sentence resolves most of the uncertainty: if I forget my password, can you get my note back?
A "yes" is not a scandal. Plenty of good products work that way, because most people would rather have recovery than secrecy from the vendor. It does mean the provider holds a key to your content, and the consequences follow whether or not the marketing mentions them: an insider can read the note, a breach at the application layer exposes plaintext, and a legal demand produces content rather than an unreadable blob.
A "no" only counts when it is architectural. "No, our policy forbids it" is a promise, and promises survive neither a change of ownership nor a subpoena. "No, the key is derived in your browser and never sent to us" is a design, and designs do.
If you want the underlying distinction in full, client-side vs server-side encryption covers who holds the key in each model and what that means during a breach.
A test you can run in about a minute
Vendor documentation can be checked without reading any code. Open your browser's developer tools, switch to the network tab, and create a note. Look at the body of the request that gets sent when you save.
If your text appears there in readable form, encryption is happening after your data leaves you. If you see a block of base64, it happened before. This is the single most useful check available to someone who is not a specialist, and it takes longer to describe than to perform.
The same trick works on the sharing flow. Create a share link, watch the request, and see whether the password you typed appears anywhere in it.
There is a third check worth doing on any service that puts a key in the link. Create a passwordless share, then compare the URL in your address bar with the request the browser actually made. The portion after the # should be present in the former and absent from the latter — that is the browser declining to transmit the fragment, and it is what makes a link-borne key invisible to the provider. If a service claims the key never reaches it but you can find that key in a request, the claim is false and you have just proved it.
Where the key goes
This is where designs differ most and where documentation is thinnest. Three patterns cover almost everything on the market.
The key travels inside the link. Your browser generates a random key, encrypts with it, and appends it to the URL after a #. The fragment is not included in the HTTP request the browser sends, so the provider genuinely cannot decrypt what it stores — though the fragment is still readable by scripts running in the page and by browser extensions. The practical consequence is that the link is the secret, and links get pasted into chat apps, ticket systems and mailboxes that keep them indefinitely.
The key is a password sent separately. The password becomes the encryption key, so the stored data cannot be opened by anyone holding only the link. This is stronger, and it depends entirely on the sender actually using a second channel rather than putting both in the same message.
The provider brokers the key. Convenient, works across devices, and means the provider can decrypt.
None of these is wrong. They fail differently, and the failure you are accepting should be a decision rather than a surprise. Secure link sharing works through the trade-off between the first two in more detail.
What "deleted" means here
Expiry and view limits are the features people trust most and interrogate least. "Deleted" can mean removed from the live database, removed from backups, removed from a cache, or simply no longer served. Services usually mean the last of those and let readers assume the first.
Worth asking directly: does the record itself get erased, or does the endpoint stop returning it? How long are database backups retained? Is there a process that purges expired records, or do they accumulate?
There is also a limit no service can engineer around. Expiry protects against the link being found later. It does nothing about the recipient, who can screenshot, copy or forward the content during the seconds they had access. A tool that implies otherwise is overselling.
What good and weak answers sound like
| Question | Weak answer | Strong answer |
|---|---|---|
| Can you recover my note? | "Contact support and we'll help." | "No. The key is derived from your password in your browser and never reaches us." |
| What encryption do you use? | "Military-grade encryption." | "AES-256-GCM, key derived with PBKDF2-HMAC-SHA256, parameters published." |
| What do you store? | "Your data is stored securely." | A field-by-field list, including titles, timestamps and logs. |
| What happens at expiry? | "The note is destroyed forever." | A description of what stops serving, what is erased, and what backups hold. |
| Has it been audited? | Silence, or a badge with no report behind it. | A linked report, or a plain statement that there has been no audit. |
Unfamiliar terms in the right-hand column are worth looking up rather than nodding at; the glossary covers AES-GCM and PBKDF2 in plain language.
Inkrypt, by the same standard
Publishing an evaluation framework and exempting ourselves from it would be worthless. Here is how Inkrypt answers.
Where encryption happens. In your browser, through the Web Crypto API, before anything is transmitted. The algorithms and parameters are published on the security architecture page, and the network-tab test above works on us.
What we store for a note. The ciphertext, a per-note salt, an initialisation vector, a label recording which key-derivation parameters were used, a schema version, and created and updated timestamps. We also store the note's name in plain text, because it is the URL. A note called acme-prod-root-password tells us, and anyone who sees the link, a great deal before a password is entered.
What we store for a share. More than the note itself. Alongside the encrypted snapshot, its salt, IV, key-derivation label and creation timestamp, a shared record holds a hash of the token from the link, the expiry timestamp if you set one, the view limit if you set one, a running count of views, and — when you set a share password — a hash of that password used to gate the endpoint. Your browser also receives a viewed_note_ cookie, scoped to that share, which lasts a week and stops a reload from consuming another view.
What expiry and view limits actually do. They stop the share endpoint from serving the note once the deadline passes or the view count is reached. They do not currently delete the stored record: the encrypted row remains in the database, and there is no automatic purge. Our backup retention is not documented, and rather than estimate it here we will say plainly that it is not something we have published.
How we store a share password. Badly enough that it belongs in this list. When you password-protect a share link, we store a single-round, unsalted SHA-256 of that password to check what a recipient types. That is a fast hash — precisely the construction the "weak answer" column above is warning about — and it sits alongside a content key derived with 310,000 PBKDF2 iterations. The hash is not the decryption key, so a database breach does not directly yield your content. But your share password is what the content key comes from, so recovering a weak one from the fast hash does yield it, and the expensive derivation stops being the slow step. The practical answer is to make share passwords long and random, or to use a passwordless share where the key never reaches us. We would rather write this down than have you find it.
Audits. There have been none. The parameters are standard and documented so they can be assessed directly, but there has been no third-party cryptographic review.
The weakness we cannot design away. Encryption that runs in a web page depends on the page being the code we intended to serve. An attacker able to compromise or compel our code delivery could serve a modified script that captures a password before encryption happens. Our threat model states this outright and recommends an installed, independently audited application for anyone whose adversary operates at that level. The mechanics of why browser-delivered encryption carries this cost are covered under client-side encryption.
When this kind of tool is the wrong choice
An encrypted note moves a short-lived secret to someone once. It is a poor place to keep credentials you use daily, and it is not a communication channel.
For long-term storage of many credentials, with rotation and breach alerts, a password manager is the right tool and this category is not competing with it. For an ongoing private conversation, use an end-to-end encrypted messenger. If your risk is not that someone reads the content but that someone learns you communicated at all, no note service solves that — encryption hides what you wrote, not that a record exists, when it was created, or how often it was opened.
Recognising that a category does not fit is worth more than any comparison of features inside it. Where the boundaries actually sit is the subject of encrypted notes vs password managers vs secrets managers.
Frequently Asked Questions
Q1. Is a "password-protected" note actually private, or is that just marketing?
It depends on what the password does. If it is only an access gate checked by the server, the server can still read the note. If it derives the encryption key on your device, the content is genuinely unreadable to the provider. Both are described with the same two words, so ask which one you are getting.
Q2. Does open source guarantee a service is safe?
No, but it changes what is checkable. Published source lets a reviewer confirm the design matches the description. For a web application it does not prove the code running in your browser today matches the published repository, which is a separate problem from the licence.
Q3. Should the absence of a security audit rule a service out?
Not automatically, but it should change how much you trust it with. An unaudited service using standard, documented algorithms is reasonable for a credential handover that will be rotated afterwards, and a poor choice for something whose exposure would be serious and permanent.
Q4. If a service can email me a reset link for a protected note, what does that tell me?
That it can decrypt the note. Recovery and provider-blind encryption are mutually exclusive, and no policy language resolves that. It is a legitimate product decision, but it should be one you make knowingly.
Related reading
For the encryption model underneath all of this, start with client-side vs server-side encryption. If a service describes itself as zero-knowledge, what that term actually means is worth reading before you accept it as a credential. For the narrower question of browser notepads that need no account, see encrypted notepad tools with no signup.
Technical claims here follow the standard references for the primitives involved: NIST SP 800-38D for AES-GCM, RFC 8018 for PBKDF2, and the W3C Web Crypto API specification.