In HTML, there are currently two types of "checkbox" style controls:

  • Checkbox: Allows toggling on/off, multiple values can be selected
  • Radio: Only one value in a group may be selected, does not allow toggling off individual inputs

If anything is unclear, see this demo.

My beef is with radios, and the inability to "uncheck" them (which is the default behaviour in all browsers as far as I know). We just had an issue when one of our clients insisted that we get rid of the "Not Applicable" radio option on a form, but the field is not required.

Here's the problem: If someone selects a radio option, perhaps by misclick, there's no way out unless a "blank" option is provided (wording irrelevant). Very much like a dropdown box that does not have a blank option, but the difference is that a dropdown box doesn't take up more room in the UI whether it has 2 options or 20. Having the selectable values already present on the screen, without the extra click that the dropdown needs, is great - so we use radios all the time.

I cannot comprehend why the radio type inputs cannot be toggled off by clicking the input, and why this behavior is the default. Clicking a different option is the only way to deselect the current one, but it's very likely that none of the options are required or applicable, so once a value is selected - a selection is "locked in", regardless of which one it is.

My Questions

  1. Surely this behaviour is deliberate and took a room full of experts to agree upon, but what could those reasons possibly be?

  2. I'm thinking of going against the grain and writing some JavaScript to change this behaviour, by default, for all future applications that I write. Is there any reason why I shouldn't?

  3. Do non-techie users even have an expectation of how radios work?

  4. Is it likely that people are trying to deselect radio options by clicking them again, expecting a toggle, and getting frustrated?


Look at this mockup

How could this be changed to appear the same way with all options visible, using checkbox style controls and not require an empty radio that itself will require a label like N/A or I don't want to fill in this field?

If someone clicks the wrong option by accident, they're locked into selecting one of the options.

  • 4
    It's the default behaviour in desktop applications too. Once you have selected one option (all of them can start deselected) you can't return to that state.
    – ChrisF
    Commented Nov 3, 2011 at 21:52
  • 2
    jsfiddle.net/f4vXj/2 from stackoverflow.com/questions/2117538/… I don't recommend this though, I've never heard of anyone try to "uncheck" a radio button. But if that's what your client wants, then give it to them. They will be the only ones that knows how it works though.
    – Matt
    Commented Nov 4, 2011 at 7:13
  • 12
    @Jon: Your suggestion to use checkboxes but restrict to one selection... doesn't that break expected behavior for checkboxes? I know it would trip me up. Why would you hack checkbox to save radio? If no one expects clicking a radio to deselect it, and won't generally try to re-click it, then what expectation is actually being broken? All I can see is benefit.
    – user4487
    Commented Nov 4, 2011 at 15:27
  • 6
    @WesleyMurch: In the case of UX, "because it's always been that way" is a valid answer. All else being equal, change is bad for UX. I do prefer checkboxes over radio buttons for "select 0 or 1 choice" because a confused user won't get stuck. Compare, "I have no idea how to deselect the radio buttons" to, "I have no idea how to select more than one checkbox." The latter is preferable; the user is trying to do something illegal. That being said, I agree with the majority that just adding another option is preferable.
    – Brian
    Commented Aug 13, 2012 at 16:47
  • 5
    People keep talking about 'mandatory'. I want exclusiveness, but in my case I don't want 'mandatory'. 'Mandatory' should be a separate property that I can set on different things. For instance "please select at least one checkbox" is normal to see. So I come down on the side of thinking the default behavior is bad, and wanting to fix it with JS. Commented Jan 13, 2016 at 23:25

18 Answers 18


You're not supposed to leave radio buttons blank. They're allowed to be blank so you can avoid setting defaults as mentioned in the question about setting a default gender. You can't not pick a gender, it's a required field, though you can leave a "prefer not to say" etc. option; this is different than the user never touching the radio button, however. If the field is required, not setting a default allows extremely useful behavior; You force the user to fill in the field and you don't assume a default.

Say it's an extremely important yes/no question; the user is legally responsible for this yes/no question. You can't pick a default setting for the user in this case! But still, this option can't be left blank, they have to commit to one or the other. How is this helpful? You catch this in validation (preferably in page). This lets you make sure the user has filled in the field, rather than assuming the default, which can be very important.

