Your Word Count Lives in a Dashboard You Don't Own. Count It From Your Own Files Instead.

A writing stat is a property of your text, not your app. The word count, the words-per-day trend, the streak — all of it can be computed straight from the plain-text files you own, with tools no vendor can deprecate. The number that lives in a dashboard dies with the dashboard. The number you compute yourself survives every app switch.

Picture the test that matters. The note app you tracked your streak in raises its price, breaks a plugin, or shuts down. Your dashboard goes dark. Where did your writing history go? If the answer is "into the company's database," it is gone. If the answer is "it was always just a count of words in my own files," then nothing happened to it at all — you recompute it in a second.

This is a how-to, not a manifesto. By the end you will have one command that counts every word across a folder, two ways to rebuild a daily history, a method for reconstructing a streak yourself, and an honest account of what these tools do and do not do.

The reason this works is older than any note app. The tool that counts your words has been standardized since the 1980s and shipped with the first Unix in the 1970s — a count of words is not a feature an app grants you. It is a measurement anyone can take of text they hold.

How do I track my writing word count without relying on an app's dashboard?

Count straight from the files. wc -w *.md returns the words in every Markdown file in a folder plus a running total, in one command. For a daily history, diff dated files or read a git commit log. For a streak, mark the days a file changed. None of it needs the app you wrote in.

That single answer carries the whole post. The rest explains each step, because a method you understand is one you will trust when the dashboard you used to trust goes dark.

The thesis is small and durable: a stat is a property of your text, not your editor. An in-app counter shows you a number. It does not own the number. The same number is sitting in your files, recomputable forever, by you, offline, with tools that predate every app on the market.

Why a count of words can't be deprecated

The number itself is defined by a public standard, not by any company. The Unix wc utility "was inherited into the first version of POSIX.1 and the Single Unix Specification"¹ and "appeared in Version 1 Unix."¹ The way your words are counted has been specified, in the open, for over forty years — no vendor can change it under you.

The standard is explicit about what it does. POSIX defines it precisely: "The wc utility shall read one or more input files and, by default, write the number of <newline> characters, words, and bytes contained in each input file to the standard output."² A count is a reading of the file. It is not stored inside an app and handed back to you on a subscription.

The GNU implementation everyone actually runs says the same thing in plain words. The GNU Coreutils manual: "wc counts the number of bytes, characters, words, and newlines in each given file, or standard input if none are given or for a file of '-'."³ Each given file — the count belongs to the file you point it at, wherever that file lives.

This is the whole argument compressed. Steph Ango, the CEO of Obsidian, named the principle behind it: "Apps are ephemeral, but your files have a chance to last."⁴ A statistic computed from a lasting file lasts with it. A statistic locked in an ephemeral dashboard is ephemeral too.

The five-minute version: count words across a whole folder

Here is the entire method for a folder of notes, and it is one line. The GNU manual describes the behavior you rely on: "wc prints one line of counts for each file," and "if more than one file is given, wc prints a final line containing the cumulative counts."³ Per-file and total, in a single pass.

For a flat folder of Markdown notes:

# Words in every .md file here, plus a cumulative total line
wc -w *.md

# Just the grand total for the folder
cat *.md | wc -w

For an entire vault with subfolders, the practitioner Simon Späti documents the one-liner that walks the tree and counts everything at once:⁵

# Every .md file under ./notes, recursively, skipping dotfolders, one total
find notes -type f -not -path '*/.*' -name '*.md' -exec cat {} \; | wc -w

Run it, and you have your manuscript's current size — no app, no account, no dashboard. The same line works on a folder synced from any editor, because the editor never owned the count to begin with.

The thirty-minute version: rebuild a words-per-day history

A daily history is a sequence of counts over time, and you can reconstruct it two ways from files you already keep. The first uses dated files; the second uses version history. Both rebuild the same trend line a vendor dashboard would have shown you — except this one is yours, and it survives the app that drew it.

From dated daily files. If each day's writing lives in its own dated file — the append-only daily-log pattern — then a day's output is just the word count of that day's file. Loop wc -w over the folder, sort by the date in each filename, and you have a words-per-day series. This is why a dated filename is worth the effort: it is the index that makes per-day stats trivial.

From git history. If your notes live in a git repository, the commit log already records every change, so you can read net words added per day from it. The writer Gijs van Dam built exactly this. To motivate himself, he "decided to measure my progress by counting the net change in words I achieve throughout each day."⁶ His framing is the point: "it is a reality check to see how fast my work is progressing."⁶

Either way, the history is a function of your files, not a record trapped in someone's product. Switch apps tomorrow and you recompute the same series from the same files.

