Readonly vs Disabled Inputs: They Are Not the Same Thing

The quick answer: a readonly input stops users from editing a field's value but still submits that value with the form and lets users focus and select it. A disabled input blocks editing too, but it also removes the field from focus, drops it from form submission entirely, and greys it out visually. So when you weigh readonly vs disabled, the real question is whether you still want that value sent to your server.

The core differences at a glance

Both attributes prevent a user from typing into a field, but everything else about them diverges. Here is the side-by-side breakdown.

What readonly actually does

The readonly attribute locks the value so the user cannot change it, while treating the field as a fully live part of the form. The value gets sent when the form submits, the user can click into it, highlight the text, and copy it.

<input type="text" name="invoice_id" value="INV-20418" readonly>

Reach for readonly when the value matters to your backend but should not be touched by hand:

• An auto-generated invoice number, order ID, or reference code you want submitted as-is.
• A pre-filled email or account name that the user should see and confirm but not edit.
• A calculated total that updates via JavaScript but should not accept manual typing.

What disabled actually does

The disabled attribute takes a field completely out of play. The browser greys it out, skips it in the tab order, blocks focus and selection, and, most importantly, leaves its value out of the submitted form data.

<input type="text" name="coupon" value="SAVE10" disabled>

In that example, when the form is submitted, no coupon key appears in the request at all. That is the single biggest trap people hit: they disable a field, then wonder why the value never reaches the server.

Use disabled when the field is genuinely unavailable right now:

• A submit button that stays off until a checkbox is ticked.
• A "State" dropdown that is inactive until the user picks a country.
• Options that don't apply to the current plan or selection and you don't want submitted.

When to use each one

A simple decision path:

1. Should the value be submitted? If yes, you cannot use disabled. Use readonly (or disabled plus a matching hidden input carrying the same value).
2. Should the user be able to select or copy the text? If yes, readonly. Disabled fields can't be selected.
3. Is the field temporarily off because of another choice? That is classic disabled territory, like a button waiting on a condition.

These states matter most inside real forms, and they pair naturally with other choices you make about layout and behavior. If you are still deciding how a field itself should be built, our guide on choosing between a datalist and a select covers input types that also interact with these attributes. And once your fields are set, understanding where the HTML form action sends your data helps you predict exactly which values land on the server, disabled ones included (or rather, excluded).

Common gotchas and accessibility notes

• Disabled kills accessibility clues. Screen readers often skip disabled controls or announce them as unavailable, and keyboard users can't tab to them. If a user needs to read the value, readonly is far friendlier.
• Readonly still shows validation quirks. Per the MDN readonly reference, readonly fields are barred from constraint validation, so a required readonly field will not block submission the way you might expect.
• Client-side locks are not security. Both attributes only affect the browser. A user can edit the HTML in dev tools and change a readonly value or re-enable a disabled one. Always validate and re-check on the server.
• Styling differs. Readonly fields look normal, so add a subtle style (like a lighter background) so users notice they can't type. Disabled fields already look greyed out by default.
• The disabled-plus-hidden trick. When you want a select to look locked but still submit its value, mark the visible select disabled and add a <input type="hidden"> with the same name and value.

The official MDN documentation on the disabled attribute confirms these behaviors are consistent across modern browsers, so you can rely on them without vendor-specific workarounds.

Build a contact form that submits exactly the right fields

Whether you use readonly to lock a pre-filled value or disabled to hide one from submission, our contact form endpoint captures every field you actually send, no backend required.

Try our free contact form →

Frequently asked questions