GitHub
Markdown table
Drawing checkbox
Tick mark
Coding tutorial

How to draw checkbox or tick mark in GitHub Markdown table?

Master System Design with Codemia

Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.

GitHub Flavored Markdown does not render task list syntax (- [x]) inside table cells as interactive checkboxes. To display check marks or tick marks in a GitHub Markdown table, use Unicode symbols, emoji shortcodes, or plain text labels. These render consistently across GitHub Issues, Pull Requests, READMEs, and Wikis.

Unicode Symbols: The Simplest Approach

Place Unicode check and cross characters directly in table cells. No special syntax required.

markdown
1| Feature        | Supported |
2| -------------- | --------- |
3| Dark mode      ||
4| Export to PDF  ||
5| Offline mode   ||
6| Plugin system  ||

Here are the most useful Unicode symbols for status tables:

SymbolUnicodeNameUse Case
U+2705White Heavy Check MarkCompleted, supported, yes
U+274CCross MarkNot supported, no
U+2713Check MarkSimple check (monochrome)
U+2717Ballot XSimple cross (monochrome)
U+2611Ballot Box With CheckCheckbox-like appearance
U+2610Ballot BoxEmpty checkbox appearance
U+2B1CWhite Large SquareNeutral / not applicable

The colored emoji symbols (checkmark and cross mark) are the best choice for public documentation because they are visually distinct at any font size. The monochrome symbols (check mark and ballot x) are better when you want a minimal, text-like appearance.

GitHub Emoji Shortcodes

GitHub converts emoji shortcodes into rendered emoji. This approach does not require copying Unicode characters.

markdown
1| Milestone          | Status             |
2| ------------------ | ------------------ |
3| API design         | :white_check_mark: |
4| Database migration | :white_check_mark: |
5| Frontend build     | :warning:          |
6| Load testing       | :x:                |

Useful shortcodes for status tables:

ShortcodeRenders AsMeaning
:white_check_mark:Done / Yes
:heavy_check_mark:✔️Done (alternative style)
:x:No / Failed
:warning:⚠️Partial / At risk
:construction:🚧In progress
:question:Unknown / TBD
:rocket:🚀Shipped / Released

Emoji shortcodes are GitHub-specific. They do not render on other Markdown platforms (GitLab, Bitbucket, or standard Markdown renderers) unless those platforms also support the same shortcode syntax.

Why - [x] Does Not Work in Tables

GitHub's task list rendering is designed for list items, not for table cells. When you place - [x] inside a table cell, it is rendered as literal text, not as an interactive checkbox.

markdown
1| Task          | Status |
2| ------------- | ------ |
3| Write tests   | - [x]  |
4| Code review   | - [ ]  |

This renders as:

TaskStatus
Write tests- [x]
Code review- [ ]

The - [x] text appears as plain characters, not as a checkbox. There is no workaround for this within table syntax. If you need interactive checkboxes, use a task list outside the table.

HTML Checkboxes in Tables

You can embed HTML <input> elements in GitHub Markdown, but the results are limited:

markdown
1| Task         | Done                          |
2| ------------ | ----------------------------- |
3| Write tests  | <input type="checkbox" checked disabled /> |
4| Code review  | <input type="checkbox" disabled />         |

GitHub renders these as disabled (non-interactive) checkboxes. They look like checkboxes but cannot be toggled by clicking. This approach works but has drawbacks:

  • The checkboxes are always disabled (GitHub sanitizes the HTML and removes interactivity).
  • The raw Markdown is less readable than Unicode symbols.
  • Some Markdown renderers strip HTML entirely, leaving nothing in the cell.

For most use cases, Unicode symbols are more portable and easier to maintain.

Combining Symbols with Text Labels

For tables that will be read by many people over time, pair symbols with text labels. This improves accessibility and removes ambiguity.

markdown
1| Component       | Status           | Notes                       |
2| --------------- | ---------------- | --------------------------- |
3| User auth       | ✅ Complete       | Shipped v2.3                |
4| Payment gateway | ⚠️ In progress   | Blocked on vendor API       |
5| Admin dashboard | ❌ Not started    | Scheduled for Q3            |
6| Mobile app      | 🚧 In progress   | Beta testing                |

This pattern works well for:

  • Release checklists in README files
  • Feature comparison matrices
  • Sprint planning summaries in GitHub Issues
  • Compatibility tables in documentation

Feature Comparison Matrix Pattern

A common use case is comparing features across products or versions:

markdown
1| Feature           | Free | Pro | Enterprise |
2| ----------------- | ---- | --- | ---------- |
3| Single sign-on    ||||
4| API access        ||||
5| Custom domains    ||||
6| SLA guarantee     ||||
7| Priority support  ||||
8| Data export       ||||
9| Audit logs        ||||

This format is scannable and works well at any display width. Readers can quickly identify which tier includes a given feature.

Using Task Lists Alongside Tables

When you need interactive checkboxes for tracking and a table for structured data, use both. Place the task list outside the table:

markdown
1## Release Checklist
2
3- [x] API contract frozen
4- [x] Database migration tested
5- [ ] Documentation updated
6- [ ] Load test results reviewed
7- [ ] Stakeholder sign-off
8
9## Release Details
10
11| Item               | Owner   | Deadline   |
12| ------------------ | ------- | ---------- |
13| API contract       | Alice   | 2025-03-01 |
14| Database migration | Bob     | 2025-03-05 |
15| Documentation      | Charlie | 2025-03-08 |
16| Load testing       | Diana   | 2025-03-10 |

The task list provides interactive tracking (clickable checkboxes on GitHub Issues and PRs), while the table provides structured metadata. This separation is cleaner than trying to force checkbox behavior into table cells.

Cross-Platform Compatibility

If your Markdown will be rendered on platforms beyond GitHub, choose the most portable symbols:

Symbol TypeGitHubGitLabBitbucketStandard Markdown
Unicode symbols (checkmark, etc.)
GitHub emoji shortcodesPartial
HTML <input> checkboxesDisabled onlyVariesVaries
- [x] in table cellsPlain textPlain textPlain textPlain text

Unicode symbols are the only option that works everywhere. If portability matters, stick with and or their colored equivalents.

Common Pitfalls

  • Using - [x] inside table cells and expecting interactive checkboxes. GitHub renders this as literal text in tables.
  • Relying on GitHub emoji shortcodes in documentation that will be viewed on other platforms. Shortcodes like :white_check_mark: only work on GitHub and a few compatible platforms.
  • Using bare Unicode characters without a text label in accessibility-sensitive contexts. Screen readers may not announce the intended meaning of a checkmark symbol.
  • Embedding HTML form elements and expecting them to be interactive. GitHub disables all interactive HTML for security reasons.
  • Using symbols with inconsistent meanings across the same document. Pick a legend (e.g., checkmark = done, x = not started, warning = in progress) and stick to it throughout the file.
  • Forgetting that table alignment affects readability. Keep the status column narrow and left-aligned. Do not pad with extra spaces around symbols.

Summary

  • Use Unicode symbols (, , , ) for check marks and tick marks in GitHub Markdown tables. They are the most reliable and portable option.
  • Use GitHub emoji shortcodes (:white_check_mark:, :x:) for richer status vocabulary when the audience is on GitHub.
  • Do not use - [x] task list syntax inside table cells. It is not rendered as a checkbox.
  • Pair symbols with text labels for clarity and accessibility in long-lived documentation.
  • Use real task lists outside tables when you need interactive, clickable checkboxes.

Course illustration
Course illustration

All Rights Reserved.