GTD vs PARA gets framed as a contest, and it mostly isn't one. Getting Things Done decides what you do next. PARA decides where a file goes. Run either without the other and you feel the gap almost immediately — a GTD system with nowhere for the PDF, or a PARA vault that is beautifully organised and tells you nothing about Tuesday.
There is one genuine disagreement between them, and it is worth naming early: where material that serves a project is allowed to live. Everything else in the comparison is vocabulary.
What each one is actually deciding
David Allen's method is a loop — capture, clarify, organize, reflect, engage — and every one of those verbs is about commitments. Its structural units exist to answer "what can I do right now, given where I am and how much time I have".
Tiago Forte's PARA is four top-level folders sitting side by side: Projects, described as short-term efforts you take on with a certain goal in mind; Areas, the parts of work and life that require ongoing attention; Resources, topics you are interested in; and Archives, anything from the other three that is no longer active. It sorts information by how close it is to something you are actually doing, and it is deliberately silent about what to do next.
Note the structure, because it trips people up. In PARA, projects and areas are siblings — four folders at the same level, each holding subfolders. That is a filing decision, and it is a different shape from the nesting most task apps use. The method itself gets a fuller treatment in the PARA method.
The mapping, and where it breaks
Most of the two systems translate cleanly. The table below is the translation, with the last column doing the real work.
| the job | GTD's answer | PARA's answer | what actually differs |
|---|---|---|---|
| unprocessed stuff | the in-tray | an inbox folder | nothing meaningful |
| a multi-step commitment | a project | a project | GTD demands a next action on every one; PARA does not care |
| an ongoing responsibility | an area of focus, reviewed periodically | an area, a top-level folder | GTD's is a lens you review through; PARA's is a place files sit |
| material that serves a project | a reference file, kept out of the action lists | inside the project folder, or in resources | the real disagreement |
| wanted, but not now | the someday/maybe list | no equivalent | archives holds finished or dropped, not deferred wants |
| what to do next | the next actions list | nothing, by design | PARA declines the question |
| finished work | the logbook of completed items | the archive | GTD keeps evidence of doing; PARA keeps the material |
Two rows in that table carry the whole comparison. The someday row is a real hole: PARA's Archives covers anything no longer active, which is not the same thing as something you actively want in eighteen months. A dropped project and a deferred ambition end up in the same folder, which is why people running pure PARA usually reinvent a someday maybe list within a few months.
The material row is where the two systems genuinely pull in opposite directions. GTD, written when reference meant paper, sends supporting material to a filing system kept deliberately away from the action lists, so the lists stay scannable. PARA sends it into the project folder, on the grounds that the material and the work are the same effort. Both are coherent. They cannot both be implemented in one place unless your tool can hold a task and a document in the same container.
Where PARA wins outright
PARA is better than GTD at one thing that matters daily, and it should be said plainly: it gives every piece of information a home in under two seconds, using a rule you can apply without thinking.
The actionability test — is this tied to something I am doing now, something I maintain, something I am curious about, or something finished — resolves almost every filing decision instantly. GTD's reference category is a single bucket by comparison, and buckets need search to be useful. PARA also survives a tool change better, because four folders port to any app that has folders, while a GTD setup is usually entangled with the specific features of the app it was built in.
It is also easier to teach. Most people can run PARA correctly after one reading. GTD takes a few weeks and a couple of failed weekly reviews before it clicks.
Where GTD wins outright
GTD answers the question PARA refuses to. On a Tuesday at three, with forty minutes and a low battery, a PARA vault tells you what exists and a GTD list tells you what to start.
The mechanism is the physical next action, and it is a stricter discipline than it sounds. A PARA project folder can sit there perfectly organised with no indication that it has been stuck for six weeks; a GTD project with no next action is caught by the weekly review by design. That review is the second thing GTD has and PARA lacks — a scheduled reconciliation, described step by step in the GTD weekly review checklist.
Capture is the third. GTD is precise about the in-tray being unstructured and emptied on a schedule, and it specifies the processing pass down to the order of the questions. PARA assumes things arrive already sorted, which is a fair assumption for a research note and a poor one for a thought you had in a lift.
Running both without running two systems
The usual setup is GTD in a task app and PARA in a notes app, and it works until the moment you need both halves of the same project. Then you are reconciling by hand: the tasks in one place, the quote PDF in another, the address in a message thread.
There are three ways out. Accept the split and pay a small tax at every context switch. Push tasks into the notes app, which most of them handle poorly. Or use something that holds both, which is what most second brain apps are trying to be, with varying success. Which apps carry which of the five GTD lists is covered in how to pick an app for GTD.
Where init.Tasks fits
init.Tasks puts to-dos, personal projects and a second brain behind one terminal-styled interface on iOS, macOS and web, borrowing PARA's vocabulary and GTD's discipline. Areas → projects → subprojects, with counts and progress rolling up so a stalled project is visible without opening it.
Everything arrives through one polymorphic inbox, so filing a link never means opening a second app — which is the reconciliation tax the section above is about. Start date and deadline stay separate fields, keeping the GTD half honest. Search reaches tasks and material alike, in one result list.
The AI connection is coming in september: connect an MCP client read-only and it can read across both halves at once, which is hard when your tasks and your notes live in different tools. It is in private beta: the waitlist is open, invites go out in september, and it is free while in beta.
FAQ
What is the difference between GTD and PARA?
GTD is a workflow for commitments: capture everything, clarify what each thing means, organise it into lists, review weekly, then act. PARA is an organising scheme for information: four top-level folders — Projects, Areas, Resources, Archives — sorted by how actionable the material is. GTD tells you what to do next. PARA tells you where something goes.
Can you use GTD and PARA together?
Yes, and most people who run either eventually do. The usual seam is that PARA's project and area folders hold the material while GTD's lists hold the commitments, with the same project names on both sides. The cost is reconciliation: two systems means two places to update when a project ends, unless one tool holds both.
Is PARA a replacement for GTD?
No. PARA deliberately does not answer what to work on next, has no weekly review, and no equivalent of a someday/maybe list — its Archives folder holds what is no longer active, which is a different idea from something you still want later. Replacing GTD with PARA usually means quietly reinventing next actions a few months in.
Which one should you learn first?
PARA, if your immediate pain is not finding things, because it takes an afternoon and pays off the same week. GTD, if your immediate pain is dropped commitments, because no amount of filing fixes a missed follow-up. Learning both at once is the common mistake — two new systems in the same week means neither gets a fair trial.