How do I rebuild a writing streak without the app's tracker?

A streak is the set of days a file changed, marked on a calendar — and that set is recoverable from your files. From dated daily notes, every date with a non-empty file is a day you wrote. From git, every commit that added words counts. Mark those days on a grid and you have the contribution-graph view, rebuilt yourself.

This is not theoretical. The community plugin obsidian-daily-stats lets you "view your daily word count across all notes in your Obsidian.md vault" and shows "the historical logs in a right panel view akin to Github's contribution graph"⁷ — 112 stars' worth of writers who want exactly this.⁷ The plugin proves the point: the streak it renders is computed from the same vault files you hold. The view comes and goes with the plugin; the days-you-wrote do not.

So the durable move is to treat the dashboard as a renderer, not a vault. Let any app draw the pretty graph. Keep the dated files (or the commits) that the graph is drawn from. When the app is gone, the graph is one short script away from coming back.

Common mistakes

These are the four ways the method goes wrong, and how to keep each one honest. None of them break the thesis — they bound it. A stat you own is only as good as the file habit underneath it, so name the limits before they surprise you.

• Treating "own your history" as "apps are bad." A live in-app word counter is genuinely convenient — instant feedback while you write is a real feature, not a trap. The claim is narrow: your history should not live only in one vendor's dashboard. Use the counter; just keep the files the count comes from.
• Trusting wc -w as a publisher-grade count. wc -w counts whitespace-delimited tokens, so Markdown markup — # headings, link syntax, code fences — gets counted too. It is accurate enough to track a trend (the same overcount applies every day, so the day-to-day delta is honest), not to report a final manuscript length to an editor.
• Building a git streak without committing. A git-history history is only as good as your commit habit. Van Dam says it plainly: "if you don't commit regularly (at least daily) this word count doesn't come up with accurate data."⁶ No commit, no data point — the streak has a hole where the discipline lapsed.
• Letting the date live only in the filesystem. A dated-filename history needs the date in the filename (or in the text), not just in the file's modified-time. Copies, syncs, and restores routinely rewrite filesystem timestamps, silently flattening your history. Put the date where it cannot be clobbered: in the name.

A note on daily targets

If you track output against a goal, the most widely searched one is the novel-draft challenge: writers aim to produce "a 50,000-word novel draft by the end of the month, aiming for an average of 1,667 words each day."⁸ The methods above turn that target into a number you compute against your own folder.

The point is not the specific figure. It is that any goal you set is measurable from the files in front of you, with nothing standing between you and the count.

Frequently asked questions

How do I count words in all my Markdown files across a vault?

For a flat folder, wc -w *.md lists every file plus a total. For a vault with subfolders, walk the tree and pipe it through wc: find notes -type f -not -path '*/.*' -name '*.md' -exec cat {} \; | wc -w.⁵ Both read straight from your files and need no app or account.

How do I track daily word count or words per day?

Two ways, both from files you keep. Diff dated daily files — each day's count is wc -w on that day's file. Or read net words added per day from your git commit log, as Gijs van Dam documents.⁶ The git method needs regular commits to stay accurate.⁶

How do I make a writing streak or heatmap like GitHub's contribution graph?

Mark every day a file changed on a calendar grid. The obsidian-daily-stats plugin renders this "akin to Github's contribution graph,"⁷ but the underlying graph is rebuildable from your own dated files or commit history — so it survives the plugin.

Will I lose my writing stats if I switch note apps or my subscription lapses?

Not if the stat is computed from files you own. A count, a trend, and a streak are all functions of your text; recompute them anywhere. They are lost only when they live solely in a vendor's dashboard — which is the case Ango warns about: "Apps are ephemeral, but your files have a chance to last."⁴

Is wc accurate for counting words in Markdown?

wc -w counts whitespace-delimited tokens, so Markdown markup (#, links, code fences) is counted too. It is accurate enough for tracking a trend — the overcount is consistent day to day — but not a polished, publisher-grade manuscript count.

How many words should I write per day?

A common target is roughly 1,667 words a day, the pace that reaches a 50,000-word draft in 30 days.⁸ Treat it as a yardstick, not a rule — and measure it against your own files, not an app's tracker.

A statistic you can recompute is a statistic you can keep. Let the app draw the graph; hold the files the graph is drawn from. The same ownership principle is why it is worth knowing how to get your text out of any app before you need to — a stat survives an app switch only because the files do.

A note kept as plain text on your own device — open Markdown, stored locally, readable with or without any particular app — is the shape mnmnote.com is built around.