NotesNudge the notes you never go back to

Plain Text and the Long Term

Plain text files in a folder is the least impressive way to keep notes and the one most likely to still work in twenty years.

The argument for it is usually made badly — as taste, or as suspicion of software companies. The actual case is narrower and stronger.

For a workplace-oriented comparison with this kind of workflow, this resource provides additional context.

The case

The format has no owner. A text file does not depend on a company, a licence, a subscription or a format specification anyone controls. Every argument about vendor lock-in dissolves, not because the vendor is trustworthy but because there is nothing to lock.

Every tool can read it. Editors, scripts, search utilities, backup systems, whatever exists in 2040. You are not choosing an application; you are choosing a format and renting applications to view it.

Migration becomes trivial. Changing tools means changing which program opens the same folder, which is the difference between a decision and a project.

For an independent external reference related to this topic, see Joplin.

And it degrades gracefully. A partially corrupted database is often unreadable. A partially corrupted text file is a text file with a hole in it.

Markdown adds light structure — headings, emphasis, links — while remaining readable without anything rendering it. That is the sweet spot, and it is why it won.

What you give up

Being honest, because plain-text advocacy usually is not.

Structured fields. Dates, statuses, relations, tables you can query. Plain text can fake these with conventions; a database does them properly. If your notes are really a small database — reading log, contacts, an inventory — a database is the right tool and text files are stubbornness.

Real collaboration. Simultaneous editing, comments, permissions. Text files in a synced folder handle one person well and several people badly.

Rich media in the document. Embedded drawings, canvases, recordings. Attachments alongside a text file work; embedded and editable in place does not.

Some interface conveniences. Instant filtered views, kanban boards, backlink panels — these exist for plain-text tools and are provided by the application rather than by the format, which means they leave when it does.

The realistic middle

Almost nobody needs everything to be plain text.

Notes and writing: plain text. This is where longevity matters most and structured features matter least. Thinking notes have no fields to query.

Genuinely structured data: a database. A reading list with ratings and dates is a table, and pretending otherwise is unpleasant for years.

Collaborative documents: whatever the group uses. These are shared artefacts rather than your archive, and their lifespan is the project's.

The mistake is applying one answer to all three, in either direction.

The habit that makes it work

Sync a folder, do not sync an app. Whatever the file-syncing mechanism, the archive is the folder and the tool is incidental.

Keep filenames meaningful, because in a plain-text archive the filename is the primary index. A title stating a claim does double duty here.

One note per file. Grep, scripts and every future tool assume it.

And test the escape route annually. Open a file in a plain editor. Check the links still make sense as text. If your setup has quietly introduced a proprietary syntax that only one application renders, you have a database with a text-file extension.

What it does not solve

The thing worth saying, because format choice attracts more attention than it deserves.

Plain text is a preservation decision, not a practice. It ensures your notes will still be readable in fifteen years. It does nothing about whether you will read them — which is the actual problem, and no format has ever addressed it.

An archive of perfectly portable Markdown you never open is exactly as useful as a proprietary one you never open. Longevity is worth having and it is the smaller half of the question.

The short version