The HTML <form> Element

Basic

The <form> element defines a section of a document whose associated controls can be used to collect and submit information. It is the boundary that ties controls together as one form, while attributes on the form establish default submission and autofill behavior.

What the <form> element represents

A form is not just a visual box around fields. It establishes a form owner for form-associated elements nested inside it and provides the defaults used when the form is submitted. The browser can then apply native form behavior without requiring JavaScript to invent the underlying model.

<form action="/account" method="post">
  <label for="display-name">Display name</label>
  <input id="display-name" name="displayName" autocomplete="name">
  <button type="submit">Save</button>
</form>

<? action="/account" method="post">
  <input name="email">
</form>

The name on the control is part of the submitted data model; the id connects the control to its label. The form element itself does not turn arbitrary descendants into submitted fields. Submission depends on which associated elements are submittable and whether they have successful submission data.

A form cannot contain another form

The content model of <form> permits flow content but not another <form> element. Do not nest forms to represent separate visual groups. If a page needs multiple independent submissions, give each submission its own form and use ordinary grouping elements inside each one.

<form action="/profile" method="post">
  <fieldset>
    <legend>Profile</legend>
    <label for="name">Name</label>
    <input id="name" name="name">
  </fieldset>
</form>

The form action

The action attribute supplies the URL that processes the submission. It is about where the form submission is sent, not where the page currently lives. If it is omitted, the browser uses the form submission URL defined by the HTML submission algorithm and document context.

<form action="/signup" method="post">
  <!-- controls -->
</form>

Choosing the method

The method attribute selects the submission method. get is the default and places the encoded form data in the destination URL. post sends the form data in the request body. dialog is a special mode for a form associated with a <dialog>; it closes the dialog and fires a submit event without sending the form data as a normal navigation submission.

Encoding submitted data

The enctype attribute controls how a POST submission encodes its entry list. The default is application/x-www-form-urlencoded. Use multipart/form-data when the form includes file uploads. text/plain exists as another encoding option and can be useful for debugging, but it is not a general replacement for the standard encodings.

<form action="/upload" method="post" enctype="multipart/form-data">
  <label for="avatar">Profile photo</label>
  <input id="avatar" name="avatar" type="file">
  <button type="submit">Upload</button>
</form>

Where the response goes

The target attribute chooses the browsing context that receives the response to a form submission. The common values are _self, _blank, _parent, and _top. A submit button can override the form-level target with its own formtarget attribute.

Autofill belongs to the user

The autocomplete attribute gives the browser guidance about whether it may automatically fill controls and, on individual controls, what kind of information a field expects. A form-level value provides a default that individual controls can override. Useful field tokens such as name, email, or street-address describe the data purpose rather than the visual label.

<form autocomplete="on">
  <label for="email">Email address</label>
  <input id="email" name="email" type="email" autocomplete="email">
</form>

Naming and identifying a form

The name attribute gives the form a name for the document’s forms collection. It must not be empty and should be unique among the forms in that collection. The global id attribute is different: it identifies the element in the document and is what other form-associated elements can reference through their form attribute.

<form id="checkout" name="checkoutForm" action="/checkout" method="post">
  ...
</form>

<!-- A form-associated control can refer to this form by id. -->
<input form="checkout" name="coupon">

Controls do not always have to be inside the form

Most form controls are associated with their nearest ancestor <form>. A form-associated element can instead use the form attribute to name the id of a form in the same document. This is useful when document layout requires a control to live elsewhere, but it does not make every descendant of that control’s surrounding container part of the form.

<form id="account">…</form>

<input name="email" ?>

Skipping constraint validation

The boolean novalidate attribute tells the browser not to run constraint validation as part of that form submission. It does not make invalid data valid, and it does not remove the need for server-side validation. A particular submit button can use formnovalidate to override the form’s validation behavior for that submission.

<form action="/drafts" method="post" novalidate>
  <label for="title">Title</label>
  <input id="title" name="title" required>
  <button type="submit">Save draft</button>
</form>

Accessibility and form structure

A good form gives each user-facing control an accessible name and groups related controls meaningfully. <label> belongs with labelable controls; <fieldset> and <legend> can expose a group and its caption. The <form> element supplies the overall form boundary, but it does not replace labels for individual controls.

Keep the visible wording, control purpose, and submitted data model aligned. A label such as “Email address” should identify the control, while the control’s name determines the key used in the submission data.

The form is declarative; submission can be enhanced later

HTML already defines the form model, validation hooks, submission attributes, reset behavior, and events. JavaScript can enhance that behavior, intercept submission, update the interface, or send data with APIs, but it should build on the native form rather than replacing the form element with a collection of unrelated controls.

Common mistakes

Avoid nested forms; do not use placeholder as a replacement for labels; do not choose GET or POST merely because a framework example used it; do not use novalidate as a security measure; and do not assume client-side validation or browser UI makes server-side validation unnecessary.

A practical form checklist

Before considering a form complete, check: a real <form> boundary exists; controls have appropriate labels; related controls are grouped where useful; action and method match the application’s submission contract; file uploads use the appropriate encoding; autofill guidance is meaningful; and validation decisions are deliberate. Then test the actual submission path rather than trusting only the visual appearance.