HTML readonly versus disabled: preserve the right submission contract

Last updated: 7 Oct 20267 min read

tutorial

Readonly keeps a supported control's value in form submission; disabled removes most controls from interaction and submission.

Why this choice matters

A shipment correction screen shows the registered parcel code beside an inspection note. The code is fixed for this request and still accompanies the POST, so readonly fits the visible field. A retired reference is displayed in a disabled field because it is not part of the decision. Neither attribute protects server data: a caller can change the submitted code or add a missing field. The server reads the authoritative parcel record and checks the user's permission before saving.

<form action="/shipments/S-47/review" method="post">
  <label for="parcel-code">Registered parcel code</label>
  <input id="parcel-code" name="parcel_code" value="004731" readonly>
  <label for="retired-reference">Retired reference</label>
  <input id="retired-reference" name="retired_reference" value="OLD-29" disabled>
  <label for="inspection-note">Inspection note</label>
  <textarea id="inspection-note" name="note" required></textarea>
  <button type="submit">Save review</button>
</form>

What it does not do

Readonly does not apply to every input type, including checkboxes. Disabled controls are omitted from successful form data. Use ordinary text when a value is only for reading and does not need control semantics.

Cost and operational limits

These native states need no script. The operational cost is the common backend mistake of treating a submitted readonly value as authoritative or treating an omitted disabled value as a request to clear stored data.

Common Mistakes

Do not assume readonly is a security control.
Do not expect disabled values in the POST body.
Do not use a disabled control when plain text communicates the record better.

Connected lessons

Related CSS decisions

CSS :read-only: distinguish fixed values from disabled controls

html

comparison