Purpose and content model
Form groups controls for submitting a set of named values. Its action identifies the receiving resource and its method determines the submission method. The browser can collect data and provide basic validation, but an HTML form alone does not create a storage system, authentication process, or secure server handler.
A form contains flow content but must not contain another form. Controls can be associated with a form by ancestry or by a supported form attribute pointing to its ID. Not every visible control is submitted: a disabled field, an unchecked checkbox, or a field without a name can be absent from the resulting data.
Syntax and working example
<form action="/search/" method="get">
<label for="q">Search the catalogue</label>
<input id="q" name="q" type="search">
<button type="submit">Search</button>
</form>Supported attributes and behavior
Action, method, enctype, target, autocomplete, novalidate, name, accept-charset, and rel are relevant form attributes. GET puts values in a URL query and suits retrieval such as search; POST sends a request body and suits state-changing operations. File uploads need multipart/form-data. A submit button can override action, method, encoding, target, and validation through its form* attributes. Method=dialog is a special dialog workflow and does not make a network submission.
Another practical pattern
<form action="/upload/" method="post" enctype="multipart/form-data">
<label for="photo">Choose a photo</label>
<input id="photo" name="photo" type="file" accept="image/*">
<button type="submit">Upload photo</button>
</form>Accessibility and browser notes
Use visible labels, clear instructions, and actionable error messages. Validation errors should preserve entered data and identify affected controls. Browser validation can be bypassed, so the receiving application must validate, authorize, and protect state-changing requests. HTTPS protects transport; method=post does not provide encryption by itself.
Common mistakes
Do not nest forms, put secrets into GET query strings, or treat accept as an upload security control. Do not silently discard values when a validation failure occurs. A successful submit event is not proof that the server accepted or saved the data.
Verify your implementation
Inspect the actual request and verify its names, values, encoding, destination, and response. Test empty fields, unchecked choices, disabled controls, multiple submit buttons, and server rejection. The isolated learning playground blocks submissions; use a deliberate local test endpoint for this verification.
Standard status and sources
Standard; browser availability must be checked independently of specification status.