Forms Introduction (<form>)

The <form> element is how HTML collects user input and sends it somewhere — a login screen, a search box, a checkout flow, a comment box. Everything from a single search field to a multi-step checkout ultimately boils down to a <form> wrapping a set of inputs and a submit control.

A Minimal Form

HTML

<form action="/search" method="get">
  <label for="q">Search</label>
  <input type="text" id="q" name="q">
  <button type="submit">Go</button>
</form>

Note

The name attribute on each input is what becomes the key in the submitted data. An input without a name is not submitted at all — a very common beginner mistake.

The action Attribute

action is the URL the form data is sent to when submitted. If omitted, the form submits to the current page's URL.

HTML

<form action="/api/subscribe">
  <!-- submits to https://yoursite.com/api/subscribe -->
</form>

<form>
  <!-- no action: submits back to the current page URL -->
</form>

The method Attribute: GET vs POST

method controls HOW the browser sends the data — and this choice has real consequences for security, caching, and what kind of data you can send.

Aspect	GET	POST
Where data goes	Appended to the URL as a query string	Sent in the request body
Visible in URL / history / logs	Yes	No
Can be bookmarked / shared as a link	Yes	No
Suitable for sensitive data (passwords)	No	Yes (still requires HTTPS)
File uploads	Not supported	Supported (with proper enctype)
Idempotent / safe to repeat	Yes — intended for reading, not changing state	No — intended for state-changing actions
Typical use	Search forms, filters	Login, signup, checkout, comments

HTML

<!-- GET: good for search — shareable, bookmarkable URL -->
<form action="/search" method="get">
  <input type="text" name="q">
  <button type="submit">Search</button>
</form>
<!-- Submitting "html forms" navigates to: /search?q=html+forms -->

<!-- POST: good for anything that changes server state -->
<form action="/login" method="post">
  <input type="text" name="username">
  <input type="password" name="password">
  <button type="submit">Log In</button>
</form>
<!-- Credentials go in the request body, not the URL -->

Warning

Never use method="get" for a form containing a password or other sensitive field. GET data ends up in the browser history, server access logs, and can be leaked via the Referer header — none of which happens with POST.

The Form Submission Lifecycle

The user fills in form controls and triggers submission — clicking a submit button, or pressing Enter in a single-line text field.
The browser runs built-in constraint validation (required, pattern, type checks) on every control. If anything fails, submission is blocked and the browser focuses the first invalid field.
If validation passes, the browser gathers every successful control's name/value pairs (unnamed or disabled controls are skipped).
It builds the request: for GET, values are URL-encoded into the query string; for POST, they go in the body using the encoding set by enctype.
The browser navigates to (or fetches) the action URL using the specified method, sending the encoded data.

Form:
  <form action="/search" method="get">
    <input type="text" name="q" value="html forms">
  </form>

Resulting navigation:
  GET /search?q=html+forms

Form:
  <form action="/login" method="post">
    <input type="text" name="username" value="ana">
    <input type="password" name="password" value="secret123">
  </form>

Resulting request:
  POST /login
  Body: username=ana&password=secret123

Submitting Without a Button Click

Pressing Enter inside a single-line text input submits the form automatically — as long as there's a submit button (even a hidden one) somewhere in the form. This is a common source of confusion when a form "submits on Enter" unexpectedly during development.

Tip

To prevent Enter-key submission on a single-field form intentionally (e.g. a live search box that submits via JavaScript on every keystroke), listen for the form's submit event and call event.preventDefault(), rather than removing the submit button.

Preview: What's Coming Next

Form attributes in depth — enctype, target, autocomplete, novalidate.
Labels and why for/id association matters for accessibility.
Every input type — text, email, number, checkboxes, dates, files, and more.
Validation and the Constraint Validation API for custom error handling.

Key Takeaways

<form> wraps a set of controls and defines where (action) and how (method) their data is sent.
GET appends data to the URL — good for shareable searches, bad for sensitive data.
POST sends data in the request body — the correct default for anything that changes server state or contains sensitive information.
Only named controls with valid values are included in a submission.
The browser runs constraint validation before submitting; invalid fields block submission and get focused automatically.