FAQ : Answers & Help

Yes, Inkrypt is completely free. We do not require any subscriptions, credit cards, or hidden fees to create and share encrypted notes.

Yes, if you open an existing note and provide the correct password, you can edit its contents. The note will be re-encrypted and saved securely.

Yes. Anyone with the correct password can open the note and choose to delete it permanently. Once deleted, the ciphertext is removed from our servers and cannot be recovered. Note that a share link is stored as a separate encrypted snapshot, so deleting the note does not necessarily retract a link you have already sent — that share stays governed by its own expiry and view limit.

When you set a view limit (e.g., 5 views), our servers count how many times the encrypted data is requested. Once that limit is reached the link stops working — we decline any further request for it. The encrypted record itself is not automatically removed from the database, so the accurate description is that the note becomes unavailable rather than erased.

Inkrypt's own code does not log or store IP addresses, and we require no personal information (no email, no name). Your IP address is still visible to our hosting provider and to third-party services your browser contacts, such as Google for advertising and analytics, because it is required to deliver a response. We operate no tracking pixels of our own, and nothing we measure is linked to your note contents.

Currently, Inkrypt is optimized for text. You can securely store large text documents and code snippets. We do not support uploading images, videos, or binary files at this time.

Absolutely. Inkrypt is a fully responsive web application that works seamlessly on all modern mobile and desktop browsers without needing to install a dedicated app.

Because Inkrypt requires a connection to our servers to retrieve and store the encrypted ciphertext, you need an active internet connection to create, read, or edit notes.

Currently, Inkrypt is designed for user-to-user sharing via the web interface. We do not offer a public API for programmatic note creation at this time, as our focus is on client side encryption strictly within the browser environment.

We can see the note's name, because it is the URL and is stored in the clear. We can see the ciphertext, the salt, the initialisation vector and the key-derivation label, none of which reveal content. We can see when a record was created or updated, and our hosting provider records ordinary connection metadata in its server logs the way any web host does. We cannot see the note's text or your password, because neither ever leaves your browser in a readable form. Treat the note name as public: never put a secret in it.

The note is unrecoverable, and that is a design decision rather than a limitation we intend to fix. Your password never reaches our servers, so we hold nothing that could decrypt the note or verify a reset. Any service that can email you a recovery link for encrypted content is necessarily able to decrypt that content itself. The trade-off is deliberate: we would rather be unable to help you than be able to help an attacker who compromises us.

It depends on what the link carries. By default the decryption key travels in the URL fragment — the part after the '#' — which browsers do not send to servers, but which is still fully visible to anyone who reads the message and is retained in that platform's chat history. If you set a separate share password, the link alone is not enough and the password should travel by a different channel. For anything genuinely sensitive, use a share password, set a view limit, and assume the message itself may persist longer than you expect.

No, and we would rather be precise about this than reassuring. When a share reaches its view limit or its expiry, the endpoint stops serving it and the link is dead for practical purposes. The encrypted record itself is not automatically purged from the database. The accurate description is that the note becomes unavailable, not that it is erased. It remains ciphertext we cannot read either way, but if your threat model requires guaranteed deletion, this distinction matters.

A compromised device where someone else has access to the plaintext before encryption runs. A weak password, because key derivation makes each guess expensive but cannot make a dictionary word strong. The recipient choosing to copy, screenshot or forward what you sent. For those risks, an audited, installed application is the right tool.

That pause is the key derivation running in your browser. Your password is stretched through PBKDF2-HMAC-SHA256 over many thousands of iterations before it becomes an AES key, and that work is deliberately slow. The cost you pay once per save is the same cost an attacker pays on every single guess, which is the entire point of a password-based key derivation function. It is a feature of the design rather than a performance problem, and it is more noticeable on older phones.

We can be compelled to hand over what we hold, which is ciphertext, a salt, an initialisation vector and a note name. We cannot be compelled to hand over plaintext or a password, because we do not have them and no order can create data we never received. This is the practical consequence of zero-knowledge architecture rather than a promise about our conduct. Note that the note name is stored in the clear and would be disclosed along with everything else.

For most everyday purposes it is strong, and it uses the same vetted primitives through the browser's Web Cryptography API rather than a custom implementation. But there is one honest difference: with an installed application you verify the code once, whereas with a website your browser fetches the code fresh on every visit. That means you are trusting us not to serve a modified version, and trusting the delivery path. If your adversary is capable of compelling or compromising code delivery, that is a real distinction and you should choose an audited, installed tool instead.

No. Expiry times and view limits are properties of a share link, not of the note behind it. A note itself has no expiry: once created, its encrypted record stays until you open it and overwrite or delete it. If you have seen 'self-destructing' used about Inkrypt, that describes share links only. When you need a note gone, you have to remove it yourself — there is no scheduled deletion to rely on.

No. A share is a separate encrypted snapshot with its own key, so expiry, view limits and revocation act only on that snapshot. When a share link stops resolving, the note is untouched and still opens with its own password. The reverse is also worth knowing: deleting the note does not retract share links you have already sent, because those snapshots are stored independently.

Treat the whole link as the secret. For a passwordless share the decryption key is the part after the #, so anyone who receives the complete link can read the note — forwarding it forwards the access. The fragment is never sent to our servers, which is why we cannot read the note, but that protects it from us, not from whoever holds the link. If a link might be forwarded, set a short expiry, set a low view limit, or add a share password and send that password through a different channel.

Honestly: less strongly than the note content itself. When you password-protect a share, we store a single-round, unsalted SHA-256 of that password to check what a recipient types. That kind of hash is fast, so it is far more exposed to guessing than the 310,000-iteration derivation protecting the content. The hash is not the decryption key and a breach does not directly hand anyone your content — but because your share password is what the content key is derived from, a weak one can be recovered and then used. So make a share password long and random rather than memorable, or skip it and use a passwordless share, where the key is generated in your browser and never reaches us at all.