One Note Per File, or One Big File? It's Your Call

The honest answer is that neither wins. One big text file makes synchronisation, backup, and zero-friction capture trivial; one note per file gives you focus, clean per-file conversion, and localized edits. The right granularity depends on how you work — and because both are just plain text files you own, you can switch later.

This is a decision people agonize over and almost nobody explains neutrally. The two camps each have a real founder and a real history. "One big text file" (OBTF) traces to an observation by technology journalist Danny O'Brien at the 2004 O'Reilly Emerging Technology Conference: he noticed many of the most productive technologists worked from "one single large text file."¹²

The opposite instinct — one note per idea — is older still. The framework below treats both as legitimate. This is a decision guide, not a verdict.

What does "note granularity" actually mean?

Note granularity is the size of the unit you save: everything in one running text file, or one file per note, project, or task. It is a file-organization decision, not a method like Zettelkasten or a tool like Obsidian. The same Markdown content can live either way, and the same person can split or merge it whenever their work changes.

Keep two things separate. The first is how much goes in a file — the granularity axis this post is about. The second is how many notes you keep overall, which is a different argument about consolidation. A person can run one giant file and still write very few notes, or keep hundreds of tiny files and hoard everything. Granularity is about the container, not the count.

This post is also distinct from our essay on coming back to one text file for to-do management, which is a personal workflow arc about tasks — why one writer abandoned every to-do app and returned to a flat file. That piece argues for the flat file in one narrow domain. This one stays neutral across all your notes and hands you the decision.

The case for one big text file

One big text file wins on operational simplicity. With a single file, syncing across devices, verifying the sync worked, and backing up all collapse into one tiny operation. Scott Nesbitt of The Plain Text Project ran this setup for three years and found backups and cross-device syncing "much simpler when there is only one file to worry about."³

William Hern, whose 2006 essay popularized the practice after O'Brien's observation, is precise about why. "With just one file to worry about, synchronisation across multiple systems is very easy."¹ Verification is just as cheap: "With only one file to check for, it's very quick to verify that the synchronisation is working as it should."¹

And backup follows the same logic. "The use of a single file makes data back-up much easier as well."¹ One file, one thing to move, one thing to confirm.

The second advantage is capture with zero friction. There is no decision about where a thought goes — it goes in the file. Ellane W, who revived the practice in 2025, frames it as the whole point.

"If you want to write something down and it doesn't have a home yet (or isn't ready for prime time), put it at the beginning or end of a single text file along with the date and time it was added."⁴ No folder, no filename, no taxonomy. You just write.

The case for one note per file

One note per file wins on focus and clean boundaries. When each note or project is its own file, you work on one thing without the rest of your thinking in view. Nesbitt, who later moved to smaller files, accepts "more files and folders for me to manage" for the payoff of focusing "on one task or project at a time."³

The second advantage is conversion at the unit level. A single note can be exported, shared, or transformed without dragging everything else along. Nesbitt is direct about the asymmetry: "it's easier to convert individual files (or multiple files) to another format than it is to extract a portion of a larger file and convert it."³

If you ever need just the meeting notes as a PDF, a per-file setup hands them over. A big file makes you find and carve them out first.

There is a third, quieter advantage: edits stay local. In a many-files setup, a change touches one small file, so two devices editing different notes rarely collide. A practitioner on the Zettelkasten forum named the upside of small units while drafting longer work — "I am very happy to have the more granular file-length to assist me to focus on a tiny part of the text."⁵ Smaller containers mean smaller blast radius.

A side-by-side tradeoff

Here is the whole decision on one screen, axis by axis. This compares the two workflows — not any product — because both are achievable with nothing more than plain Markdown files and a search box. Read down the column that matches how you actually work, and notice that every strength on one side is a cost on the other.

No row crowns a winner. Each strength on the left is a cost on the right, and which side of each row matters is a fact about your work, not about the file format.

How to decide: a short framework

Pick by matching the workflow to the three things granularity actually changes — capture, navigation, and how units leave the system. Most people do not need to choose globally. The strongest practical answer is a hybrid: a single running file for capture, promoted into individual files once a thought has a home.

The diagram below summarizes the decision you just read in prose. It is a summary anchor, not a substitute for the reasoning above.

flowchart TD
    A[How do you<br/>work most?] --> B{Capturing fast<br/>all day?}
    B -->|Yes| C[Lean one<br/>big file]
    B -->|No| D{Editing or sharing<br/>one unit at a time?}
    D -->|Yes| E[Lean one note<br/>per file]
    D -->|Not sure| H[Run a hybrid]
    C --> H
    E --> H
    H --> F[Capture in one<br/>running file]
    F --> G[Promote to its<br/>own file later]

Figure: A decision flow for note granularity. Start from how you work. If you capture fast all day, lean toward one big file. If you mostly edit or share one unit at a time, lean toward one note per file. When unsure, run a hybrid — capture into a single running file, then promote a thought into its own file once it has a home.

The five-minute version

1. Default to capture. Open one running file and append everything to the top or bottom with a date.⁴ No naming, no filing — just write.
2. Let things settle for a few days. Most of what you capture is disposable. Don't file what you'll never reread.
3. Promote what survives. When a captured note earns a real title, cut it into its own file. This is the move that gives you focus and clean conversion later.³
4. Keep dailies as the middle ground. A dated append-only daily log is the natural capture surface — one file per day, then promote.
5. Stop tuning. Pick the lean that fits this month's work and write. The setup is reversible; perfecting it is not the work.

The thirty-minute version

