Apps are how you edit.
Files are what you own.

When you adopt a notes app, what do you actually acquire? The marketing says features: blocks, sharing, search, AI. But features are rented; they change with every release and vanish with every shutdown. The only thing you can permanently acquire from a notes app is the artifact it leaves behind. Ten years from now, the app you are using today will have changed beyond recognition or stopped existing, and the only question that will matter is: can you still open your notes? That is why we think of the file, not the app, as the product.

Databases you rent, files you keep

Most modern knowledge tools do not give you documents at all. Your writing lives as rows in a database you will never see, on servers you do not control, reachable only through the vendor's interface and at the vendor's pleasure. This is not a criticism of any particular company; it is simply the architecture, and it has real consequences. If the service is down, your notes are down. If your subscription lapses, your access lapses. If the company pivots, sunsets the product, or gets acquired, your knowledge is a line item in someone else's migration plan.

A file has none of these dependencies. It sits in a folder you chose, on a disk you own. It opens without a login, without a network, without the company that created it existing. You can copy it, back it up with the tools you already trust, put it in a git repository, attach it to an email. The file outlives the app, which is exactly what you want from something holding years of your thinking.

Why "you can always export" is not ownership

Every database-backed tool answers this concern the same way: there is an export button. And there is, usually somewhere in settings, producing a zip file you will download at most twice. But export is not ownership, for three reasons.

First, exports are snapshots. Your export is exactly as current as your discipline, and nobody exports weekly for years. The gap between your last export and the day you need it is where knowledge dies.

Second, exports are lossy at the edges. The flattened output rarely captures everything the app knew: structures approximated, metadata dropped, references turned into dead text. The export is a photograph of your notes, not your notes.

Third, and most subtle: export being an event, rather than the default state, tells you where power sits. When your data's native home is the vendor's database, leaving is a project. When your data's native home is your disk, there is nothing to leave. NoteX inverts the default: the file on disk is the primary copy, and it is the cloud that is optional. Export still exists (Markdown, self-contained HTML, in bulk), but it is a convenience, not an escape hatch.

Designing .notex: what a note file should be

If the file is the product, the format deserves real design. Here is what we decided and why.

JSON, open, documented. A .notex file is plain JSON: structured, human-inspectable, parseable in any language in one line. No binary container, no proprietary encoding. If NoteX vanished tomorrow, a competent developer could write a converter in an afternoon, and honestly, so could an AI agent. That is not a failure of lock-in; it is the point.

Metadata inside the file. A note is more than its text: it has an icon, a cover, timestamps. Most apps store that in a sidecar database, which means the note falls apart the moment it leaves. In .notex, the metadata travels inside the file. Copy a note to a USB stick and it arrives whole.

Icons that travel. The clearest example of that principle: because a note's icon lives in the file, NoteX Desktop renders it in Windows Explorer itself, on the desktop, and in open and save dialogs. Your Reading List looks like your Reading List even when NoteX is closed. The full story is on the file icons page.

Markdown as a first-class citizen. Not everything needs the richer format. NoteX edits plain .md and .mdx files natively, because a decade of existing knowledge lives in Markdown and it should not need converting to be welcome.

Git-friendly knowledge

Files unlock a workflow databases cannot offer: version control. Because notes are kilobytes, not megabytes, and stored as structured text, they behave beautifully in git: meaningful diffs, real history, branches for drafts, pull requests for team docs if you want them. Engineers have enjoyed this relationship with their code for decades; there is no reason your knowledge deserves less. The engineering use case shows what specs and ADRs living next to the code actually looks like, and the broader ownership story is on files you own.

Ownership and collaboration are not enemies

The usual objection: files are a lonely format, and teams need real-time collaboration, databases, and sharing. True, and that is why NoteX has two surfaces. NoteX Web is the collaborative workspace with live cursors and shared databases; NoteX Desktop is the local-first home where notes are files, with two-way sync between your devices and workspaces when you sign in, against Lisan's cloud or a server you host yourself. You do not have to choose between owning your knowledge and working together on it. You only have to refuse the architecture that says you must.

Apps are how you edit. Files are what you own. Choose tools accordingly, ours or anyone else's.