Due Dates, Priorities, and Repeats in a Plain Text File

A due date in a plain text task file is just text: write due:2026-07-01 at the end of the line. A priority is (A) at the front. A project is +work, a context is @phone, and a weekly repeat is rec:1w. One task is one line, readable in any editor — no database, no app required to make sense of it.

That single line is the whole system. The todo.txt format spec opens with what it calls "the first and most important rule of todo.txt": "A single line in your todo.txt text file represents a single task."¹ Everything below — the priority, the date, the tags — decorates that one line without ever leaving plain text. The format dates to a script Gina Trapani first published on Lifehacker in 2006², and it has outlived a generation of task apps precisely because it never asks you to import or export anything.

This is the how. For the why I came back to a text file — the longer argument about apps that die and files that don't — see I Tried Every To-Do App and Came Back to One Text File. This post is its companion: the syntax cheat-sheet that makes a flat file behave like a scheduler.

The one-line cheat-sheet

Read a task left to right and you read the whole grammar. Priority first, then dates, then the description, then projects and contexts, then any key:value metadata. Nothing is positional magic — the order is a readable convention, and the line stays human-legible at every step.

(A) 2026-06-16 Draft the Q3 report +work @laptop due:2026-07-01 rec:1w

That line says: top priority (A), created 2026-06-16, the task is "Draft the Q3 report", it belongs to the +work project, you do it @laptop, it is due 2026-07-01, and it repeats weekly rec:1w. Strip any piece and the rest still parses. Add a piece and you have not changed file formats — you have typed more text. Below, each field, in the order the spec defines it.

Priority: an uppercase letter in parentheses

A priority is one uppercase letter wrapped in parentheses at the very start of the line, followed by a space. The spec is exact about it: "The priority is an uppercase character from A-Z enclosed in parentheses and followed by a space."³ The canonical example is the smallest possible task: (A) Call Mom.

(A) Call Mom
(B) Email the contractor about the quote
(C) Read the chapter on indexing

(A) is most important, (Z) least. In practice you want three or four bands, not twenty-six — a list where every task is (A) carries no information, and a list of (A) through (N) is a ranking exercise that costs more than it returns. Treat priority as a coarse triage signal, not a precise sort key. When a task is done, the convention is to drop the priority and prefix the line with a lowercase x and the completion date.

Due date: the spec's own key:value example

A due date uses the format's generic metadata syntax: key:value. The spec is explicit that this is the intended extension point: "Developers should use the format key:value to define additional metadata (e.g. due:2010-01-02 as a due date)."⁴ Due dates are not a bolt-on. They are the documented example of how the format grows.

(A) Submit tax documents due:2026-04-15
(B) Renew passport due:2026-09-30
Water the plants due:2026-06-18

The date format is ISO 8601 — YYYY-MM-DD — the same format the spec mandates for creation dates: "If the creation date exists, it should be in the format YYYY-MM-DD."⁵ That choice is what makes scheduling work in a flat file. ISO dates sort lexically: sort the file alphabetically and due:2026-04-15 lands before due:2026-09-30 because the strings sort in the same order as the calendar. No date parser required — your text editor's sort command is your deadline view.

Projects and contexts: +project and @context

Projects and contexts are inline tags that group tasks across the file without folders. The spec defines them by their single-character prefix: "A context is preceded by a single space and an at-sign (@). A project is preceded by a single space and a plus-sign (+)."⁶ A +project names the outcome; an @context names where or how you can do the task.

(A) Call Mom +Family +PeaceLoveAndHappiness @iphone @phone
(B) Outline the talk +Conference @laptop
(C) Buy printer ink +Conference @errands

The first line is the spec's own multi-tag example.⁶ Because the tags live in the text, filtering is grep. grep '+Conference' todo.txt returns every task for the talk regardless of priority or date; grep '@errands' todo.txt is your errand list the moment you are out of the house. You did not build a saved view. You searched a file.

