How we protect your journal
TLS encryption in transit, strict access controls, and optional client-side encryption you control.
How encryption works
Turn on client-side encryption and your words are encrypted before they ever leave your device.
You write
Your journal entry starts on your device
Optional device encryption
If enabled, AES-256-GCM encryption runs using your key
Ciphertext syncs
With encryption on, only encrypted data leaves your device
We store it
Encrypted data we cannot read, or TLS-protected data if encryption is off
Security in depth
Multiple layers of protection for your most personal thoughts.
End-to-end encryption explained (optional)
By default, your entries travel to our servers over TLS-encrypted connections and are protected there by strict per-user access controls, but they are stored in readable form. If you turn on client-side encryption in Settings, entries you write afterward are encrypted on your device before they ever leave it. That content travels to our servers already scrambled, and even if someone intercepted it, they would see meaningless ciphertext. AI-generated summaries and structured metrics are always stored separately to power features like narratives and insights, and are never end-to-end encrypted, regardless of your setting.
Your encryption keys (if you enable encryption)
If you turn on client-side encryption, your key is generated on your device and never leaves it unencrypted. When you add a new device, you must approve it from an existing device. This device approval flow ensures only your authorized devices can access your data. A recovery phrase lets you regain access if you lose all devices.
Web security
We enforce a strict Content Security Policy (CSP) that prevents cross-site scripting attacks. Cryptographic operations run in isolated contexts. All connections use HTTPS with modern TLS. Security headers protect against clickjacking, MIME sniffing, and other common web attacks.
What encryption does not cover
We want to be transparent: some metadata is not encrypted. This includes timestamps (when you created entries), device information (which device synced what), and ciphertext sizes. This metadata is necessary for sync to work but does not reveal what you wrote.
Encryption Algorithm
AES-256-GCM with unique 96-bit IV per entry
Key Derivation
PBKDF2-SHA256 with minimum 100,000 iterations
Mobile Key Storage
Platform keychain (iOS) / keystore (Android)
Web Key Storage
Secure browser storage with isolation
Key Logging
No key material in logs or error reports
Transit Security
TLS 1.2+ for all network requests
Note: These specifications may evolve as we adopt stronger cryptographic standards. We will always communicate changes in advance and ensure backward compatibility for your existing data.
New devices need your approval
If you have client-side encryption turned on, a new device cannot access your encrypted data until you approve it from an existing device. This device approval flow applies to encryption keys; account sign-in is separately protected by strict access controls.
Device approval required
New devices must be approved from an existing trusted device
Key exchange protocol
Encryption keys are securely transferred between your devices
Recovery phrase backup
A recovery phrase lets you regain access if you lose all devices
Revoke anytime
Remove device access instantly from your security settings
Approve new device
If you use client-side encryption, keys transfer securely between your devices. You control access.