Type - [ ] Do the thing into a Markdown file and you’ll get a checkbox almost everywhere — GitHub, GitLab, Notion, Obsidian, and most static site generators all recognize the syntax. What’s inconsistent is what happens next. On some platforms that checkbox is genuinely clickable, and clicking it edits the real content. On others it renders as a checkbox-shaped image that does absolutely nothing when you click it — it’s just a disabled <input> tag with no logic wired up behind it. Confusing the two is an easy mistake to make, especially if your only experience is with the one platform where it happens to work.

This guide covers where checkboxes are real, where they’re decoration, and the couple of places task lists silently break outright — plus a mention of our new Markdown Checklist Generator if you just want clean, correctly-nested checklist syntax without hand-typing brackets and indentation. If you’re looking for basic task list syntax itself rather than platform behavior, our complete guide to task lists and checkboxes covers that ground.

GitHub: Interactive in Issues and PRs, Static in Files

GitHub is the platform most people picture when they think of “clickable Markdown checkboxes,” and it’s also the platform with the split behavior that trips people up.

In issue bodies, pull request descriptions, and comments, a - [ ] checkbox renders as a real, clickable <input type="checkbox"> wired directly to the underlying issue/PR text. Click it (if you have write access, or you’re the author) and GitHub edits the stored Markdown body for you, flipping [ ] to [x] in place. This is genuinely interactive — the checkbox state and the raw text are the same source of truth, always in sync.

GitHub also does something useful with this automatically: any issue or PR containing a task list gets an “N of M tasks complete” progress count that shows up in the issue list, the sidebar, and anywhere that issue is referenced or linked from another issue. You don’t have to configure anything for this — it’s computed straight from the checkbox count in the body text.

In regular repository files — a README, a docs page, any .md file rendered on github.com’s file browser — the story is different. GitHub still renders the checkbox visually, but it’s a disabled input with no click handler behind it, because there’s no “body” concept to persistently update; it’s just a static file being rendered as HTML. You can look at a checked-off roadmap in a README and it looks exactly like an interactive one, but nothing happens if you click it. This is the single most common source of confusion in this whole topic — people assume README checkboxes work like issue checkboxes because they’re visually identical.

GitLab: The Same Split as GitHub

GitLab’s behavior mirrors GitHub closely enough that if you understand one, you understand the other. Task lists inside issue descriptions and merge request descriptions are interactive — click a checkbox and GitLab persists the change to the description text, and issue lists show a task-completion count the same way GitHub’s does.

Task lists rendered inside wiki pages and regular repository files (README, any Markdown file in the file browser) are static, same as GitHub — visually identical checkboxes, no click behavior. If you’re building internal documentation in a GitLab wiki and picturing an interactive checklist your team can tick off together, that’s not what you’ll get; you’d want an actual issue or a dedicated task-tracking feature instead.

Confluence: A Real Interactive Feature, But It’s Not the Markdown Syntax

Confluence has genuinely interactive, assignable task items — but they come from a distinct editor feature, not from typing GFM-style - [ ] syntax. In the Confluence editor, typing [] followed by a space (or using the Insert menu) creates an Action Item: a real interactive checkbox that can be assigned to a person, given a due date, and tracked in Confluence’s own Tasks report across the whole space. That’s a more capable feature than a plain Markdown checkbox in most other tools.

Where it gets inconsistent is pasting raw Markdown task list syntax into Confluence — through the /markdown slash-command panel we’ve covered before. Our own testing there found - [x] syntax converts unreliably: sometimes it becomes a real Action Item, sometimes it just renders as literal bracket text, depending on the Confluence version and editor mode. If checkbox interactivity matters, use Confluence’s native Action Item feature directly rather than relying on a Markdown paste to produce one.

Jira: Depends Entirely on Which Editor and Project Type

Jira wiki markup — the plain-text format used by Server, Data Center, and classic (non-next-gen) Cloud projects — has no checkbox syntax at all. Typing - [ ] Task into a wiki-markup field just renders as a literal bullet point followed by the literal characters [ ] Task; there’s nothing for the renderer to interpret, which is exactly what our own Markdown to Jira converter produces when it hits checkbox syntax, since there’s no Jira wiki-markup equivalent to convert it to.

The modern Jira Cloud rich-text editor (used in team-managed/next-gen projects) does have a real interactive Task list block, but you reach it through the editor’s Insert menu or its own autoformat shortcut, not by pasting GitHub-style Markdown. If your workflow involves generating Jira content programmatically, it’s worth checking which editor your specific project type actually uses before assuming checkbox syntax will do anything.

Notion: Converts to a Real Block, Not Rendered Markdown Text

