Goal
You’ll understand what actually happens when a form is submitted, the real difference between GET and POST methods, and genuine UX considerations that separate a functional form from a well-designed one.
Learn
A form’s action and method attributes control what happens on submission:
<form action="/submit" method="post">
action specifies where the form data gets sent. method specifies how: GET appends the form data directly to the URL as query parameters (visible in the address bar, bookmarkable, appropriate for something like a search form), while POST sends the data in the request body, not visible in the URL (appropriate for anything sensitive or data-changing, like login credentials or a purchase).
Real form UX goes beyond just technical correctness. A few genuinely important practices: use <button type="submit"> explicitly rather than relying on default behavior, since a form can contain multiple buttons with different purposes. Provide clear, specific error messaging when validation fails, not just a generic “error” message. Group related fields visually and structurally, often using <fieldset> and <legend> for genuinely related groups of inputs, like a set of radio buttons or an address block.
<fieldset> <legend>Shipping Address</legend> <label for="street">Street</label> <input type="text" id="street" name="street"> </fieldset>
<fieldset> groups related form controls together, with <legend> providing a caption for the whole group — genuinely useful both visually and for screen readers, which announce the legend when a user enters that group of fields.
Decision Task
A login form sends a username and password. Before reading on: should this form use method=”get” or method=”post”, and why does this choice matter beyond just convention?
Show Answer
method=”post” — with GET, the password would be appended directly to the URL as a visible query parameter, potentially exposed in browser history, server logs, and shared links. POST keeps sensitive data in the request body instead, which is both more secure and semantically correct, since login is a data-processing action, not a bookmarkable content retrieval.
Common Mistake
Using method=”get” by default (since it’s often the browser’s implicit default if method is omitted entirely) for forms handling sensitive or data-changing actions like login, payment, or account updates. Beyond the security exposure of sensitive data in the URL, GET requests are also meant to be safely repeatable/bookmarkable, which doesn’t make sense for an action like “submit a payment” that shouldn’t be accidentally repeated.
Practice Questions
1. A search form on a blog lets users bookmark or share their exact search results URL. Which method fits this use case, and why?
Show Answer
GET — since search results are content retrieval that benefits from being bookmarkable/shareable via URL, unlike a data-changing action.
2. Write a fieldset with a legend “Contact Info” wrapping a single email input.
Show Answer
<fieldset><legend>Contact Info</legend><label for="email">Email</label><input type="email" id="email" name="email"></fieldset>
3. Why might a form intentionally include a <button type=”button”> alongside a <button type=”submit”>?
Show Answer
A type=”button” doesn’t submit the form by default, useful for secondary actions like “Cancel” or “Clear” that shouldn’t trigger submission, distinct from the actual submit action.
4. True or False: it’s generally fine to use GET for a payment form, since it’s simpler to set up.
Show Answer
False — payment involves sensitive, data-changing action that shouldn’t be exposed in a URL or safely “repeatable” the way GET requests are meant to be; POST is the correct, safer choice.
5. What accessibility benefit does <legend> provide inside a <fieldset>, beyond visual grouping?
Show Answer
Screen readers announce the legend text when a user enters that group of fields, giving context for the related inputs that follow, similar to how a label provides context for one individual input.
Try It Yourself
Without looking back, decide and justify: should a “Change Password” form use GET or POST, and why, using this lesson’s reasoning about sensitive/data-changing actions?
Show Answer
POST — changing a password is both a sensitive action (shouldn’t appear in URL/browser history) and a data-changing action (shouldn’t be safely bookmarkable/repeatable the way GET implies), matching exactly the reasoning covered for login and payment forms in this lesson.
Quick Check
1. What does the action attribute on a form specify?
Show Answer
Where the form data gets sent upon submission.
2. What’s the key difference between GET and POST regarding where form data appears?
Show Answer
GET appends data visibly to the URL as query parameters; POST sends it in the request body, not visible in the URL.
3. Why is POST generally correct for sensitive data like passwords?
Show Answer
It avoids exposing sensitive data in the URL, browser history, or server logs, unlike GET.
4. What does <fieldset> do, and what does <legend> provide within it?
Show Answer
Fieldset groups related form controls together; legend provides a caption for that group, announced by screen readers when entering it.
5. Why might a form need a button with type=”button” instead of type=”submit”?
Show Answer
For secondary actions like “Cancel” that shouldn’t trigger form submission, distinct from the actual submit action.