Frequently asked questions

No. The note is encrypted in your browser before it is sent, with a key generated on the spot. That key is never transmitted to our server: we only store ciphertext we are unable to decrypt. This is not an internal policy promise, it is a technical impossibility.

AES-256-GCM, through the Web Crypto API built into your browser. Each note gets a random 256-bit key and a unique initialization vector. GCM also guarantees integrity: ciphertext altered in transit is rejected instead of being decrypted.

In the URL fragment, the part after the #. Browsers never send that part to the server, neither in the request nor in logs. The full link is therefore the only thing that can unlock the note.

Open your browser's developer tools (F12), Network tab, then create a note. The request that goes out contains only an unreadable block of ciphertext, never your text or the key.

Like any server, yes. But an attacker would only find ciphertext without the keys, so nothing usable. That is the whole point of client-side encryption: the security of your notes does not depend on the security of our server.

The note is deleted from our database the moment it is opened. If anyone else tries the link afterwards, the note no longer exists. It is the recommended option and is on by default.

With one-time access, until its first read. You can also set an expiry of 10 minutes, 1 hour, 24 hours or 7 days: after that, the note is refused and deleted even if nobody read it.

The note is gone for good. The key only exists in the link; without it nobody, including us, can decrypt the content. Just create a new note.

Either it expired or the link was already opened. Some chat and link-preview tools open URLs automatically to build a thumbnail; to prevent that, ShareSafeNote asks for a click on "Decrypt" before fetching the note. If in doubt, treat the secret as exposed and change it.

Use a different channel than the one the secret would normally travel through, for example an encrypted messenger. For a very sensitive password, send the link through one channel and confirm receipt through another.

A space where you type code that your guests see appear in real time, with syntax highlighting. It is handy for a quick code review or for helping someone without sharing your screen.

Yes, end to end, on the same principle as notes: the key lives in the session link and never leaves the participants' browsers. The server relays ciphertext and keeps it in memory only, never on disk.

At most 6 hours, and it closes after 2 hours without activity. Once closed, its content is gone from the server's memory.

No. There is no sign-up, no password and no email address to give. Data we never collect cannot leak.

Yes. ShareSafeNote is funded by a few ads shown only on informational pages (home, guides, FAQ, legal pages), never on the pages where you write or read a note, nor inside a code session.

For each note: the ciphertext, its creation date and its optional expiry date. Your IP address is only used briefly, in memory, to limit abuse. Details are in our privacy policy.

In Canada, on an OVHcloud server in Beauharnois, Québec. Since everything is encrypted before it is sent, the server never holds readable content anyway.

Yes, that is the main use. For a team that shares access continuously, a password manager is still the better tool; ShareSafeNote is made for one-off handovers. See our guide on sharing API keys.

The link contains the key: whoever gets it can read the note. A synced browser history, a shared clipboard or a screenshot is enough to expose it. Likewise, if the recipient's device is compromised, no encryption protects what is displayed on screen.

If the note has not been read yet, one-time access protects you: whoever opens it first destroys it, and the legitimate recipient will see that it no longer exists. Either way, change the secret as soon as you have a doubt.