Notion doesn’t really “render Markdown” the way a static site or a GitHub file does — when you type or paste - [ ] syntax, Notion converts it on the spot into one of its own native To-do blocks, which is a first-class, always-interactive, always-clickable element in Notion’s block-based document model. There’s no static/interactive split here the way there is on GitHub or GitLab, because by the time you see a checkbox in Notion, it’s no longer “Markdown” at all — it’s a Notion block that happens to have originated from Markdown syntax. We cover Notion’s broader import behavior, including where this conversion does and doesn’t kick in cleanly, in our Markdown for Notion guide.

Obsidian: Interactive and Writes Back to the File

Obsidian is the one place in this list where “interactive” means something slightly different and arguably more useful: clicking a checkbox in Reading view or Live Preview doesn’t just update some in-memory display state, it actually edits the .md file on disk, flipping [ ] to [x] in the raw text. Since Obsidian vaults are just folders of plain Markdown files, that checkbox click is a real file write, not an API call against a hosted document like GitHub’s. This makes Obsidian genuinely good for checklist-style notes you expect to interact with over time, and it’s part of why the Tasks community plugin is popular — it extends this native checkbox behavior with due dates, recurring tasks, and query-based task views across your whole vault.

Linear: Live Markdown-Shortcut Conversion

Linear’s issue description editor supports Markdown-style shortcuts as you type, and task list syntax is one of them — typing - [ ] converts it live into an interactive checklist item within the issue, similar in spirit to Notion’s live-conversion behavior. As with Notion, once it’s converted it’s a native editor element rather than literal text sitting in a Markdown file, so there isn’t a “static file” version of this to worry about the way there is with GitHub or GitLab.

Quick Reference

Platform Where checkboxes are interactive Where they’re static or unsupported
GitHub Issues, PRs, comments (with auto task-count tracking) Repository files (READMEs, docs) rendered on github.com
GitLab Issue descriptions, merge request descriptions Wiki pages, repository files
Confluence Native Action Items (typed via [] or Insert menu) Raw Markdown - [ ] pasted via the /markdown panel — inconsistent
Jira Cloud team-managed project rich-text editor’s Task list block Jira wiki markup (Server/Data Center/classic Cloud) — no checkbox syntax exists
Notion Always — converts to a native To-do block on entry N/A — it’s no longer Markdown once converted
Obsidian Reading view and Live Preview — writes back to the file N/A — same file either way
Linear Issue description editor, live Markdown-shortcut conversion N/A — converts on entry

The Automation Angle: GitHub’s Completion Tracking

Worth calling out on its own, since it’s easy to miss: GitHub computes checklist completion automatically, with zero configuration. Any issue or PR body with task list syntax gets a live “3 of 7 tasks complete” count wherever that issue is displayed — the issue list, the sidebar of a linked PR, search results. If you reference another issue as a checklist item (- [ ] #123), GitHub can track that as a linked sub-issue and roll its completion into the parent’s progress. This is genuinely useful for release checklists and multi-step feature tracking, and it’s specific to GitHub — GitLab shows a similar per-issue completion count, but the cross-issue linking behavior isn’t identical, so don’t assume feature parity if you’re moving a workflow between the two.

Where Task Lists Break Outright

Two failure modes show up regardless of platform, because they’re rooted in how Markdown parsers work rather than in any single renderer’s choices:

Task lists inside table cells don’t render as checkboxes. GFM table cells are parsed as inline content, and a task list is a block-level list construct — parsers don’t recognize block elements inside a table cell, so - [ ] typed into a pipe-table cell just shows up as literal text, brackets and all, on every platform we’ve tested. If you need a checklist-style status column in a table, use a plain character (✅/⬜, or a simple “Done”/”Pending” column) instead of task list syntax.

Nested checkbox indentation is stricter than it looks. GFM expects consistent indentation — typically two spaces — for a nested task item to be recognized as a child of the item above it. Get the indentation wrong (three spaces, a stray tab, inconsistent indentation between sibling items) and the parser either treats the “nested” item as a new top-level list item or, on some renderers, breaks the list into two separate lists entirely. On GitHub specifically, this also affects whether a nested item’s completion counts toward the parent’s tracked progress, so a subtly wrong indent isn’t just a cosmetic issue there.

Hand-typing nested checklists with correct, consistent indentation is exactly the kind of small-but-annoying formatting task worth offloading — our Markdown Checklist Generator builds the syntax (including nesting) for you, so the raw Markdown is correct before it ever reaches whichever platform you’re pasting it into.

And if you just want correctly-formatted checklist Markdown without hand-typing brackets and indentation, try the Markdown Checklist Generator.