Radio buttons support

[14113]

I can see a great integration with checkboxes. Thanks for that!
Is it possible to add new support for Radio buttons?

The main motivation is a different context. On checkboxes, we want to finish all of them: https://docs.github.com/en/issues/tracking-your-work-with-issues/about-task-lists 4 of 6 tasks.

For radio buttons, we want to select only one option from the list.
For example, we are using issues like this:

**Describe the bug**
Blah blah

**Environment (please complete the following information):**
- [ ] Localhost
- [x] Staging
- [ ] Production

**Plan (please complete the following information):**
- [ ] PRO
- [x] Express
- [ ] Enterprise

We will never finish all tasks and can see on the issue index every time message: 2 of 6 tasks.

It's just an idea. Can imagine the complexity and another requests like select box, etc.

[denelon]

Similar discussion in #4319.

[ross-spencer]

Other connected issues: https://github.com/orgs/community/discussions/5238
And: https://github.com/orgs/community/discussions/5197

[JamesGelok]

It'd be nice if the syntax for radio buttons was something as easy as using parenthesis ( ) instead of square brackets [ ]

Hypothetically, your example would only need to be modified to use parenthesis instead.

**Describe the bug**
Blah blah

**Environment (please complete the following information):**
- ( ) Localhost
- (x) Staging
- ( ) Production

**Plan (please complete the following information):**
- ( ) PRO
- (x) Express
- ( ) Enterprise

I'm not sure how they model it. Maybe this would be something like "two tasks of a task list" where selecting any one of those radio buttons marks the completion of the task.

Can imagine the complexity and another requests like select box, etc.

Same, it'd be nice to answer questions like

What happens when you nest a radio list below a task list?

**Describe the bug**
Blah blah

**Environment (please complete the following information):**
- [ ] 
  - ( ) Localhost
  - (x) Staging
  - ( ) Production

**Plan (please complete the following information):**
- [ ] 
  - ( ) PRO
  - (x) Express
  - ( ) Enterprise

Maybe this would be something like "two tasks of a task list" where selecting any one of those radio buttons marks the completion of the task

This might just be a more explicit version of the above.

---

Can also imagine the other way around etc. And things with deeper nesting etc

[rafapaulin]

Interesting that almost three year later, there is no news on this basic feature :(

[kristymoniz-kubra]

yea, we were really hoping to introduce radio buttons for options so that users creating PRs can select from. Surprised this feature is still unavailable.

[JE29A]

I think radio groups need to be able to name the group they are part of, so incorporating some sort of id would be useful. [radio_id[ ]].

- [favorite_color[ ]] Red
- [favorite_color[x]] Green
- [favorite_color[ ]] Blue
- [favorite_shape[x]] Star
- [favorite_shape[ ]] Circle
- [favorite_shape[ ]] Square

Downside: Looks a lot like a text link: [Click here](http://somewhere.else/)

[rafapaulin]

double square brackets looks good to me :)

[roke-julian-lockhart]

@JamesGelok, I have tentatively suggested this for CommonMark standardisation. ¹

Footnotes

1. talk.commonmark.org/t/1952/17 ↩

[logansease]

Ping! +1 Pretty pls consider :)

[Aierbote]

Another small feature related to this radio-button could be to mark an option as disable with this kind of syntax

- (/) = 🚫 
- (\) = 🚫 *Need to be sure the escape functinality doesn't kick in* 

[skyqrose]

In HTML, checked radio buttons can be disabled, too. So if GitHub made a syntax for disabling radio buttons, the syntax should probably also allow checked options to be disabled.

The current GitHub checkboxes don't support this syntax for disabled options (or being partially-checked. examples below). I think it would be enough for radio buttons to match the features that checkboxes have, which is just basic checked / unchecked states.

