HTTP Status Code Reference

HTTP Status Codes Explained: What Your Browser Is Actually Telling You

When Tim Berners-Lee invented the HyperText Transfer Protocol (HTTP) in 1991, the very first version — HTTP/0.9 — had just a single implicit success state: if you got a response, it worked. There was no structured way to communicate failure. That changed rapidly. By 1996, HTTP/1.0 formalised the three-digit status code system, and RFC 7231 — the modern standard that governs HTTP/1.1 — defines the complete registry of status codes still in use today across HTTP/2 and HTTP/3.

Every time your browser loads a page, fetches an image, or your mobile app calls an API, the server responds with a three-digit status code. This code tells the client exactly what happened: did the request succeed, was the resource moved, is authentication required, or did something go wrong on the server side? The three digits are not arbitrary — the first digit defines the category (1xx informational, 2xx success, 3xx redirection, 4xx client error, 5xx server error), while the remaining two digits specify the exact condition within that category.

Understanding status codes is not just academic. Every developer building REST APIs, every frontend engineer debugging a failed request in Chrome DevTools, and every DevOps engineer monitoring a production system needs to read status codes fluently. In Chrome, open DevTools, click the Network tab, and reload any page — every single request shows its status code in the Status column. A green 200 means success; amber 3xx codes are redirects; red 4xx and 5xx codes are errors that need investigation.

ASEAN's fastest-growing tech companies — Grab, Shopee, Sea Group, GoTo, and dozens of Singapore-based fintech firms — publish extensive API documentation that relies on HTTP status codes to communicate success and failure to integration partners. Shopee's Open Platform returns 200 for success, 400 for bad parameters, 429 when rate limits are hit, and 500 for server-side issues. Understanding these codes is table stakes for any developer building on ASEAN digital infrastructure.

The Difference Between 401 and 403, 301 and 302 — and Why It Matters

Two of the most commonly confused pairs of status codes are 401 vs 403 and 301 vs 302. Getting them wrong has real consequences — for API security, user experience, and SEO.

401 Unauthorized vs 403 Forbidden: Despite the name "Unauthorized", 401 actually means unauthenticated — the client has not provided credentials, has provided invalid credentials, or the credentials have expired. The server is saying: "I don't know who you are." A 403 Forbidden, by contrast, means the server knows exactly who the client is but refuses to grant access to that specific resource. The client is authenticated but not authorised. In practice: a request with no JWT token should return 401; a request with a valid JWT but insufficient permissions should return 403. Mixing these up causes confusion for API consumers and can expose information about resource existence. Singapore's GovTech API standards, which govern all Singapore government API integrations, explicitly require correct use of 401 and 403 to prevent information leakage.

301 Moved Permanently vs 302 Found: The 301 is the workhorse of web migrations. When you move from HTTP to HTTPS, change domain names, or restructure URLs, a 301 tells every browser and every search engine crawler that the resource has permanently moved. Browsers cache 301 responses — the next visit goes directly to the new URL without even checking the old one. Search engines, including Google, transfer PageRank (link equity) from the old URL to the new one.

A 302, in contrast, is temporary. Browsers do not cache it; they check the original URL every time. Search engines do not transfer ranking signals for 302 redirects — they keep the original URL in their index. Use 302 for genuine temporary scenarios: A/B testing, maintenance pages, seasonal redirects. Use 301 for permanent URL changes. The wrong choice is one of the most common technical SEO mistakes in website migrations.

Reading API Errors Like a Developer: A Practical Guide for ASEAN Dev Teams

For backend engineers and API consumers, the distinction between similar codes often determines how your code handles errors. Take 400 Bad Request vs 422 Unprocessable Entity: a 400 means the request is structurally broken — malformed JSON, invalid URL encoding, or headers the server cannot parse. A 422 means the request was parsed successfully, but the data inside it failed validation — an email field containing "not an email", a required field that is missing, or a value outside an acceptable range. Good API design returns 422 with a structured list of field-level validation errors, not a generic 400. Laravel's built-in form request validation returns 422 automatically with a JSON error body listing every failed field.

The 429 Too Many Requests has become one of the most commonly encountered status codes for ASEAN developers. Every major API gateway — from AWS API Gateway to Grab's developer platform to Singapore's MyInfo API — implements rate limiting. When you hit a 429, the correct response in your code is exponential backoff: wait before retrying, and double the wait time with each subsequent attempt. Always check the Retry-After response header, which tells you exactly how many seconds to wait. Hard-coding a fixed retry delay is an anti-pattern; it can make rate limiting worse by creating synchronised retry storms.

In load-balanced, microservices-based environments — the architecture used by Shopee, Lazada, and Tokopedia to handle millions of concurrent transactions during 11.11 (Singles' Day) peak traffic — 502 Bad Gateway and 503 Service Unavailable are the most significant operational codes. A 502 means the reverse proxy (nginx, AWS CloudFront, Cloudflare) received an invalid response from the application server behind it — typically because an application instance crashed or returned a non-HTTP response. A 503 means the server is intentionally refusing traffic — it is overloaded or in maintenance mode. Correctly instrumenting your load balancer to return 503 with a Retry-After header during planned maintenance is a mark of production-ready engineering.

For teams building their own APIs, the discipline of returning the correct status code — rather than always returning 200 with an error field in the body — dramatically improves the experience of API consumers. Tools like Postman and Insomnia, used across ASEAN development teams for API testing, display status codes prominently and trigger different test assertions based on them. The curl -I command lets you inspect status codes from any terminal without a GUI tool.