Repeats: rec: is a convention, not the spec

Here is the honest line most cheat-sheets skip: recurring tasks are not part of the core todo.txt specification. The convention nearly everyone uses is the rec: tag (rec:1w weekly, rec:1m monthly), but it is a community standard layered on top of the format, not part of it.

SwiftoDo's own documentation says so in its headline: "Task recurrence patterns are not part of the todo.txt format spec!" The same page adds that "SwiftoDo supports them anyway, using the same standard other todo.txt apps use."⁷

(B) Pay rent due:2026-07-01 rec:1m
(C) Weekly review due:2026-06-19 rec:1w
Take out the bins due:2026-06-17 rec:1w

The spec backs this distinction up. As Martin Michlmayr wrote in LWN.net's reference walkthrough of the format: "The specification also defines the tag:value syntax but only mentions due (due dates) specifically."⁸ Recurrence rides on the same key:value mechanism the spec documents, but the format itself never names rec. Knowing the line between spec and convention is what keeps you honest about portability — due: will be understood by anything that claims todo.txt support; rec: is honored by a cluster of tools, not guaranteed by the format.

How rec: actually behaves across tools

A rec: tag does nothing until a tool acts on it. The convention is that when you complete a recurring task, the app creates a fresh copy with the date pushed forward by the interval. So rec:1w on a task completed today produces a new task due a week out.

The interval grammar is shared across the maintained todo.txt apps that implement it: SwiftoDo, topydo, and sleek all read the same rec: syntax over the same plain file.⁷

That interoperability is the point worth holding onto. The recurrence logic is not locked inside one vendor's database; it is a shared reading of a tag in a file you own. Switch from SwiftoDo to sleek and your rec:1m rent reminder still means "monthly". The trade you are accepting is that recurrence advances only when a tool processes the file — in a bare text editor with no todo.txt tooling, rec:1w is inert text. Useful, readable, but inert until something acts on it.

Common mistakes

Five patterns turn a clean todo.txt file into a mess. Each is easy to avoid once named.

• Treating rec: as if it were the spec. It is a community convention (SwiftoDo, topydo, sleek), not core todo.txt.⁷ Use it freely, but know that a tool with no recurrence support will leave the tag untouched.
• Over-using priorities. A through Z exists; you need maybe A through C. When every task is (A), priority stops meaning anything. Reserve it for genuine triage.
• Expecting push notifications. A text file will not buzz your phone. It has no scheduler, no alarm, no daemon. For hard deadlines, pair the file with a calendar (see the caveat below).
• Inconsistent date formats. Mixing 06/16/2026 with 2026-06-16 breaks lexical sorting and due: parsing. Use ISO YYYY-MM-DD everywhere — it is what the spec mandates for creation dates.⁵
• Inventing private tags. You can write energy:high and it is valid key:value metadata — but only your own scripts will read it. Stay close to the shared vocabulary (due:, rec:, t: for start dates) if you want other tools to understand your file.

The honest limit: plain text won't remind you

This is the trade, stated plainly: a plain text file holds your schedule but does not enforce it. No notification, no alarm, no nudge at 9 a.m. The file is a record, not a reminder service. Robert Talbert, who built a GTD system on plain text, names the cost directly: going with plain text "does mean forgoing some features you'd get in a GTD app."⁹

For anything with a real consequence — a flight, a tax deadline, a meeting — put it in a calendar too. The calendar is the alarm; the text file is the system of record you actually own.

Talbert's reason for accepting that trade is the same one that has kept the format alive for two decades: "Working with plain text files is the ultimate in simplicity and control and portability. It gives me options for how I want to work with my data, and those data are not married to anybody's app."¹⁰

Why a file, not a task database

The features a task app charges for — due dates, priorities, recurrence, projects, contexts — are, in todo.txt, just text conventions you can read with your eyes. There is no database underneath them.

The format spec puts it bluntly in its "Why plain text?" section: "There's no exporting and importing, no databases or tags or flags or stars or prioritizing or insert company name here-induced rules on what you can and can't do with it."¹¹