As for your extra question: Anyone that's used a web form (or many OS forms) is familiar with how radio buttons work since they're so common. The first time they see a radio button they might click it again to try and untick it, but they'll quickly learn. And more importantly, radio buttons function like many physical buttons in real life — originally named after buttons on radios that shared the same functionality.

You press in a button, it goes click, and it stays depressed in a state where the user can no longer press it again. Other buttons on the same control press out other buttons. Old cassette tape players used these; pressing fast-forward or play popped out the "Stop" button because both functions can't happen at the same time.

Users that have used buttons know you can't "unpush" a button. The difference with radio buttons is that some buttons push out other buttons.

  • 20
    Well, you can usually deselect those real-life radio buttons by pushing them in halfway, but that's besides the point and probably a defect. The wikipedia article outlines the way radios work, but does little to validate the behavior or explain its reasoning. Why shouldn't a user be able to "unpush" a radio? It's the only way to force single-choice besides a dropdown.
    – user4487
    Commented Nov 3, 2011 at 20:29
  • 5
    @Wesley: short term it may seem like a win. Longer term it just adds confusion as users will unlearn the meaning of radio buttons - they won't check for unselected radio buttons in forms for example, and you as well need to find new alternatives to convey 'one option required' - and need to explain why some radio buttons can be unchecked and others can't. Just don't do it, it harms more than it creates benefit.
    – Inca
    Commented Nov 4, 2011 at 16:06
  • 19
    It is always good for user experience if user can undo his last action, which he can't if there was no default option selected. Behaviour of web radio buttons is just inherently flawed. People have got used to it, I guess but place a young child in front of set of web radio buttons to play with it and I bet it is going to try to unselect it at some point. Regrettably I can't make this an answer to the original question.
    – clime
    Commented Nov 16, 2013 at 16:56
  • 3
    @Inca: one option required: that should be left to validation, and not imposed by the input itself. Just feels better.
    – clime
    Commented Nov 16, 2013 at 17:09
  • 18
    @Inca: Ye and there is a standard way to let a user know that an input is required - star upon label. You can type something into a required text input and then delete it for whatever reason, right? You can unselect an option that you selected before for a required select. You can uncheck all checkboxes where at least one is required. Yet, at the moment you click on one of radio buttons (all empty before because no default set), you cannot undo it - at least one button will stay checked. Frustrating. Just thinking about it makes me sick. But yeah, we need to live with that glitch for now.
    – clime
    Commented Nov 19, 2013 at 0:59

Answer to your main question: This is legacy behavior left over from the desktop. This is how desktop applications did it for decades before the web came along. When form elements appeared in HTML, they just copied the behavior from the desktop. The original designers of the radio button probably couldn't have imagined how this control would be used over time and didn't anticipate this need.

What you're asking for is not uncommon: the standard solution is to have a choice which is basically "no choice".

Extra: I do think that if you hack radio buttons you will find lots of people will never try to "un click" a radio button. I wouldn't do this.

Extra credit: However, I have seen one other hack you might like: use checkboxes instead, but only allow the user to pick one checkbox. This is a control that users are familiar with unchecking and they often will get over the "huh I can only check one at a time" confusion.

  • 2
    Why hack checkboxes and not radios though? "The standard solution is to have a choice which is basically "no choice" - That's exactly what I am trying to avoid (also the client's request). For dropdowns it's OK, because it takes the same amount of room and doesn't need a label, whereas an "empty" radio does need one (just a radio with no label makes no sense and may go unnoticed, but a dropdown with a blank slot is pretty normal). So all-in-all it's more clutter.
    – user4487
    Commented Nov 3, 2011 at 20:16
  • 9
    I think the problem with hacking radios is that most people who already understand them won't think to try unchecking them. To Hagan's point, with checkboxes they will at least know to try that, even if you've thrown them off a little be enforcing that only one may be selected... Commented Nov 3, 2011 at 20:32
  • 3
    From a technical perspective, I'd rather use radios and fallback to radio behavior in case of a problem with the hack, to avoid multiple values being posted when only one is expected. So, what would you do if you were desperate to uncheck a radio? I would definitely try clicking it again, even if I know it won't work (while hoping it will).
    – user4487
    Commented Nov 3, 2011 at 21:17
  • 10
    No, no, please don't make checkboxes work like radio buttons! Commented Nov 4, 2011 at 13:51
  • 2
    As far as I remember since 2003, it was totally possible to leave radiobuttons without selection. Your "legacy" statement is wrong.
    – Nakilon
    Commented Nov 15, 2016 at 10:30

