What are HTTP status codes?

The server's short answer

Every time a client (browser, mobile app, API consumer) sends an HTTP request, the server sends back a response. The very first thing in that response is a three-digit number called the status code.

This number is the server's quick summary of what happened:

HTTP/1.1 200 OK

The 200 tells the client: "Your request was received, understood, and processed successfully." No need to read the entire response body to know the outcome: the status code gives you the answer immediately.

The five families

HTTP status codes are organized into five categories based on their first digit:

Think of it like a traffic light system:

• 2xx = Green light: everything went well
• 3xx = Yellow light: go somewhere else
• 4xx = Red light for you: you made a mistake
• 5xx = Red light for the server: it broke

Anatomy of a status line

The status code appears in the first line of every HTTP response, called the status line:

HTTP/1.1 200 OK
│         │   │
│         │   └─ Reason phrase (human-readable description)
│         └───── Status code (the three-digit number)
└─────────────── HTTP version

The reason phrase (like "OK", "Not Found", "Created") is just a hint for humans reading raw HTTP traffic. Applications should rely on the numeric code, not the text.

Why status codes matter

For developers

Status codes determine how your application handles responses:

if response.status == 200
  # Show the data to the user
elsif response.status == 404
  # Show "not found" page
elsif response.status == 500
  # Show "something went wrong" page
end

Without status codes, you would have to parse the entire response body to figure out what happened: slow, error-prone, and inconsistent across APIs.

For browsers

Browsers use status codes to make automatic decisions:

• 301 → automatically follow the redirect, and remember it for next time
• 304 → use the cached version instead of downloading again
• 401 with WWW-Authenticate: Basic → prompt the user for a username and password
• 204 → stay on the current page instead of navigating

For search engines

Google and other crawlers use status codes to understand your site:

• 200 → index this page
• 301 → transfer ranking to the new URL
• 404 → remove this page from search results
• 503 → come back later, do not de-index

For infrastructure

Load balancers, CDNs, and monitoring tools all rely on status codes:

• Health checks expect 200 to confirm the server is alive
• CDNs cache responses based on status codes
• Monitoring alerts trigger on 5xx spikes

The most common status codes

You do not need to memorize all status codes (there are over 60). Here are the ones you will encounter most often:

Status codes are a contract

Status codes are part of the API contract between client and server. When a server returns 200 OK, it is making a promise: "The request succeeded and the response body contains what you asked for."

Using the wrong status code breaks this contract:

• Returning 200 with an error message in the body → confuses automated clients
• Returning 500 for a validation error → makes it look like a server bug
• Returning 404 for an unauthorized resource → hides the real problem, unless hiding that it exists is the point (GitHub answers 404 for private repos you can't see)

Choosing the right status code is not pedantic: it is how the web works reliably.

What this course covers

This course focuses on the 2xx Success family. You will learn:

• 200 OK: the default success response
• 201 Created: when a new resource is born
• 204 No Content: success with nothing to return
• 202 Accepted and 206 Partial Content: specialized success codes
• How to choose the right success code for each situation
• How Rails implements these codes

Summary