That is the structural difference. Todoist and TickTick store your due dates and repeats inside a proprietary database; the same scheduling information, in todo.txt, lives as readable text. Both approaches work — app-native scheduling buys you reminders and polish. The text file buys you ownership and zero lock-in.

As todo.txt's home page puts it, "you can work with your todo.txt file in every text editor ever made, regardless of operating system or vendor."¹² Or, in Blue Fox's words on the same idea, "your tasks truly belong to you and are not dependent on any third‑party service."¹³

The portability is not theoretical. "A text file can be read on any operating system, edited with any software and easily synchronised."¹⁴ The format's coverage is deliberately small — "The format supports priorities, creation and completion dates, projects and contexts. That's all you need to be productive."¹⁵ — and that smallness is the durability. There is nothing to break, nothing to migrate, nothing to lose when a vendor sunsets a product.

How this works in a Markdown note

You do not need a dedicated todo.txt app to use any of this. The syntax is plain text, so it lives just as happily inside a Markdown note. Keep a ## Tasks heading, write one task per line with the same fields, and you have a schedule inside the same file you write everything else in.

A tool like MNMNOTE keeps that file as plain Markdown on your own device, works offline in the browser, and never locks the text behind an account or a database. The scheduling is yours to read, sort, and search; the note is yours to keep. Pair it with a calendar for the deadlines that must buzz, and you have ownership where it matters and reminders where you need them.

Frequently Asked Questions

How do you write a due date in todo.txt?

Add due:YYYY-MM-DD at the end of the task line — for example, Submit report due:2026-07-01. Due dates use the format's generic key:value metadata syntax; the spec lists due: as its documented example.⁴ Because the date is ISO 8601, sorting the file alphabetically also sorts it by deadline.

Are recurring tasks part of the todo.txt spec?

No. Recurrence is a community convention, not part of the core format. The widely used tag is rec: (rec:1w weekly, rec:1m monthly), supported by apps like SwiftoDo, topydo, and sleek. SwiftoDo's documentation states it directly: "Task recurrence patterns are not part of the todo.txt format spec!"⁷

How do you manage tasks in a text file with deadlines?

Write one task per line with a due:YYYY-MM-DD tag, then sort or grep by date. ISO dates sort lexically, so an alphabetical sort doubles as a deadline view, and grep due:2026-06 todo.txt returns every task due that month — no app, no database, no saved filter required.

What does (A), (B), (C) mean in a todo.txt file?

They are priorities. A priority is an uppercase letter A–Z in parentheses at the start of the line, with (A) highest.³ In practice three or four bands are enough; using all twenty-six dilutes the signal. When you finish a task, drop the priority and prefix the line with x and the completion date.

What is the difference between +project and @context?

A +project names an outcome you are working toward; an @context names where or how you can act. The spec defines both by prefix — + for projects, @ for contexts.⁶ Both are searchable: grep '+work' lists a project, grep '@phone' lists everything you can do on your phone.

Can a plain text file send me reminders?

No. A plain text file has no scheduler and cannot push notifications — it is a record, not an alarm. For hard deadlines, pair the file with a calendar that does the reminding. The text file owns your tasks; the calendar owns the buzz. Talbert calls this "forgoing some features you'd get in a GTD app."⁹

Does todo.txt work in Markdown or any editor?

Yes. todo.txt is plain text, so it works in any editor on any operating system — its home page notes you can use it "in every text editor ever made, regardless of operating system or vendor."¹² You can keep the same syntax inside a Markdown note under a ## Tasks heading without changing anything.

A file you can read with your own eyes will still open the day every app that promised to organize it is gone.

For the longer argument about why a text file outlasts the apps that replace it, see I Tried Every To-Do App and Came Back to One Text File. To keep your tasks as plain text you actually own, mnmnote.com holds them as Markdown on your own device, offline, with no account.