If you want a deliberate system rather than a default, set three rules and write them at the top of your capture file. First, a capture rule: everything new lands in the running file, newest at the top, with a timestamp. Second, a promotion rule: a note leaves the file once it has a stable title and you've referenced it twice.

Third, a structure rule for whichever side you lean. If you stay in one file, divide it into named sections. If you split into many, adopt a filename convention and an index note so the pile stays navigable.

Hern, who lived in one file for years, did exactly this. He reported that his file "divided into three sections: a top third that consisted of permanent notes on specific topics, a middle third made up of my day-to-day notes and a bottom third that consisted of my work in progress stuff."³ The structure was self-imposed. That is the whole job either way — the file format hands you no structure on its own, so you supply the order.

Common mistakes

The failures of note granularity are not about choosing the wrong side — they're about leaving the side you chose unmanaged. A big file with no internal order rots; a folder of files with no naming habit gets lost. These five mistakes account for nearly every "plain text didn't work for me" story, and each has a one-line fix.

• Treating the choice as permanent. It isn't. With find-and-replace across notes and full-text search, splitting a big file or merging a folder is an afternoon, not a migration.
• Going one-big-file with no internal structure. Without self-imposed order, a big file rots. Mark Koester warns that "Like a junk drawer or an unsorted inbox, things can get get [sic] pretty disorganized using plain text files."⁶ Nesbitt is blunter: "you need to be very careful about how you structure that file."³
• Going many-files with no naming or index habit. The opposite failure: you trade one wall of text for a heap of untitled files you can't find. A naming convention and an index note are not optional in this lean.
• Ignoring the friction costs of a giant file. They are real. A forum practitioner noted that "scrolling through massive walls of text to copy and past/move things around would be fatiguing,"⁵ and one file is a single sync-conflict surface — two devices editing it at once can collide where many small files would not.
• Picking sides on identity, not workflow. OBTF versus Zettelkasten is treated as a tribe online. It's a granularity tradeoff. Match the file size to how you capture and navigate, not to which camp you'd rather belong to.

Will it scale, and is it really reversible?

Yes on scale, mostly yes on reversibility — with one honest caveat. Big files hold up further than people fear: Hern's grew to "nearly forty-thousand lines and was well over a megabyte in size"¹ and his editor "was still able to handle it with ease."¹ The worry that you'll lose track is answered by search, not scrolling.

Hern's own habit makes the point: "I do most of my navigating via the incremental search capabilities built into all proper editors."¹ You navigate a large file the way you'd find anything across many files — you search.

Reversibility is the real payoff of plain text, and it is honest to state its limit. Merging many small files into one is trivial. Splitting one large file into many takes a little more work, because, as Nesbitt notes, "it's easier to convert individual files (or multiple files) to another format than it is to extract a portion of a larger file."³

So the choice is reversible with the tools you already have — search and find-and-replace — but not perfectly symmetric. Lean toward fine-grained if you're unsure, since merging is the cheaper direction.

The deeper reason any of this is reversible is ownership. When notes are plain Markdown files stored on your own device, no app dictates the unit, and no export step stands between you and a different layout. As Obsidian's Steph Ango puts it, "Apps are ephemeral, but your files have a chance to last."⁷ The granularity decision is yours precisely because the files are yours.

Frequently Asked Questions

The questions people ask about file granularity almost always reduce to one fear — that the choice is permanent and that picking wrong means a painful migration later. It isn't, and it doesn't. These answers cover the recurring objections, with the same neutral stance the framework takes: match the file size to your workflow, then change it whenever your work changes.

One big text file vs one note per file — which is better?

Neither is universally better. One file wins on sync, backup, and frictionless capture;¹³⁴ many files win on focus and clean per-unit conversion.³ Match the granularity to how you capture and navigate. Because both are plain text, you can change your mind later without an export.

What are the pros and cons of one big text file?

Pros: trivial sync and backup, instant search, and zero-friction capture — you append and move on.¹³⁴ Cons: it needs self-imposed structure or it drifts into a "junk drawer,"⁶ scrolling a huge file to move things can be fatiguing,⁵ and one file is a single sync-conflict surface.

How granular should my notes be?

A practical default is one file per project or task, exactly the middle ground Nesbitt landed on: "use one file per project or task."³ Capture loosely into a single running file, then promote a thought into its own file once it has a stable title and you've referenced it more than once.

Won't I lose track of things in one giant file?

Less than you'd expect. Hern names the worry directly — "with so much stuff in one file, doesn't it make it difficult to find anything?" — and answers that "it works better than you'd think,"¹ because you navigate by incremental search rather than scrolling.¹ The same search habit finds notes across many files too.

Is Zettelkasten better than one big text file?

It's not better or worse — it's a different granularity. Zettelkasten is a many-small-notes method; OBTF is one large file. They optimize for different things (atomic linking versus capture simplicity), so the question is which tradeoff fits your work, not which method is superior.

Can I split one big file into many files later?

Yes. With full-text search and find-and-replace you can break a large file into per-note files, or merge a folder back into one. Merging is the easier direction; splitting takes a little more work, since extracting a section is harder than converting a standalone file.³ Either way, plain files keep the door open.

This decision was never as heavy as the camps make it sound. One file or many is a question about how you capture and move your thinking, and the moment your notes are plain files you own, it stays a question you can answer again tomorrow.

This framework builds on Danny O'Brien's original observation and the practitioners — William Hern, Scott Nesbitt, and Ellane W — who refined it into a working method.¹²³⁴

If you'd rather keep that choice in your own hands, mnmnote.com keeps your notes as plain Markdown files on your own device, so you can split or merge them whenever your work changes.