What are the main differences between the GET and POST HTTP request methods?

Purpose

• GET requests a representation of a resource. By specification it is read-only: the client does not expect any server state change. RFC 9110 notes that sending a body in a GET request has undefined semantics, so GET should not carry a body.
• POST asks the target resource to process the data enclosed in the request body according to that resource's own semantics (create a record, submit a form, upload a file, etc.).

Where the data goes

• GET carries parameters in the URL query string (after ?, formatted as key=value&...). These are visible in the address bar and recorded in browser history and server logs, and are bounded by a practical URL-length limit.
• POST carries data in the request body; the type is given by the Content-Type header. HTML forms typically use application/x-www-form-urlencoded (the default) or multipart/form-data (for files). There is no fixed protocol-level size limit, but servers and proxies configure their own maximums (e.g. Nginx client_max_body_size).

Properties per RFC 9110

• Safe: GET is safe (read-only); POST is not.
• Idempotent: a request is idempotent if making it N times has the same effect on server state as making it once. GET is idempotent; POST is not — repeating it may create duplicates, such as two identical orders. Idempotent is not the same as safe (PUT and DELETE are idempotent but not safe), and it says nothing about the response body being identical.
• Cacheable: GET responses are cacheable by default; POST responses are cacheable only when they include explicit freshness information and a matching Content-Location header, which is rare in practice.

Practical implications

• Use GET for retrieval and navigation; results can be safely repeated, bookmarked, and prefetched, and refreshing a GET page is harmless.
• Use POST for state-changing actions and for sending sensitive or large payloads. Refreshing or navigating back to a POST page triggers the browser's "confirm form resubmission" warning.
• Never send passwords via GET — they would land in the URL, logs, and history. This is hygiene, not encryption: HTTPS encrypts both URL and body in transit, but the URL is still logged.

Common follow-ups

• Safe methods are GET, HEAD, OPTIONS; idempotent methods are GET, HEAD, PUT, DELETE; POST is neither.
• Both methods are supported by HTML forms (the method attribute).
• "Safe" in the RFC sense means no state change, not data protection.
• Application-level POST idempotency is often enforced using idempotency keys.