Encrypted notes

How it works

An encrypted note is an ordinary plain note whose body you encrypted on your own machine before sending it. Fresh Jots never sees your key and cannot derive it, so it stores and returns the ciphertext exactly as you sent it. You mark the note as encrypted so the app treats it correctly (see below); the confidentiality itself comes entirely from your own encryption, not from anything we do.

The flow is: encrypt locally, store the ciphertext, then download and decrypt locally when you need to read it. For example, with a tool you already trust:

# encrypt a file to base64 ciphertext with your own passphrase
openssl enc -aes-256-gcm -pbkdf2 -a -in secret.txt -out secret.b64

# paste the contents of secret.b64 into a new encrypted note, then later:
# copy the note's ciphertext back out and decrypt it locally
openssl enc -d -aes-256-gcm -pbkdf2 -a -in secret.b64 -out secret.txt

What we can and can't see

• We can't read it. For a note you actually encrypted, the stored bytes are ciphertext. We never hold your key, so we cannot decrypt, search inside, or recover the contents — and neither can anyone who compels or breaches us.
• We can't verify it. The encrypted marker is your declaration, not something we check — we don't inspect the bytes. If you mark a note encrypted but paste plaintext, the app will still treat it as opaque, but it won't actually be protected. The protection is your encryption, not the flag.
• This is not whole-service end-to-end encryption. Only the notes you choose to encrypt are unreadable to us; ordinary notes are stored as described on our Security page so we can render, search, and export them.
• Metadata is still visible. The note's title, filename, size, timestamps, and folder are stored in the clear (that's how the note stays findable) — so don't put secrets in the title.

Doing it safely

• Encode as text. Store base64 or hex, never raw binary — the note body is a text field, and appends split on newlines.
• Whole-body vs per-record. For a normal note, encrypt the whole body as one ciphertext. For an append-only note, encrypt each append as its own self-contained ciphertext line, so you can split on newlines and decrypt each independently — a single stream encrypted across appends won't decrypt.
• Read by downloading. The web view and search only ever see ciphertext, so read and search locally after you decrypt; the note's .txt download gives you the raw ciphertext. The web editor is read-only for encrypted notes — copy the ciphertext out to decrypt locally, and replace the contents through the API if you need to change them, so a stray keystroke can never overwrite your ciphertext.
• Webhook appends carry a timestamp line. Appends made through the direct API (POST /notes/:id/append or the by-filename append) are stored byte-for-byte, but appends sent to a note's inbound webhook URL (/h/<token>) get a plain-text ── … UTC ── header line prepended to each entry. When you decrypt a webhook-fed stream, skip those header lines and decrypt the ciphertext lines between them.
• Keep your key safe. Back it up somewhere separate — it is the only thing that can recover the data, and we cannot reset or reveal it.
• Still get your alerts. Dead-man's-switch and append alerts are time-based, so an append-only encrypted note still warns you when a stream goes silent — even though we can't read what it reported.

Availability

Encrypted notes are personal notes only — available on every personal plan, including Free, but not in Team workspaces, since a team note is shared with members who don't hold your key. They are plain-text notes, so you'll find them in Code mode. You can create one through the API or MCP by sending client_encrypted: true when you create the note — or open an append-only encrypted log stream in a single call with the append-by-filename endpoint or the MCP append_to_note tool.