• unchecked
• checked
• [-] partial (doesn't work)
• [/] disabled (doesn't work)

[ShayokhShorfuddin]

Ping! Really hoping that we get checkbox support in 2025! 🙏

[udlose]

+1

[0xcaffeinated]

+1

[ShayokhShorfuddin]

+1. Let's make it happen.

[DIFSRIP]

+1

[ryangoree]

+1

[Keyurkariya]

+1

[bishiboosh]

Guys, please subscribe and/or add emoticons on the first message instead of sending unuseful comments.

[ryangoree]

[ShayokhShorfuddin]

Any development on this?

[marcellodesales]

Catching up with this once again, Dec 2nd, 2025... Wow, Github... listen to your customers...

[esafak]

It has been five years. It is safe to assume they are not interested in your money.

[Gruebes]

[dorianmariecom]

5 years

[colinemarie]

+1 🙏🏻 🤗

[N-Fannilla]

+1 Please! 🥲

[ShayokhShorfuddin]

Half of 2026 is gone, yet no development in this.

[esafak]

Stop holding your breath, it's not going to happen. The only way it would is if you can explain how it makes Github more "AI".

[znewt99]

What's the purpose of this?

I understand you want radio buttons for a single selection. But, most situations (where you list multiple options, but can only select one of the options) is for a form and that point you might as well just handwrite all the html you need to write the full form.

I guess I just don't understand when you will use radio buttons with markdown that will be turned into html.

I need an example to look at to understand.

[znewt99]

Why does Markdown need radio buttons?

Also, with radio buttons only one option can be selected, so what happens when somebody accidentally does something like this:

(x) Option 1
( ) Option 2
(x) Option 3

[ross-spencer]

I don't have any background as to why you are engaging with this issue if it doesn't hold any relevance for you Zach, but the issue could likely be worded better - part of the desire is (1) to remove the count from the UI when using a feature that looks like checkboxes and (2) the suggestion is to use radio buttons to enable selection of one option instead of all options in a form group.

I don't know how you want to design a feature like that, but if you don't enforce cardinality, you obviously just approach it knowing you can put crap in and get crap out, like most things, and you'll just have to interpret two selections over one for yourself.

Clearly, most people engaging with a repository are going to try to do so in good faith, and so it doesn't seem a big deal.

[znewt99]

you'll just have to interpret two selections over one for yourself

Do you mean GitHub or the user? Two selections is invalid HTML for radio buttons. The user will never have to interpret two selections because they can only see one selection. GitHub will have to choose which selection to show as the single selection.

If a user accidentally has two selections in the markdown for the issue they are writing, then the GitHub parser and renderer (either cmark-gfm or commonmarker; i think github uses commonmarker for issues and cmark-gfm for readmes) will have to decide how to interpret two selections and determine which one to show to the user when the user is viewing the issue in the rendered state.

[ross-spencer]

and determine which one to show to the user when the user is viewing the issue in the rendered state

It's an overcomplication that isn't needed.

[znewt99]

Can you elaborate?

Radio buttons only allow for one selection, so if someone accidentally selects two things in the markdown, the renderer will have to choose which one to show as selected. Simple solution could just be that first selection is shown as a selected in the rendered state, and the second selection is shown as not selected.

[znewt99]

Is this for Issue Templates and to making submitting an issue like filing out a form?

[sheikh-abuhurairah]

GitHub task lists are currently designed strictly around Markdown checkboxes (- [ ]) as independent boolean items, so there’s no native concept of mutual exclusion or “radio groups”.

What you’re describing would require a new semantic layer (e.g. grouped tasks with single-selection constraints), which would fundamentally change how task lists are interpreted, rendered, and stored across issues, PRs, and APIs.

A possible workaround today is using structured sections or labels instead of task logic, since task lists are intentionally meant for “completion tracking,” not state selection.

So this feels less like a missing feature and more like a deliberate limitation of task lists being boolean-only by design, to keep them consistent across GitHub’s issue/PR ecosystem.

[esafak]

Github already has its own variant of Markdown called GFM. This is just a request to extend it to support radios. An existing CommonMark proposal, all the way back from 2014, is to use ( ) instead of [ ].