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

then you need a workaround rather than relying on readonly.

Common alternatives

Typical approaches include:

• using disabled plus a hidden input
• blocking interaction with JavaScript
• replacing the checkbox with plain text or a visual indicator when editing is not allowed

The best choice depends on whether the value is only for display, must be preserved exactly, or needs strong server-side validation.

Important security note

Client-side restrictions are only for user experience. A user can still modify HTML or send custom requests. If a value must not be changed, the server must validate and enforce that rule.

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.

Practical workaround: disabled checkbox + hidden input

If you want to show a non-editable checked checkbox and still submit a value, a common pattern is:

<form action="/submit" method="post">
  <label>
    Premium account:
    <input type="checkbox" checked disabled>
  </label>

  <input type="hidden" name="premiumAccount" value="true">

  <button type="submit">Submit</button>
</form>

Why this works

• The checkbox is visible and cannot be changed.
• The hidden input carries the value that will be submitted.

JavaScript-based interaction blocking

Another option is to prevent changes with JavaScript:

<label>
  Locked option:
  <input type="checkbox" id="lockedBox" checked>
</label>

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

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

This stops the user from toggling the checkbox in normal browser interaction, while the checkbox remains part of the form.

However, this is only a client-side convenience and must not be trusted for security.

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.
9. If the form is submitted, the checkbox value is still submitted because the checkbox is not disabled.

Compare that with disabled

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

Step by step:

1. The checkbox is created in the checked state.
2. Because it is disabled, the user cannot interact with it.
3. When the form is submitted, the browser skips this field.

That difference is the main reason people look for a readonly checkbox alternative.

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" checked id="locked">
<script>
  document.getElementById('locked').addEventListener('click', function (event) {
    event.preventDefault();
  });
</script>

Use this when:

• you need the field to remain enabled
• you want the native checkbox value submitted
• you understand that the server must still enforce the rule

Pattern 4: Server-side guard clause

On the server, never trust a locked checkbox just because the UI looked locked.

Example logic:

if (!user.isAdmin) {
  submittedData.canDeleteUsers = existingData.canDeleteUsers;
}

This is the real protection.

Pattern 5: Conditional rendering

In many codebases, the template decides whether to show:

• an editable checkbox
• a disabled checkbox with hidden input
• plain text status

This keeps the UI honest about whether the user can actually edit the value.

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:

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

Mistake 3: Trusting hidden inputs for security

Broken assumption:

• "If I use a hidden input, the user cannot change it."

Why it is a problem:

• Users can edit hidden inputs in developer tools or send custom requests.

How to avoid it:

• Always validate and enforce locked values on the server.

Mistake 4: Showing an uneditable control when plain text would be clearer

Sometimes a checkbox suggests the user can interact with it, even if you block clicks.

Better alternative:

<p>Notifications enabled: Yes</p>

Use this when the value is informational, not editable.

Mistake 5: Forgetting unchecked checkboxes submit nothing

A checkbox only submits a value when it is checked.

Example:

<input type="checkbox" name="subscribe" value="yes">

• Checked: sends subscribe=yes
• Unchecked: sends nothing at all

This matters when building hidden-input workarounds or processing forms on the server.

Quick comparison: readonly vs disabled

The most important takeaway is simple: if you need a locked checkbox that still submits data, disabled alone is not enough.

• 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').addEventListener('click', function (event) {
    event.preventDefault();
  });
</script>

Use plain text if the field is not editable

<p>Feature enabled: Yes</p>

Rules to remember

• readonly is for text-like fields, not checkboxes.
• disabled prevents interaction but also prevents submission.
• Hidden inputs are useful for preserving submitted values.
• Server-side validation is required for anything that must truly stay locked.

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.