The HTTP POST Method

GET is a question. POST is an action.

That's the entire distinction. When you click a link, your browser asks "what's at this URL?" When you submit a form, your browser says "here's data—do something with it." Every login, every upload, every checkout, every API call that creates or changes something: POST.

What POST Does

POST submits data to a server, typically causing a change in state or triggering side effects. The server receives your data and does something with it—creates a user account, processes a payment, stores a file, sends an email.

Common POST operations:

• Submitting login and registration forms
• Creating new resources (posts, orders, accounts)
• Uploading files
• Sending data to APIs
• Processing payments

The key word is processing. GET retrieves what exists. POST causes something to happen.

POST Request Structure

A POST request has three parts:

Request Line:

POST /api/users HTTP/1.1

Headers:

Host: example.com
Content-Type: application/json
Content-Length: 87

Request Body:

{
  "username": "johndoe",
  "email": "john@example.com",
  "password": "securepass123"
}

The body is where POST carries its payload. Unlike GET, which squeezes parameters into the URL, POST sends data in the body—allowing larger payloads and keeping sensitive information out of URLs, logs, and browser history.

Content Types

The Content-Type header tells the server how to parse the body.

application/x-www-form-urlencoded — The default for HTML forms:

username=johndoe&email=john%40example.com&password=securepass123

multipart/form-data — Required for file uploads:

------WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Disposition: form-data; name="username"

johndoe
------WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Disposition: form-data; name="avatar"; filename="photo.jpg"
Content-Type: image/jpeg

[binary image data]
------WebKitFormBoundary7MA4YWxkTrZu0gW--

application/json — The standard for modern APIs:

{
  "username": "johndoe",
  "preferences": {
    "theme": "dark",
    "notifications": true
  }
}

POST vs. GET

That last row matters most. GET is safe to repeat—refreshing a search page doesn't create duplicate searches. POST is not safe to repeat—refreshing a checkout page might charge your card twice.

When to Use POST

Use POST when:

• Creating, updating, or deleting resources
• Handling sensitive data (passwords, payment info)
• Sending large payloads or files
• Actions that shouldn't be repeated accidentally

Don't use POST when:

• Simply retrieving data (use GET)
• You want URLs to be shareable or bookmarkable
• The operation is safe to repeat

Form Submissions

<form method="POST" action="/register">
  <input type="text" name="username" />
  <input type="email" name="email" />
  <input type="password" name="password" />
  <button type="submit">Register</button>
</form>

When submitted, the browser sends:

POST /register HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded

username=johndoe&email=john%40example.com&password=securepass123

For file uploads, add enctype="multipart/form-data" to the form tag.

POST in APIs

fetch('https://api.example.com/articles', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    'Authorization': 'Bearer token123'
  },
  body: JSON.stringify({
    title: 'Understanding HTTP POST',
    content: 'POST is used to submit data...',
    tags: ['http', 'tutorial']
  })
});

A successful creation returns:

HTTP/1.1 201 Created
Location: /articles/12345

{
  "id": 12345,
  "title": "Understanding HTTP POST",
  "created_at": "2024-05-15T10:30:00Z"
}

The 201 Created status confirms the resource exists. The Location header tells you where to find it.

Response Codes

The Duplicate Submission Problem

HTTP is stateless. Each request arrives as if it's the first time. The server has no memory of what came before.

This creates a problem: users click "Submit" twice, or the network hiccups and the browser retries. Suddenly you've charged someone's card twice or created duplicate orders.

Solutions:

Post-Redirect-Get: After a successful POST, redirect to a GET:

POST /create-order → 303 See Other → GET /order/12345

Now if users refresh, they refresh the safe GET, not the dangerous POST.

Idempotency keys: The client generates a unique ID for each submission:

fetch('/api/orders', {
  method: 'POST',
  headers: { 'Idempotency-Key': 'unique-key-12345' },
  body: JSON.stringify(orderData)
});

The server ignores duplicate requests with the same key.

CSRF tokens: Embed single-use tokens in forms. Each submission invalidates its token.

Security

Use HTTPS: POST data isn't in the URL, but it's still plain text over HTTP. Encrypt the connection.

Protect against CSRF: Cross-Site Request Forgery tricks browsers into sending unauthorized POSTs. Use CSRF tokens, SameSite cookies, and Origin/Referer header validation.

Validate server-side: Never trust client data. Validate everything.

Rate limit: Prevent abuse by limiting POST frequency.

Limit body size: Prevent memory exhaustion from giant payloads.

Key Takeaways

• POST submits data that causes server-side changes—it's an action, not a question
• Data travels in the request body, keeping it out of URLs, logs, and browser history
• POST is not idempotent: the same request can have different effects each time
• Use Post-Redirect-Get and idempotency keys to prevent duplicate submissions
• Always use HTTPS and CSRF protection for POST endpoints handling sensitive data