Introduction
GitHub Flavored Markdown supports task lists, but it does not turn task-list syntax into interactive checkboxes inside table cells. If you need a checkbox or tick mark in a GitHub Markdown table, the practical choices are Unicode symbols, GitHub emoji codes, or plain text labels.
What Works Reliably in GitHub Tables
The simplest option is to place a Unicode check or cross directly in the cell.
12| --- | --- |
3| Login flow | ✓ |
4| Billing export | ✗ | ``` |
5
6That renders clearly, keeps the table readable in raw Markdown, and does not depend on HTML support.
7
8If you want a more GitHub-native visual style, emoji shortcodes also work well:
9
10```markdown
1112| --- | --- |
13| Login flow | :white_check_mark: |
14| Billing export | :x: |
15| Audit log | :warning: | ``` |
16
17Emoji are useful when you want a fuller status vocabulary than just checked and unchecked.
18
19## What Does Not Work the Way People Expect
20
21Many people try to put task-list syntax inside a table cell, like this:
22
23```markdown
2425| --- | --- |
26| Login flow | - [x] |
27| Billing export | - [ ] | ``` |
28
29On GitHub, that is not rendered as a task list inside the table. It remains plain text because task-list parsing is intended for list items, not for table cells.
30
31Raw HTML is also not a dependable solution for this case. Even if you try to embed an HTML checkbox element, GitHub's sanitization and Markdown rendering rules are not designed to make a form control inside a table the canonical answer.
32
33So if the goal is a stable README or issue comment, prefer symbols and text over HTML hacks.
34
35## A Good Pattern for Status Tables
36
37In documentation, a status table usually benefits from explicit labels alongside the visual mark. That helps accessibility and makes the meaning obvious when fonts or clients render symbols differently.
38
39```markdown
4041| --- | --- |
42| Linux support | ✓ Done |
43| Windows support | ~ In progress |
44| Legacy API cleanup | ✗ Not started | ``` |
45
46This approach has two advantages:
47
48- screen readers and plain-text readers get a textual status
49- people do not have to guess what a symbol means in your project
50
51For public repositories, that clarity is often better than trying to imitate a literal checkbox.
52
53## When to Use a Real Task List Instead
54
55If you need actual task-list behavior, move the checklist outside the table and keep the table for summary data.
56
57```markdown
58## Release checklist
59
60- [x] API contract frozen
61- [ ] Documentation updated
62- [ ] Migration guide reviewed
Then, if needed, keep a separate table for owner, priority, or milestone information. GitHub renders that combination much more predictably than trying to force task-list semantics into a table cell.
Common Pitfalls
The most common mistake is expecting - [x] inside a table cell to become a real checkbox. On GitHub, it does not.
Another mistake is relying on raw HTML form controls in Markdown and assuming they will behave the same everywhere GitHub content is rendered. Even when HTML is accepted, the result is less consistent than a plain symbol.
Teams also sometimes use symbols with no legend. A check mark is obvious, but other glyphs may not be. If the table will live a long time, pair symbols with clear words.
Finally, avoid overdesigning the table. If all you need is yes or no, a Unicode ✓ and ✗ are usually the best answer.
Summary
GitHub tables do not render task-list syntax as live checkboxes.
Use Unicode symbols or emoji for reliable checkbox-like visuals.
Add plain text labels when clarity or accessibility matters.
Prefer real task lists outside tables when interactive checklist syntax is important.
Avoid depending on HTML checkbox elements for GitHub Markdown tables.
