Can HTML Checkboxes Be Readonly? Understanding readonly vs disabled in HTML Forms

By the end of this page, you will understand why readonly does not work on HTML checkboxes, how disabled behaves differently, and what practical alternatives you can use when you need to prevent user changes while still submitting form data.

In HTML forms, readonly and disabled are not interchangeable.

The key idea is:

• readonly is supported only by certain form controls, mainly text-based inputs such as:
  • input type="text"
  • input type="email"
  • input type="number"
  • textarea
• readonly is not supported for checkboxes.
• A checkbox is either checked or unchecked, and HTML does not define a built-in readonly state for it.

That is why this does nothing:

<input type="checkbox" readonly>

Browsers simply ignore readonly for checkbox inputs.

Why this matters

This matters because form controls behave differently when submitted:

• A disabled field cannot be changed by the user.
• But a disabled field is usually not submitted with the form.
• A readonly field is submitted, but checkboxes do not support it.

So if your goal is:

1. prevent the user from changing the checkbox
2. still send its value when the form is submitted

Think of form attributes like door rules:

• disabled means the door is locked and ignored. The user cannot enter, and the form submission also skips that field.
• readonly means the user can look inside but not rearrange anything. The value is still included when submitted.

For text inputs, both ideas make sense.

For a checkbox, HTML only understands a switch that can be toggled on or off. It does not have a built-in "look but do not touch" mode. So asking for a readonly checkbox is like asking for a light switch that is visible but physically untouchable without adding your own cover over it.

The following example shows the difference between readonly and disabled.

<form>
  <label>
    Name:
    <input type="text" value="Alice" readonly>
  </label>

  <label>
    Subscribe:
    <input type="checkbox" checked readonly>
  </label>

  <label>
    Terms accepted:
    <input type="checkbox" checked disabled>
  </label>
</form>

What happens here

• The text input is readonly, so the user can see the value but cannot edit it.
• The checkbox with readonly is still changeable, because browsers ignore that attribute for checkboxes.
• The disabled checkbox cannot be changed, but its value will not be submitted.

Consider this example:

<form>
  <input type="checkbox" name="newsletter" id="newsletter" checked>
</form>

<script>
  const box = document.getElementById('newsletter');

  box.addEventListener('click', function (event) {
    event.preventDefault();
  });
</script>

Here is what happens step by step:

1. The browser creates a checkbox.
2. Because of the checked attribute, the checkbox starts in the checked state.
3. JavaScript finds the checkbox using getElementById('newsletter').
4. An event listener is attached for the click event.
5. When the user clicks the checkbox, the browser prepares to toggle it.
6. The event handler runs.
7. event.preventDefault() cancels the checkbox's default action.
8. The checkbox stays checked.

Here are common situations where this issue appears:

Account settings

A user may see that a feature is enabled by policy, but should not be allowed to change it.

Example:

• company-managed security settings
• forced two-factor authentication
• locked subscription options

Admin-controlled permissions

A form may display permissions or roles as checkboxes for visibility, but some values are controlled only by administrators.

Review or confirmation screens

You may want to display previously selected options before final submission without allowing edits at that stage.

Legal or compliance workflows

A checkbox may indicate that a rule already applies, but the user should not be able to remove it.

Imported or system-generated values

A checkbox might reflect data from another system. The value should be shown in the UI but not directly edited by the current user.

In all of these cases, the important question is whether the checkbox is truly an editable form field or just a visual representation of state.

In real projects, developers usually handle this in one of a few common ways.

Pattern 1: Disabled input plus hidden value

This is one of the most common patterns when the UI should show a locked checkbox.

<input type="checkbox" checked disabled>
<input type="hidden" name="emailVerified" value="true">

Use this when:

• the displayed value should be preserved in form submission
• the user should not edit it in the browser UI

Pattern 2: Render plain text instead of a real checkbox

If the value is not meant to be edited, many teams avoid using an actual checkbox at all.

<p>Email verified: Yes</p>

This is often clearer and more accessible when the field is informational only.

Pattern 3: Block edits in JavaScript

<input type="checkbox" name="locked"  =>

Mistake 1: Assuming readonly works on all inputs

Broken example:

<input type="checkbox" name="active" checked readonly>

Why it is a problem:

• The checkbox is still editable.
• Browsers ignore readonly for checkboxes.

How to avoid it:

• Use disabled plus a hidden field, or block interaction with JavaScript.

Mistake 2: Using disabled and expecting submission

Broken example:

<input type="checkbox" name="active" checked disabled>

Why it is a problem:

• The user cannot change it, but the browser does not submit the field.

How to avoid it:

• readonly does not work for HTML checkboxes.
• disabled does work for checkboxes, but disabled fields are not submitted.
• A checked checkbox submits its name=value pair.
• An unchecked checkbox submits nothing.

Useful patterns

Show locked checkbox and still submit value

<input type="checkbox" checked disabled>
<input type="hidden" name="featureEnabled" value="true">

Keep checkbox enabled but block user clicks

<input type="checkbox" id="box" name="featureEnabled" checked>
<script>
  document.getElementById('box').(,  () {
    event.();
  });

Can I make a checkbox readonly in HTML?

No. HTML does not support readonly for checkbox inputs, so browsers ignore it.

Why does readonly work on text inputs but not on checkboxes?

Because the HTML specification only defines readonly for certain text-like controls. A checkbox is a toggle control, not a text-editing control.

Does a disabled checkbox submit its value?

No. Disabled form controls are generally excluded from form submission.

How do I prevent users from changing a checkbox but still submit its value?

A common solution is to use a disabled checkbox for display and a hidden input with the actual submitted value.

Is JavaScript a safe way to lock a checkbox?

It is fine for user experience, but not for security. Users can bypass client-side code. Always validate on the server.

What happens if a checkbox is unchecked when the form is submitted?

Usually nothing is sent for that field. Unchecked checkboxes do not submit a value.

Should I use a checkbox at all if the value cannot be edited?

Often no. If the value is informational only, plain text or a status label may be clearer.

• HTML forms — Checkboxes are part of how forms collect and submit data.
• readonly attribute — Important for understanding why it works on some inputs but not on checkboxes.
• disabled attribute — Closely related because it prevents interaction but changes submission behavior.
• hidden inputs — Common workaround for preserving values in form submission.
• form submission — Helps explain what browsers send for checked, unchecked, readonly, and disabled fields.
• DOM events — Useful when blocking checkbox changes with JavaScript.
• client-side validation — Relevant because UI restrictions are not true security.
• server-side validation — Essential for enforcing locked values reliably.