Short answer: A private journal app should encrypt entries at rest, store the primary copy on your device, work offline, export to open formats, and have public source code. These five criteria protect your writing regardless of what happens to the app or its publisher.
Choosing a private journal app is not about comparing feature lists. It is about understanding what protects your entries five or ten years from now, not just during the first week of use. Journaling compounds. A tool that feels acceptable in month one can become hard to leave after years of daily writing.
The right evaluation criteria reduce to a few structural questions about the app's architecture. The answers tell you more than any marketing page.
1. Does it encrypt entries at rest?
Encryption at rest means entries are encrypted before they are written to permanent storage. This is different from encrypting the connection to a server (TLS) or adding a password lock screen. If the database file on disk contains plaintext, the app is not encrypting at rest regardless of what the login screen looks like.
Ask: if I copy the database file to another machine, can I read the entries without a password? If the answer is yes, the encryption model is cosmetic.
Look for AES-256-GCM or equivalent. Avoid apps that mention encryption only in the context of "secure connection" or "password protection" without specifying what happens on disk.
2. Where does the journal actually live?
The most important architectural decision is storage location. Is the primary copy on your device or on a server?
A local-first app stores entries on your own machine and does not require an account to function. A cloud-first app stores entries on a server and treats the local copy as a cache. The difference affects who can access your writing, what happens when the service changes its terms, and whether you can keep writing when the network is unavailable.
For long-form private writing, local-first is almost always the better default. You can back up your files yourself using tools you already trust. You are not relying on a third party to preserve access.
3. Does it require a network connection?
A private journal app should work without internet access. If the app stops functioning when you disconnect, it is not truly offline. An app that sends your entries to a server — even encrypted — creates a dependency on that server's continued operation and trustworthiness.
The stronger guarantee is an app that has no HTTP client at all. No network code means no telemetry, no sync service, and no update pings. It also means the app cannot change its data-sharing behavior in a future update, because the transport layer does not exist.
4. Can you export your writing in an open format?
An export path is not a backup feature. It is an exit guarantee. If the app stops being maintained, if you change operating systems, or if you simply want to move your writing elsewhere, you should be able to take your entries with you in a format that other tools can read.
JSON and Markdown are the two most portable options. JSON preserves structure and is machine-readable. Markdown preserves formatting and is human-readable. An app that supports both gives you the broadest compatibility.
Avoid apps that export only to proprietary formats or that require the app itself to be running in order to access your data. If reading your own writing depends on the app continuing to exist, you do not own the journal.
5. Is the source available?
Open source is not a requirement for privacy, but it is the strongest form of transparency. If the source code is public, anyone can verify that the encryption is implemented correctly and that no data leaves the machine. Closed-source apps can make the same claims, but you are trusting the publisher rather than verifying the implementation.
Open source also reduces the risk of abandonment. If the original maintainer stops working on the project, someone else can fork it and continue. Your journal does not become stranded on an unmaintained codebase.
The checklist in one place
When evaluating a private journal app, ask:
- Does it encrypt entries before they are written to disk?
- Is the primary copy stored on my device?
- Does it work without a network connection?
- Can I export to JSON and Markdown?
- Is the source code public?
If an app answers yes to all five, it meets the structural baseline for private journaling. Everything else — rich text, calendar views, statistics, themes — is secondary. Those features matter for daily use, but they do not protect your writing. The storage model does.
Where Mini Diarium fits
Mini Diarium is a local-first desktop journal app for Windows, macOS, and Linux. It encrypts every entry with AES-256-GCM before writing to the local SQLite database. The app has no HTTP client, so it cannot send data anywhere. Exports are available in JSON and Markdown, and the full source is on GitHub under the MIT license.
If you want the shorter product overview, start with the encrypted journal guide. If you are comparing Mini Diarium to other tools, the comparison page covers Day One, Notion, Obsidian, Standard Notes, and Joplin on the same criteria listed above.
For more on what encryption at rest actually means, read what is an encrypted diary. For the desktop-specific requirements, the post on private diary apps for desktop goes deeper on what matters when you write on your own machine.