Which Radio button in the group is checked?
Master System Design with Codemia
Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.
Introduction
To find which radio button in a group is checked, you usually select the input with the shared name and the :checked pseudo-class. The important detail is that a radio group is defined by the name attribute, not by which inputs happen to sit next to each other in the HTML.
Core Sections
How radio groups are formed
Radio buttons belong to one group when they share the same name. Only one input in that group can be checked at a time.
In this example, theme is the group. That is what your JavaScript should query.
The simplest JavaScript solution
The most direct way is:
querySelector returns the checked element itself, so you can read value, id, dataset, or any other property on that input. This is the cleanest answer for most plain HTML forms.
Read the selected radio when the user changes it
If you want to react as soon as the user switches options, use a change listener.
This pattern is often better than polling the DOM later because it keeps the UI state and the event that caused it close together.
Looping through the group manually
You do not have to use :checked. Another approach is to inspect each radio button in the group.
This is more verbose, but it is useful when you also need to inspect the full group or apply additional rules.
Handling the case where nothing is selected
Some forms intentionally start with no default selection. In that case, querySelector('...:checked') returns null, so your code must handle that safely.
That small null check prevents a very common Cannot read properties of null error.
jQuery version for older codebases
If you are maintaining older jQuery-based code, the equivalent is:
The logic is the same. The syntax is just different because jQuery wraps the DOM query.
The same checked-state query also works well at submit time, which is often better than caching the selection in extra variables. Reading the current DOM state when the form is submitted avoids subtle bugs where the UI changed but your cached value did not.
Common Pitfalls
- Grouping radio buttons visually but forgetting that the real grouping key is the shared
nameattribute. - Reading
.valuefrom the first radio in the group instead of the checked one. - Assuming one radio is always selected and then failing when the query returns
null. - Adding separate listeners to every radio when one delegated
changelistener on the form would be simpler. - Forgetting proper labels, which hurts accessibility even when the checked-state code works.
Summary
- Radio buttons are grouped by the shared
nameattribute. - The usual solution is
document.querySelector('input[name="group"]:checked'). - The returned element gives you the checked radio's
valueand other properties. - Guard against
nullwhen the form may start with no default selection. - Use a
changelistener when you want to react immediately to user selection changes.

