Links vs Forms in HTTP Requests
Every time a user clicks a navigation link or submits a search query, the browser makes an HTTP request. But which HTML element triggers that request — and how — matters more than most developers realize. Choosing between <a> and <form> isn’t just a markup preference. It’s a semantic decision that affects behavior, security, and correctness.
Key Takeaways
- Links (
<a>) are for navigation and typically trigger GET requests. Forms (<form>) are for data submission and support both GET and POST. - Use GET forms when user input shapes the URL (like search queries) and POST forms when the action changes server state (like account creation).
method="link"is invalid HTML — browsers silently fall back to GET, which can lead to unexpected behavior.- HTML forms only support GET and POST natively. For PUT, PATCH, or DELETE, use JavaScript.
The Core Difference: HTML Navigation vs Submission
Links (<a>) are navigation elements. They tell the browser: “Go get this resource.” Clicking a link typically triggers a GET navigation request to the URL in the href attribute. That’s it. No user input is collected, no data is serialized — just a clean navigation event.
Forms (<form>) are data submission elements. They collect input from the user and send it to a server. A form can use either GET or POST, depending on the nature of the request.
Here’s a quick comparison:
| Feature | <a> Link | <form> |
|---|---|---|
| Purpose | Navigation | Data submission |
| HTTP method | GET only | GET or POST |
| Collects user input | No | Yes |
| Right-click / open in new tab | Yes | No |
| SEO crawlable | Yes | Limited |
| Changes server state | No | Yes (with POST) |
GET vs POST in HTML Forms: When Each Applies
Use a link for safe, idempotent navigation
If the action doesn’t change anything on the server and the destination can be bookmarked or shared, use a link:
<a href="/articles/html-basics">Read the HTML guide</a>Links are safe, idempotent, and cacheable — exactly what GET requests should be.
Use a GET form when user input shapes the URL
A search box is the classic example. The user types a query, and the form appends it to the URL as a query string:
<form method="get" action="/search">
<input type="search" name="q" placeholder="Search...">
<button type="submit">Search</button>
</form>This produces /search?q=your+query — a shareable, bookmarkable URL. Use GET forms when the request is still safe and idempotent, but the URL parameters depend on user input.
Use a POST form when the action has side effects
Creating an account, submitting a payment, or posting a comment all change server state. These belong in POST forms:
<form method="post" action="/register">
<input type="email" name="email">
<input type="password" name="password">
<button type="submit">Create account</button>
</form>POST sends data in the request body, not the URL — which is appropriate for sensitive data and non-idempotent actions.
Discover how at OpenReplay.com.
A Common Mistake: method="link" Doesn’t Exist
Some developers write <form method="link"> hoping to create a “link button.” This is invalid HTML. Browsers ignore the unknown value and fall back to the default — which is GET. The form still submits, but it does so silently and incorrectly.
If you want a button that navigates somewhere, use a link styled as a button — not a form:
<!-- ❌ Invalid -->
<form method="link" action="/about">
<input type="submit" value="Go to About">
</form>
<!-- ✅ Correct -->
<a href="/about" class="btn">Go to About</a>Modern Form Capabilities Worth Knowing
HTML5 added per-button overrides via formaction and formmethod attributes, letting individual submit buttons change where or how a form submits:
<form method="post" action="/save">
<button type="submit">Save</button>
<button type="submit" formaction="/save-and-publish" formmethod="post">Publish</button>
</form>Also worth noting: requestSubmit() (unlike submit()) triggers form validation before submission, making it the better choice for programmatic form submission in JavaScript.
For PUT, PATCH, or DELETE, HTML forms don’t support these natively. You’ll need JavaScript (fetch, XMLHttpRequest) or a server-side method override convention.
Conclusion
The decision between links and forms is straightforward once you understand the semantics:
- Navigating to a page? Use a link.
- Collecting user input for a query? Use a GET form.
- Submitting data that changes server state? Use a POST form.
- Performing PUT/PATCH/DELETE? Use JavaScript.
Reach for the element that matches the intent of the action. Semantic HTML isn’t just about correctness — it’s what makes your UI predictable, accessible, and maintainable.
FAQs
Technically yes, but it’s usually the wrong semantic choice. A GET form is designed to collect user input and append it to the URL as query parameters. For simple navigation with no user input, a link is the correct semantic choice. Links are crawlable by search engines, support right-click context menus, and clearly communicate navigational intent to both browsers and assistive technologies.
Browsers treat any unrecognized method value as invalid and silently fall back to GET, which is the default form method. So a form with method link still submits, but it behaves exactly like a GET form. This can mask bugs and produce confusing behavior. Always use get or post as your form method value.
The submit() method sends the form immediately without running built-in HTML validation or firing the submit event. The requestSubmit() method behaves like a user clicking the submit button. It triggers constraint validation first and fires the submit event, allowing event listeners to intercept or cancel the submission. Use requestSubmit() when you need validation to run.
HTML forms only support GET and POST as method values. To send DELETE, PUT, or PATCH requests, you need JavaScript using fetch or XMLHttpRequest. Some server-side frameworks also support a method override pattern where you submit a POST form with a hidden input field that specifies the intended HTTP method, which the server then interprets accordingly.
Gain control over your UX
See how users are using your site as if you were sitting next to them, learn and iterate faster with OpenReplay. — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.
