The symptom: data in the address bar
You fill in the form, hit Send, and the page reloads with something like:
https://yoursite.com/contact?name=Jane&email=jane%40example.com&message=HelloThat's method="GET" at work — and if you never wrote a method attribute, GET is what you got, because GET is the HTML default. The browser took every field, URL-encoded it into a query string, and navigated to the resulting URL. From the browser's perspective it didn't "submit" anything; it just visited a very long link.
GET vs POST: the actual difference
The two methods describe two different intents:
- GET — "retrieve something." Parameters live in the URL, so the request is bookmarkable and shareable. Browsers, proxies, and servers all log it. Length is practically limited (~2,000 characters safely). It should never change state — fetching it twice must be harmless.
- POST — "process this." Data travels in the request body: invisible in the URL, no practical size cap, supports files via
multipart/form-data. Explicitly allowed to create things — a submission, an order, an email.
A contact form is definitionally a POST: personal data goes to a server that does something with it (emails you, stores it, fires a webhook). Encoding someone's message into a URL is both a privacy leak and — because most destinations ignore GET bodies — a silent failure.
When GET is the right choice
Search boxes, filters, and pagination: /blog?query=spam, /products?color=red&sort=price. Here the URL is the feature — users can bookmark results, share filtered views, and hit Back naturally. Rule of thumb: if the form changes nothing on the server and the result is worth linking to, GET. If it sends data to anyone or changes anything, POST.
The fix — and the error you might hit next
<form action="https://splitforms.com/api/submit" method="POST">
<input type="hidden" name="access_key" value="YOUR_ACCESS_KEY" />
<input name="name" required />
<input name="email" type="email" required />
<textarea name="message" required></textarea>
<button type="submit">Send</button>
</form>Two things must change together: method="POST" and an action that accepts POST. If you flip the method but keep pointing at a static page (/contact, index.html), you trade the URL-data bug for a 405 Method Not Allowed — static hosts only serve GET. The full diagnosis is in the 405 error guide.
With splitforms as the action, the POST body is parsed (form-encoded, multipart, or JSON), spam-filtered, stored in your dashboard, and emailed to you — free for 500 submissions/month, working identically on every static host.
Two follow-on refinements
Kill the "confirm form resubmission" warning
After a POST, refreshing the result page prompts browsers to warn about resubmitting. The cure is Post/Redirect/Get: the endpoint processes the POST then redirects the browser to a thank-you page, so a refresh re-runs an innocent GET. splitforms does this with a hidden redirect field — details in redirect after form submission and form resubmission on refresh.
Keep GET submissions out of your logs
If legacy forms must stay GET temporarily, at least scrub query strings from analytics and log pipelines — personal data in URLs propagates further than most teams expect. Better: schedule the POST migration; it's one attribute plus an endpoint.
FAQ
Why does my form put the submitted data in the URL?
Because the form's method is GET — which is also the default when the method attribute is missing. GET appends fields to the action URL as a query string (?name=...&email=...) and the browser navigates to that URL, which looks like a page reload with your data exposed in the address bar. Set method="POST" to send the data in the request body instead.
What is the actual difference between GET and POST in a form?
GET packages the fields into the URL's query string and asks the server to retrieve something — it's visible in browser history, server logs, analytics, and has a practical ~2,000-character limit. POST puts the fields in the request body and asks the server to process something — invisible in the URL, no practical size limit, and the correct choice whenever data is being created or sent to someone.
Is it ever correct to use GET on a form?
Yes — for search and filter forms where the result is a bookmarkable, shareable view of the same page: /search?q=shoes, /products?color=red&sort=price. GET is designed for retrieval. Never use it for contact forms, logins, orders, or anything containing personal data.
Why is GET dangerous for contact forms specifically?
Three reasons: the visitor's name, email, and message end up in server logs, proxy logs, browser history, and any analytics that records page URLs; URLs get shared and bookmarked, leaking that personal data; and most endpoints (and all static hosts) don't process GET submissions, so nothing is delivered anyway.
I changed to POST and now I get a 405 error — what happened?
Your action URL points at a static page that only serves GET. POST needs a destination that runs code: a form endpoint like https://splitforms.com/api/submit, a serverless function, or a server-side route. The 405 error guide walks through the fixes.
How do I stop the browser warning 'confirm form resubmission' on refresh?
That's the browser protecting against duplicate POSTs when a user refreshes the result page. The standard fix is the Post/Redirect/Get pattern: after processing the POST, the server responds with a redirect to a thank-you page, so refresh re-requests a harmless GET. splitforms supports this with a hidden redirect field.
Switch to POST with an endpoint that actually processes it. Get a free access key.
Related: the form method attribute, the complete form action guide, and how form action works.