Introduction

A disabled HTML input is not included in form submission, so ASP.NET MVC model binding never receives its value. That behavior comes from the browser, not from MVC, which means the real fix is in form design and server-side validation, not in trying to make model binding recover data that was never posted.

Why Disabled Inputs Do Not Post

Browsers omit disabled controls from the submitted form payload by design. If the browser never sends the value, MVC has nothing to bind.

This looks visible to the user:

<input name="Email" value="[email protected]" disabled="disabled" />

But on submit, the Email field is missing from the request unless some other input carries the same value.

Use readonly When the Value Should Still Post

If the field should be visible, non-editable, and still submitted, readonly is often the correct attribute.

<input asp-for="Email" readonly="readonly" class="form-control" />

Readonly fields are usually posted back for supported input types, which makes them a better fit when the user should see the value but not edit it.

That said, readonly and disabled are not the same user experience. A readonly field may still be focusable and copyable, which can be either useful or undesirable depending on the form.

Pair a Disabled Input with a Hidden Input

If the control really needs to look disabled, a common pattern is to render a hidden input with the same value.

<input asp-for="Email" disabled="disabled" class="form-control" />
<input type="hidden" asp-for="Email" />

The visible input becomes display-only, while the hidden input is what actually gets submitted:

1[HttpPost]
2[ValidateAntiForgeryToken]
3public IActionResult Save(ProfileVm vm)
4{
5    if (!ModelState.IsValid)
6        return View(vm);
7
8    _service.Update(vm);
9    return RedirectToAction("Done");
10}

This works for ordinary round-trip UI behavior, but it introduces an important security point.

Rehydrate Sensitive Values on the Server

Hidden inputs are still client-controlled. If the field is security-sensitive or business-critical, do not trust the posted value even if the UI showed it as disabled.

Instead, reload the trusted value from the server-side source of truth:

1[HttpPost]
2[ValidateAntiForgeryToken]
3public IActionResult Save(ProfileVm vm)
4{
5    var existing = _service.GetById(vm.Id);
6    if (existing == null)
7        return NotFound();
8
9    vm.Email = existing.Email;
10    _service.UpdateEditableFields(vm);
11    return RedirectToAction("Done");
12}

This is safer for identifiers, prices, roles, permissions, account ownership, and anything else the browser should not be allowed to redefine.

Keep Presentation Separate from Authorization

A disabled control is only a presentation choice. It is not an authorization rule.

The server must still decide what the user is allowed to change regardless of which form fields appear greyed out in the browser. That is why anti-forgery protection, model validation, and authorization checks still matter:

<form asp-action="Save" method="post">
    @Html.AntiForgeryToken()
</form>

The UI can suggest that a field is locked, but only the server can enforce that rule.

Sometimes Plain Text Is Better

If a value only needs to be displayed and does not need to behave like a form control, plain text plus a hidden field can be clearer than a disabled input.

<p class="form-control-static">@Model.Email</p>
<input type="hidden" asp-for="Email" />

This avoids some of the accessibility and usability oddities that come with disabled inputs while still preserving round-trip submission when appropriate.

Common Pitfalls

The biggest mistake is expecting disabled inputs to be submitted. They are not.

Another issue is trusting hidden inputs for security-sensitive values. Hidden does not mean trusted.

Developers also sometimes use readonly blindly on fields where the resulting UX is awkward or inconsistent, especially if the field should not behave like an editable control at all.

Summary

• Disabled inputs are not submitted, so MVC cannot bind their values.
• Use readonly when a field should stay non-editable but still post back.
• Use a hidden mirror only when the client is allowed to send that value.
• Rehydrate sensitive values from the server instead of trusting the browser.
• Keep authorization and business rules on the server, not in HTML attributes.