Can a Journaling App Read Your Entries? 7 Questions to Ask
Ask seven questions about AI journal privacy, encryption, recovery, sharing, and device security before deciding where your private entries belong.
A journaling app may keep strangers away from your pages while the company running it can still technically read them. Another app may encrypt selected entries before they leave your device. Both may use the word “private,” but they describe different boundaries.
Before you place years of personal writing in any service, ask what privacy means in practical terms. The answer is rarely a single badge or setting. It depends on where readable text exists, who controls the keys, what remains outside encryption, and what happens when you search, share, recover, or use an AI feature.
1. Does “private” mean private from other people—or from the service?
An account-private entry is hidden from the public and from other account holders. That is important, but it does not necessarily prevent the service’s systems or authorized staff from accessing the stored text.
End-to-end or client-side encryption makes a stronger and more specific promise: protected content becomes unreadable before it reaches the service, and the service does not hold the usable key needed to turn it back into words. Ask the provider to state plainly whether it can technically read your entry—not only whether it intends to.
A login password, HTTPS, database encryption, and end-to-end encryption solve different problems. A password controls account access. HTTPS protects data while it travels over the network. Server-side encryption can protect stored disks or backups, but the running service may still hold the keys. Client-side encryption changes who can decrypt the content in the first place.
2. Where does encryption happen?
Ask whether the entry is encrypted in your browser or app before upload, or only after the server receives readable text. The location matters because each design protects against a different threat.
The OWASP Cryptographic Storage guidance recommends beginning with the threat model and explains that encryption at the application, database, filesystem, and hardware layers provides different protection. Disk encryption may help if hardware is stolen, for example, but it does not stop a compromised application server from reading data it normally decrypts.
Useful privacy documentation names both the protected layer and the remaining limits. “Encrypted with AES” is not a complete answer if it does not explain where encryption happens and who has the key.
3. Who controls the decryption key—and how does recovery work?
Encryption is only as meaningful as its key boundary. Find out whether the service stores a usable key, whether your password unlocks a separate key on your device, and whether a recovery key exists.
Then ask a difficult but revealing question: if you forget your password and lose every unlocked device, can support restore the old encrypted entries? A “yes” may mean the service has a recovery or key-escrow path. A “no” may indicate a stronger user-held key model, but it also means you carry more responsibility.
Neither trade-off should be hidden. OWASP’s key-management guidance notes that data encrypted with a lost key cannot be recovered and that long-term encrypted storage needs a deliberate backup or recovery design. If an app gives you a Recovery Key, store it separately from the device and account it protects. Anyone holding that key may be able to read the encrypted journal.
4. Which parts of an entry are actually encrypted?
“Your journal is encrypted” can conceal a patchwork of boundaries. Check each part separately:
- Entry title and body.
- Photographs, audio, video, and other attachments.
- Links and link descriptions.
- Tags, moods, people, and locations.
- Search indexes, summaries, and generated insights.
- Exports, backups, and deleted copies awaiting removal.
A service may protect the body while leaving titles or tags readable so it can organize and search them. That can be a reasonable product decision. The important question is whether you understand the decision before using those fields for sensitive details.
For a practical example of the trade-off, read how search works in an encrypted journal.
5. What metadata remains visible?
Even when an entry’s words are ciphertext, the service may still need operational information such as an account identifier, record ID, creation date, update time, filename, file size, or protection state. Reminder times and public-sharing status may also need to remain readable for those features to work.
Metadata is not the same as the content of a private page, but it can still reveal patterns. A trustworthy app lists what remains visible instead of implying that encryption makes the entire record disappear.
Decide where you place identifying details. If tags remain outside encryption, use them as broad organizing labels rather than miniature summaries of the entry.
6. What happens during search, AI processing, and sharing?
Features that interpret writing need readable text somewhere. Full-text search may run on a server, on your device after local decryption, or over a limited plaintext index. An AI assistant may process text locally or send selected content to an external provider. Ask where that processing happens, what is sent, how long it is retained, and whether it is used for training.
Apple’s Journaling Suggestions privacy documentation is useful because it names the data categories involved, describes on-device processing, and states the conditions under which Journal entries stored in iCloud are end-to-end encrypted. Look for that level of specificity from any app you consider.
Sharing creates a separate boundary. A protected entry cannot remain unreadable to the service and also become an ordinary public web page. Publication should therefore be an explicit action with a clear warning about what becomes readable and indexable. Private writing and public publishing should never blur into one setting.
7. What protects the page while your device is unlocked?
End-to-end encryption is not a force field around an unlocked screen. If your browser or app already holds the key, malicious software, a harmful extension, injected page code, or someone using the open device may be able to reach the readable content.
OWASP’s browser-storage guidance cautions that browser-side storage should not be assumed confidential from a person or process that can read the browser profile. Review the app’s logout behavior, session expiry, device lock support, and instructions for shared computers. Keep the operating system and browser current, remove extensions you do not trust, and sign out when leaving a shared device.
Encryption can reduce the harm of a server or database compromise. It does not replace device security or careful sharing.
A ten-minute privacy check before you commit
You do not need to audit cryptographic code to make a better choice. Open the app’s privacy, security, recovery, search, AI, and sharing documentation, then write down seven short answers:
- Can the service technically read an ordinary private entry?
- Where does readable text become ciphertext?
- Who can obtain the decryption key?
- Which fields, files, and derived data are protected?
- Which metadata remains visible?
- What changes when search, AI, recovery, or sharing is used?
- What happens after logout, device loss, export, and deletion?
If the answers rely on words such as “secure,” “military-grade,” or “private” without naming the mechanism and limits, keep asking. Good privacy language should make an informed decision easier, not ask you to trust an adjective.
How Inpages.me draws the boundary
Inpages.me separates visibility from protection. Standard Memories stay private inside your account, while their writing remains readable to the service for the features you choose. Protected Memories encrypt the title, content, links, keepsakes, and inline images in your browser before storage. Hashtags and operational details such as record IDs, timestamps, filenames, and file sizes remain outside that content-encryption promise.
Check-ins have their own boundary: protected details include the note, location, people, and new photographs, while mood and emotion use Standard protection in both modes. A public Memory must use Standard protection and be deliberately published; Protected Memories cannot be shared as public pages.
When the optional Journal Assistant is available and you turn it on for a journal, it can use Standard Memories in that journal. It skips Protected Memories. The Recovery Key belongs to the journal owner and can unlock Protected writing on another device. While the vault is unlocked, its key stays in the browser for convenience and is cleared on logout. This reduces server-side access to Protected content, but it does not protect an already unlocked device from harmful extensions, injected scripts, or malware.
Read the broader digital journal privacy checklist or compare the criteria in how to choose a private journaling app. When the boundary fits what you need, begin with one quiet page on Inpages.me.
Sources and further reading
- OWASP Cryptographic Storage Cheat Sheet
- OWASP Key Management Cheat Sheet
- OWASP HTML5 Security Cheat Sheet
- Apple Journaling Suggestions & Privacy
Your first quiet page
Keep writing, without turning your life into content.
Inpages.me is a calm digital journal for thoughts, photographs, and details you want to return to—without an audience or an endless feed.
Choose and pay for a membership before writing your first entry.