According to the W3C, the default behavior of radio elements with no default control set to checked is undefined.


Radio buttons are like checkboxes except that when several share the same control name, they are mutually exclusive: when one is switched "on", all others with the same name are switched "off". The INPUT element is used to create a radio button control. If no radio button in a set sharing the same control name is initially "on", user agent behavior for choosing which control is initially "on" is undefined. Note. Since existing implementations handle this case differently, the current specification differs from RFC 1866 ([RFC1866] section, which states:

At all times, exactly one of the radio buttons in a set is checked. If none of the elements of a set of radio buttons specifies `CHECKED', then the user agent must check the first radio button of the set initially.

Since user agent behavior differs, authors should ensure that in each set of radio buttons that one is initially "on".

While browsers currently agree on allowing radio controls to be unchecked by default, this is not considered to be the expected behavior.

  • I couldn't find equivalent language in the HTML5 standard. Commented Jul 19, 2017 at 15:12
  • 1
    "this isn't considered to be expected behaviour". Says who?
    – Florian F
    Commented Feb 21, 2020 at 11:16
  • 2
    HTML 5.2 standard states all inputs should be unchecked if none has been marked checked: If none of the radio buttons in a radio button group are checked when they are inserted into the document, then they will all be initially unchecked in the interface, until such time as one of them is checked (either by the user or by script).
    – Imre
    Commented Aug 6, 2020 at 14:10

As other have said, this is perfectly normal and expected behaviour.

I'm thinking of going against the grain and writing some javascript to change this behavior, by default, for all future applications that I write.

Really bad idea. You would be making buttons that most people understand work in a different way. If you need on/off functionality, use checkboxes, but changing the functionality of an existing type of control is going to cause you huge problems.

  • 1
    Checkboxes are not an option because they can't be used to force a single selection from many (at least natively). I understand this breaks some users' expected behavior, but I don't see why this particular idea is a bad one. Can you offer an example? How could this possibly trip someone up? Accidental double click? That's all I can think of.
    – user4487
    Commented Nov 3, 2011 at 22:27
  • 5
    Exactly. The worst solution to a problem is to invent a control which looks familiar* to the user but acts differently. Bruce Tognazzini has more on this in "Tog on Interface" (worth a read anyway.)
    – jensgram
    Commented Nov 4, 2011 at 7:20
  • 2
    @wesley: "they can't be used to force a single selection from many" but that's exactly what radio buttons are for. If you want them to be able to not 'select' one of the radios, what you do is add another option 'no thanks', or 'not applicable' or the like.
    – DA01
    Commented Nov 4, 2011 at 15:00
  • 1
    @DA01: Yep, that's what I usually do, and why I use radios for forcing single choice. Using native checkboxes for that is not the right choice. It just strikes me as odd that a radio group can start off all unchecked, but going back to that state is impossible.
    – user4487
    Commented Nov 4, 2011 at 15:12
  • 1
    @DA01: I am describing this: at most one option can be selected.
    – clime
    Commented Nov 19, 2013 at 3:33

Radio buttons are meant to be used in cases where you definitely need the user to select something, it is a way to force users to give you an input.

From what I've seen around the web, there are no cases of radio button hacks whereas there are examples of checkbox hacks where you will note that the system does not allow you to select multiple checks. From a user perspective, it would be easier to understand that only one option can be selected from a checkbox vs leaving a radio selection blank.

  • 1
    Note, HTML 5.2 standard does allow browsers to submit when no items are checked and none of them are required. Just playing devils advocate! But it does seem good practice to always set a default.
    – CrazyTim
    Commented Jan 15, 2021 at 1:07

The answer to this is really to try understanding why they are called "radio buttons".

In ancient times - well, before the world went digital at least - radios used to have a couple of preset channel buttons. Those were mechanical, and when you pressed one button, the previously pressed button would "pop up" and become deselected. The same arrangement were used on amplifiers as well, selecting the source device. In this application, it's even more obvious that having none selected is not really an option.

This behaviour carried over to the skeuomorphism of the software UI radio button.

I won't say if it's correct or not, just that the origin of the behaviour is hidden in its name.

  • 12
    But you COULD half-way push in the radio button to de-select the previously selected one! Why does everyone who quotes the history of the radio button forget this?
    – GHP
    Commented Apr 24, 2013 at 20:38
  • 3
    It's more of a mechanical bug than an actual feature. Using the original radio case, deselecting any channel like that would usually leave you with just static, so using the power button/switch was a more valid use case. Also, when you started turning the frequency knob to select a frequency manually, the selected preset channel wouldn't pop out - which would be a proper behaviour. Commented Apr 24, 2013 at 23:09
  • 2
    If my memory serves when you halfway pushed it, the selection wouldn't necessarily change, just the button state.
    – wastubbs
    Commented Jan 27, 2015 at 19:58
  • 2
    The behaviour when pushing halfway was somewhat erratic and could most definitely be considered a 'bug' due to the mechanical construction of different devices. On some devices, a halfway push would actually 'deselect' all channels with the result that only static came out of the speakers. Commented Feb 9, 2015 at 13:22
  • 1
    It is called "radio buttons" because of the behavior that when you push one in, the other one pops out. That's all.
    – Florian F
    Commented Feb 28, 2020 at 16:53

You can use a small subtle button (e.g. a small 'x') for each radio group. Pressing this button clears the radiobuttons in the associated group. This may give less clutter then having all these extra 'n/a' radiobuttons, plus you do not have to think about how to label these extra radiobuttons.


Totally agree with the OP on this one. The argument that 'you don't push a radio button to select between 2 options' is totally bogus.

Take a look at your computer or any other electrical equipment - you push a button to turn something ON and push the very same button to turn it OFF. Not allowing deselection of a radio button is NOT intuitive for end-users but exactly the opposite.

I have a case where we need to let users opt to show old data or only current data - they don't want 2 radio buttons because it's a binary operation (show/no-show). If they click then change their minds there's nothing to let them do that except a page refresh. Why shouldn't they be able to select/deselect the ONE option? There are countless use-cases for this functionality. You're STILL only submitting one (true/false) value so the logic is not broken.

  • 2
    I don't see how that particular analogy applies to radio buttons. The situation you describe ("you push a button to turn something ON and push the very same button to turn it OFF") is analogous to a checkbox which has an inherent true or false value.
    – Matt Obee
    Commented Apr 23, 2013 at 21:26
  • 1
    Hi @RadioButtonBad. Welcome to the UX Stack Exchange! I like your suggestion of the standard usage of a power button providing a potential affordance for how users would expect a radio button to work. Perhaps you could edit your post more directly to answer the OP's question though? He's already remarked on how it seems odd to him that radio buttons can't be deselected and is asking why they were designed this way. Commented Apr 23, 2013 at 21:49
  • If a control has the capacity where the user doesn't have to make a choice, then it shouldn't be a radio control. Case in point, older electric flick switches. They either can be pushed to an OFF position, or an ON position. But there's no middle ground. Neither can you change your mind about it and say 'I don't wanna make a choice'. The button will have a state. In your case, look at using a checkbox instead of a radio button.
    – Adnan Khan
    Commented Feb 4, 2020 at 2:05
  • 1
    Totally agree. For instance checkboxes have a variety with 3 states. "selected" "unselected" and "undefined". For radio buttons there are also use cases where "undefined" is a valid state. Unselecting a button would be the logical case.
    – Florian F
    Commented Feb 21, 2020 at 11:38

Radio button = mandatory single value field.

One has to be selected for submission. If you want a None option. make the first Radio 'None'.

Otherwise use checkboxes - which allow multi select

  • 2
    The typical online poll contains questions with multiple answers behind radio buttons. The initial state is almost always with no button selected. So the claim that a radio button implies a mandatory selection is questionable. And it doesn't reply to the question why it should be so.
    – Florian F
    Commented Feb 21, 2020 at 11:27

The real solution is to either use a combo/select with the none option plus all the other options or radios for all the options with the none option selected by default.

From Wikipedia:

A radio button or option button is a type of graphical user interface element that allows the user to choose only one of a predefined set of options.

So you must provide an option for NONE if you plan to offer an option for none otherwise use the combo.

  • 1
    That could be a solution although it could increase fill-out time for the form by a lot. Users cannot see all the options and when you have lots of these combo/select boxes it poses a readability/scanability problem. Commented Aug 14, 2012 at 9:22

Instead of downvoting others, I'd rather add my tiny voice to the opposite side.

Both behaviors are needed for performing different tasks. Unfortunately, I came across this question when needing to do the opposite of the default behavior. Now, if you ever think about accessibility, then if you try to alter the default behavior in JavaScript - well, you are out of the game.

Now, for all those who defend the "mandatory input" ideology: please look around yourself for the actual use cases. For example, okcupid.com (it's a dating site) has lots and lots of questions that would fit into radio-group control, unless it was so rigidly and unwisely designed to behave as some enterprise Java brain-dead manager designed it.

If there was a control that could provide n choices of m, where n <= m, then radio-group, as it is now, would be justified as a particular case of that more generic control, but, alas, there's not such control (checkboxes allow for variable number of choices, restricting the number of choices programmatically would, again, break the accessibility).

  • 1
    A radio button is meant to have only one option valid. Your example of an actual use case would be something OTHER than a radio button list. As you state, checkboxes could work--and could also be accessible. The use of JavaScript does not, itself, make something inaccessible.
    – DA01
    Commented Aug 13, 2012 at 17:45
  • 2
    "A radio button is meant to [...]" - who says that? Do you have "some other" browser control to offer? I'd sure use that instead. The use of JavaScript, in this particular case makes the functionality of deselecting all options by repeated selection of one already selected impossible.
    – wvxvw
    Commented Aug 13, 2012 at 18:46
  • 1
    To rephrase it: "a radio button is meant to have only one option valid" is a preposition that has no argument. You put it as a "fact of life", while this is no axiom or fact. It is an opinion. Be it your own opinion or opinion of W3C or anyone else - is of no consequence. Preposition is made true or false in a formal way, where opinions don't matter.
    – wvxvw
    Commented Aug 13, 2012 at 18:56
  • 1
    I have no idea what you are getting at. Radio buttons (both the physical ones that used to be on radios, and the ones now used in GUI interfaces) have always been defined as a set of options where only one can be selected. That is a fact. The 'argument' is prior usage and the precedent that the original physical device created.
    – DA01
    Commented Aug 13, 2012 at 18:58
  • 1
    Screen readers and automation testing tools that can't handle javascript are woefully antiquated given that we have standards such as ARIA now. Yes, I admit, some popular screen readers (such as the horrendous JAWS are antiquated). Also (as I previously stated) client side validation may be required depending on the level of accessibility requirements one seeks.
    – DA01
    Commented Aug 13, 2012 at 18:59

This may be subjective, but I really felt like this needed to be said. I think the standard way radio buttons work already are fantastic.

I'll explain why.

Let's think about the user for a second. What if the radio button is already selected on what the User needs in order to fill out their form? Would that not provide a wonderful User Experience?

Let's think about a possible user interaction scenario:

Providing one less click/touch, that the user may not have to deal with, will most definitely provide a better User Experience. Now granted,the overall user experience may have a lower chance of being that perfect " I don't have to change my selection " experience, but it is possible. Especially if setup that way.

Radio buttons already have an option selected when you first come into the page. Now again this is very subjective, but if the User Research is done well, it might just be possible to achieve that no touch/click goal with the radio button if the default is the majority of what people will select.

Pretty awesome stuff if you ask me. I agree with the others in sticking to the standard and familiar use of Radio buttons.

In the end, I think it really comes down to what your goals are for the project you're working on.

Here is a very simple example of what I mean by an option is already selected:



A purely UX solution might be to simply append the ubiquitous red asterisk (*) to the question, which most everyone understands to mean "required."

The main problem with the behavior of radio buttons seems to be that, on questions designed like the one shown at the jsfiddle link, the user doesn't know what to do if their answer is "none of the above." The first thought is to click a button again expecting it to be a toggle, which is a quite common capability in physical buttons.

Adding the "required" marker confirms that the user must pick one of the options (and probably leave a nasty comment, if possible, for not providing a "none of the above" type option.)


I think it is fairly confusing to have the clear functionality embedded in a radio item in the list e.g. "select none". Whenever I have seen this on the web I have never understood why that is the case. I don't believe it is intuitive.

I think "clear selection" functionality if needed should be a seperate button - almost a reset. This is especially important if it were for example a large number of items which scroll. The "Clear selection" button should be on the fixed area of the screen.


An example is how Chrome Web Store handles "Ratings" filter:

enter image description here

Once you select an option, you can't deselect it, but a "Clear" option appears on top.

Anyways, I believe radio buttons should have the ability to be deselected, just like the checkboxes do.


The thing here is, if you have (a group of) radio button(s), that means it is mandatory to select one of them (That's how radios are made to behave), they are all blank by default to avoid the user from not choosing one and going with the default. If your client wants a control that can not be chosen then you must be using check boxes, and no don't make them uncheck each other that's not how they are meant to work, if a user only wants to make one choice he must have the freedom and many choices too.

  • 1
    But why does it have to be mandatory? Isn't there any use case where an answer isn't mandatory? Isn't it disturbing to you that you start with an all-blank state and you cannot return to it? Would you forbid deleteing the content of a text input just because the input is mandatory? I don't think so.
    – Florian F
    Commented Feb 21, 2020 at 11:44
  • The main reason for having radio buttons is that they represent a mandatory choice, you can choose one or the other, the "empty state" as you say is just there to not bias the user towards an unintentional choice.
    – ThaSaleni
    Commented Feb 21, 2020 at 12:42
  • 1
    The main reason for having radio buttons is that they exclude multiple choices. An optional input is just as legitimate a use case as a mandatory input. I don't see why the claim that a radio button just cannot be an optional input.
    – Florian F
    Commented Feb 21, 2020 at 17:49
  • 1
    And I am asking: why should it be not intended to be optional? If I implement radio buttons and I make them optional, what terrible things will happen?
    – Florian F
    Commented Feb 24, 2020 at 13:21
  • 1
    I have implemented the checkbox behavious in radio buttons and no user ever complained. Do you have a different experience?
    – Florian F
    Commented Feb 28, 2020 at 16:31

I see two solutions:

  1. have a radio button "other" when none of the others apply. You should even provide an "other" for gender selection. A transexual may not feel "male" nor "female" and prefer another option. What you do with it is your choice. If you want to know the percentage males in a survey you might ignore the "other"s and just count males and females.

  2. Add a checkbox to the radio button group and gray out the entire group when the checkbox is unchecked. You could name the checkbox "select gender" for the above example, and process it as if a radio button "other" was selected when the checkbox is unchecked.

  • 1
    When I don't select genter M or F, I usually don't mean "other". I mean that I do not provide the information.
    – Florian F
    Commented Feb 28, 2020 at 16:40

First of all, minimal javascript is required to facilitate deselection for each radio in the document:

function toggleRadio(event)
    if(event.target.type === 'radio' && event.target.checked === true)
        setTimeout(()=>{ event.target.checked = false; },0);
document.addEventListener('mouseup', toggleRadio);


Case for Enabling Deselection of Radios

Radios are not necessarily required fields, but you can make them required.

When they're not required, the user can skip them.

If the user decides to skip a radio group after having already clicked one of the radios, then it makes sense to allow them to deselect it via an (intuitive) additional click (as the code above facilitates).

People that don't know you can deselect a radio, due to this code, won't encounter any new issues from this code being implemented.

However, someone desperately trying to figure out how to deselect a radio (instead of starting over on the entire form) will certainly try clicking the radio again as a means of accomplishing that (as it is logically the first thing that would come to mind for someone trying to figure it out).

If you don't think users ever want to deselect radios, then do a google search and see all the user-hacks dedicated to overcoming this very frustration (such as this article).

Just because something was initially designed a certain way, that doesn't mean we can't make it better going forward. If a radio is required, then add the required attribute and they'll still have to select one of the options before successfully submitting the form.

Enabling deselection adds flexibility, eliminates the need for user-hacks, and make the world a better place.

  • Hi Lonnie, ux.stackexchange does not deal with implementation details. Maybe you should expand a little more on the questions asked, such as why people designed radio-buttons that way or if people want to uncheck them.
    – Nash
    Commented Sep 10, 2021 at 7:57
  • 1
    @nash : It seems that you saw implementation details and stopped reading. Read on. Commented Sep 10, 2021 at 7:59