GET vs POST
GET and POST are the two HTTP methods every web developer uses constantly. GET is for retrieving data — it's safe, idempotent, and cacheable. POST is for sending data to create or change something — it's neither safe nor automatically idempotent. Picking the right method matters more than newcomers usually expect.
Last reviewed on 2026-04-27.
Quick Comparison
| Aspect | GET | POST |
|---|---|---|
| Intent | Retrieve data | Submit data; create or change something |
| Safe? | Yes — should not modify server state | No — typically modifies state |
| Idempotent? | Yes — same request, same effect | Not by default |
| Cacheable? | Yes (by default) | Generally not |
| Body | No body (or ignored by most servers) | Carries the data being submitted |
| Parameters in | URL query string | Body (typically JSON or form-encoded) |
| Visible in browser history | Yes — URL is the request | No — body isn't logged like a URL |
| Length limits | Practical URL length limits (~2 KB) | Effectively unlimited (depending on server config) |
Key Differences
1. What each one is for
GET retrieves a representation of a resource. Loading a page, fetching a list of users, requesting a JSON file — all GET. The server should not change anything in response to a GET.
POST sends data to a resource and lets the server do something with it: create a user, submit a comment, charge a card. POST is how the client expresses intent to change state.
2. Safe and idempotent
GET is "safe" (must not modify state) and "idempotent" (running it twice has the same effect as once). That lets browsers, caches, and crawlers retry GETs without worrying about duplicates.
POST is neither. Submitting a payment twice charges twice unless the server takes specific care. That's why browsers warn before resubmitting a POSTed form.
3. Caching
GET responses are cacheable by default. Browsers, CDNs, and intermediate proxies can store and reuse them. That's a huge performance benefit.
POST responses are usually not cached. The whole point of POST is something changing, so caching the response would be misleading.
4. Where data goes
GET parameters go in the URL query string (?q=cats&page=2). They're visible, bookmarkable, and shareable.
POST parameters go in the body. They're not visible in the URL, not in browser history, and not shared by accident.
5. When the choice goes wrong
Putting a state-changing action behind a GET is a classic web bug. A web crawler hits the link /delete?id=42 and deletes a row. That's why GET should not change state.
Putting a search query behind a POST defeats caching, kills bookmarking, and confuses the back button. Search is GET, every time.
6. Idempotent doesn't mean read-only
GET is the canonical safe method, but other methods (PUT, DELETE) are also idempotent — the property is about retrying.
POST's non-idempotence is what makes it the right tool for "create new thing" — calling it again creates a second thing.
When to Choose Each
Choose GET if:
- Loading any page, image, JSON file, API resource you're reading.
- Search forms — URL is the obvious place for the query.
- Anything you want to bookmark or share.
- Resources you want browsers and CDNs to cache.
Choose POST if:
- Creating something — sign-ups, posts, comments, orders.
- Logging in — credentials don't belong in a URL.
- Sending a body of data, especially structured JSON.
- Anywhere you don't want the request resaved by browsers, caches, or logs.
Worked example
A search bar on a website uses GET because the URL captures the query — you can bookmark /search?q=docker, share it, and let CDNs cache the response. A login form uses POST because the username and password don't belong in the URL or browser history. Both decisions look obvious in hindsight; both have been gotten wrong in real systems.
Common Mistakes
- "POST is more secure." POST hides parameters from the URL but the body is just as readable as a GET to anyone who can see the request. HTTPS is what makes either secure in transit.
- "GET has a hard length limit." No formal limit, but browsers and servers commonly cap URLs around 2 KB. Long requests should use POST.
- "Use POST for everything to be safe." Doing so kills caching, bookmarking, and many useful HTTP semantics. Use the right method.
- "Side-effects are okay in GET if they're small." They're not. Crawlers, prefetchers, and back-buttons will trigger them at the worst times.