Detailed explanation
The method attribute on an HTML form determines how the browser submits its data to the server. GET places submitted name–value pairs in the destination URL’s query string, while POST sends them in the HTTP request body. For example, <form method="get" action="/search"><input name="q"></form> produces a URL such as /search?q=css when submitted. Changing the method to POST sends q=css in the body instead. If method is omitted, an HTML form defaults to GET. Controls generally need a name attribute to contribute data to the submission.
GET is intended for retrieving information without requesting a change to server state. Search, filtering, and pagination are suitable examples because their URLs can be copied, bookmarked, and revisited. GET is safe and idempotent by HTTP semantics: repeating an identical request should not introduce additional intended state changes, although the response can change as underlying data changes. Its responses are normally eligible for caching, subject to HTTP caching rules and headers. GET must not be used for actions such as deleting an account just because implementing them through a link is convenient.
POST submits data for processing and commonly supports login, registration, purchases, and updates through HTML forms. It is not guaranteed to be idempotent: submitting the same order twice could create two orders unless the server prevents duplicates. The body is not included when bookmarking the resulting page, and browsers may warn before resubmitting a POST. POST responses are not commonly cached, although HTTP permits caching under specific explicit conditions. By default, form bodies use application/x-www-form-urlencoded; file uploads normally require POST with enctype="multipart/form-data".
Neither method provides encryption; HTTPS protects both query strings and request bodies in transit. POST keeps submitted fields out of the URL, reducing exposure through browser history and URL logging, but does not automatically make them secure. GET submissions face practical URL-length limits imposed by browsers, servers, and intermediaries; there is no single universal maximum. POST also has configured request-size limits. Interviewers look for the distinction between retrieval and processing, not merely where the data appears.
Key points to remember
- GET sends form fields in the URL query string; POST sends them in the request body.
- Use GET for retrieval, such as searches and filters; use POST for submissions that process or change data.
- GET is safe and idempotent by definition; POST is not guaranteed to be either.
- GET URLs are bookmarkable and responses are cacheable subject to caching rules; POST submissions are not preserved by bookmarks.
- HTTPS is required for transport encryption, and both methods face implementation-specific size limits.
Common mistakes candidates make
- Claiming POST encrypts data or makes passwords secure without HTTPS.
- Saying GET has one fixed maximum length or POST allows unlimited data.
- Using GET for state-changing actions, or claiming POST responses can never be cached.
Likely follow-up questions
What does idempotent mean for GET?
Repeating the same GET request should have the same intended effect on server state as making it once. It does not mean every response must contain identical data, and incidental effects such as access logging can still occur.
Why should a login form use POST?
POST keeps credentials out of the URL, where they could appear in browser history or URL logs. The form must still use HTTPS, and the server must avoid logging sensitive request bodies.
How do you upload a file through an HTML form?
Use method="post", enctype="multipart/form-data", and an <input type="file"> with a name attribute. The server must validate the uploaded file and enforce appropriate size limits.
Interview tip: Start with URL versus request body, give search and registration examples, then clarify that POST is not automatically secure.