Query string defined.
A query string is the key=value data appended to a URL after a question mark, and it's how a form using method GET carries its fields to the server.
How a query string works
A query string is the part of a URL after the question mark: pairs like name=Ada&topic=billing, joined by ampersands and percent-encoded so spaces and symbols survive. It's how data rides along in the address bar itself, which makes it perfect for search filters and pagination, where you want the URL to be shareable and bookmarkable.
A form with method="GET" builds a query string automatically: the browser takes every named field, encodes it, appends it to the action URL, and requests that address. That's the right choice for a search box. It's the wrong choice for a contact form, because everything you type ends up visible in the URL, saved in browser history, and written into server logs, and there's a length limit on how much a URL can hold. Data you're sending somewhere belongs in a POST body instead. That's why a form backend expects POST: FormWire's endpoint reads submissions from the request body, so your visitors' messages, emails and file uploads never leak into a URL.
Good for reading, wrong for sending.
Built by GET forms
A search box with method GET encodes its fields into the URL, so results are shareable and the back button just works.
Visible in the URL
Every pair sits in plain sight in the address bar, browser history and server logs. Fine for a filter, wrong for a message.
Why forms use POST
Data you're submitting belongs in the request body, out of URLs and logs, with no length cap and room for file uploads.
Related questions
When the submission only reads data and you want the result to be linkable. Search results, filters and pagination are the classic cases: a GET form puts the criteria in the URL so the page can be bookmarked, shared and cached.
A query string lives in the URL and is capped in length, logged and cached. A POST body travels separately from the address, has no practical size limit, and stays out of history and logs. Anything that creates, sends or stores data should use a POST body.
See how a POST body differs →Yes. JavaScript can parse them from the address with URLSearchParams, which is how many static sites read a UTM tag or a preselected plan. That's a read on the client, though, not data delivered to a server the way a form submission needs.
No, and that's deliberate. The endpoint reads submissions from the POST body so your visitors' details never end up in a URL or a log file. You point your form's action at the endpoint with method POST, and the fields travel safely in the body.
Want to see it working?
Read the docsHow FormWire fills the role.
Keep your form data in the body, not the URL.
Free tier forever. No credit card required.