HTTP Status Codes Explained: What 200, 301, 404 and 500 Actually Mean

CodexFuse Team · 2026-11-04T10:52:11.805Z · 13 min read min read

Every code meaning quoted from RFC 9110, every capture run live this run: what 200, 301, 302, 404, 500 and 9 more codes mean — plus 301 vs 302 and 401 vs 403 disambiguated.

HTTP status codes explained in one sentence: every time your browser asks a server for something, the server answers with a three-digit code that says whether the request worked, moved, or broke — and learning to read those codes is the fastest way to debug the web. This guide covers the 14 codes you will actually meet, and every one below is backed by a live curl -i capture run this morning: a real 200 from codexfuse.dev, the site's real http-to-https 301, and the full 4xx/5xx family from a test endpoint. If you are new to how to use curl, that guide is the perfect companion piece; here we use curl as a microscope for the web's response language. Every meaning is quoted from the specification it comes from — RFC 9110, the IETF's "HTTP Semantics" (June 2022) — and every capture was produced at write time, never copied from another guide.

What is an HTTP status code?

An HTTP status code is the three-digit number a server sends back with every HTTP response, telling the client — your browser, your app, or Googlebot — how the request went. 200 means it worked, 404 means nothing exists there, 500 means the server broke while trying.

The first digit is the entire classification system: it names the class, and RFC 9110 defines five of them (all confirmed registered in the IANA registry):

One naming quirk, said once: the words after the code ("OK", "Not Found") are only recommendations — RFC 9110's exact line is that they "can be replaced by local equivalents or left out altogether without affecting the protocol." Clients, browsers and tools must decide on the number, never the words.

How do you check a status code with curl?

You check it with curl -i, which prints the response headers before the body — the status line is the first thing the server says, so reading one line tells you everything. The cURL guide covers the tool itself; this section uses it as the test instrument for every code in this article. Run it against this site's homepage and you get:

$ curl -i https://codexfuse.dev/
HTTP/1.1 200 OK
date: Wed, 04 Nov 2026 10:48:27 GMT
content-type: text/html; charset=utf-8
server: cloudflare

The first line, HTTP/1.1 200 OK, is the status line: protocol, code, reason phrase. (On machines behind a corporate proxy you may see an extra HTTP/1.1 200 Connection Established first — that is the tunnel handshake, not the site's answer; the line that matters is the one from the server itself.) The rest of this guide reads the same way: ask, read the first line, then decide what to do.

What do the 2xx success codes mean?

The 2xx class means "the client's request was successfully received, understood, and accepted" (RFC 9110 §15.3) — but three of its members mean subtly different things, and mixing them up is a classic API bug. Here are the three that matter, each with a live capture:

200 OK. RFC 9110 §15.3.1: "The 200 (OK) status code indicates that the request has succeeded." For a GET request it means "here is the thing you asked for" — the everyday success, captured above against this site's homepage.

$ curl -i https://httpbin.org/status/201
HTTP/1.1 201 Created
date: Wed, 04 Nov 2026 10:48:42 GMT

201 Created. §15.3.2: "the request has been fulfilled and has resulted in one or more new resources being created." A good API answers a successful POST with 201 plus a Location header naming the new resource — a 200 for creation is not broken, but it is less precise.

$ curl -i https://httpbin.org/status/204
HTTP/1.1 204 No Content
date: Wed, 04 Nov 2026 10:48:43 GMT

204 No Content. §15.3.5: "the server has successfully fulfilled the request and ... there is no additional content to send." DELETE endpoints use it: the thing is gone and there is nothing to say. Notice the capture has no body at all — that is the point.

301 vs 302 redirects: what is the difference?

301 means "moved permanently — update your records"; 302 means "moved temporarily — keep using the old URL." That one distinction decides whether search engines move a page's standing to the new address, so get it right once and you never debug a redirect chain again.

$ curl -i http://codexfuse.dev/
HTTP/1.1 301 Moved Permanently
date: Wed, 04 Nov 2026 10:48:28 GMT
location: https://codexfuse.dev/

301 Moved Permanently. §15.4.2: "the target resource has been assigned a new permanent URI and any future references to this resource ought to use one of the enclosed URIs." Browsers and crawlers follow the Location header automatically. The capture above is this site's real permanent http-to-https redirect — the canonical 301 example.

$ curl -i https://httpbin.org/absolute-redirect/1
HTTP/1.1 302 Found
date: Wed, 04 Nov 2026 10:48:57 GMT
location: https://httpbin.org/get

302 Found. §15.4.3: "the target resource resides temporarily under a different URI... the client ought to continue to use the target URI for future requests." The redirect might change tomorrow, so nothing should update its records.

SEO note, said once: a 301 is the right tool for a permanent migration because permanent redirects carry ranking signals to the new URL — Google's current docs frame it as a canonicalization signal ("the indexing pipeline uses the redirect as a signal that the redirect target should be canonical") — while a 302 explicitly says "temporary," which can leave a page's standing split between the old and new URLs. The 302 carve-out: use 302 for genuinely temporary moves — maintenance pages, login gates, A/B tests — where you want the old URL to keep its standing.

Two related 3xx codes round out the picture. 304 Not Modified is the web's bandwidth saver: send a conditional request with If-None-Match, and if nothing changed the server answers HTTP/1.1 304 Not Modified with no body, so the browser reuses its cache. 308 Permanent Redirect is 301's stricter sibling: it guarantees the request method and body survive the redirect, which 301 does not promise for POSTs.

$ curl -i -H 'If-None-Match: "abc"' https://httpbin.org/etag/abc
HTTP/1.1 304 Not Modified
date: Wed, 04 Nov 2026 10:48:50 GMT

What is a 404 error?

A 404 error means the server has nothing at the URL you asked for — the web's "nothing here," and the most seen error on the internet. The live capture:

$ curl -i https://httpbin.org/status/404
HTTP/1.1 404 Not Found
date: Wed, 04 Nov 2026 10:48:46 GMT

RFC 9110 §15.5.5 gives 404 a second, security-flavored meaning that most guides skip: "the origin server did not find a current representation for the target resource or is not willing to disclose that one exists." A server can 404 a resource that exists rather than admit it — 404 is as much a privacy answer as a missing-page answer.

One honest platform note: this site (codexfuse.dev) is a single-page app, so an unknown path returns the app shell with a 200 rather than a real 404 — that is why the capture above uses a test endpoint. If you ever audit your own site's 404s, verify the code, not just the page: some stacks return 200 for every path, which silently tells search engines "this page exists."

What do 400, 401 and 403 mean?

400, 401 and 403 are the "you messed up — in three different ways" codes. Each is a different diagnosis, and the fix is different each time.

$ curl -i https://httpbin.org/status/400
HTTP/1.1 400 Bad Request
date: Wed, 04 Nov 2026 10:48:43 GMT

400 Bad Request. §15.5.1: "the server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing)." Malformed JSON in an API call is the classic trigger — the request itself was broken before the server could do anything with it.

$ curl -i https://httpbin.org/status/401
HTTP/1.1 401 Unauthorized
date: Wed, 04 Nov 2026 10:48:44 GMT
www-authenticate: Basic realm="Fake Realm"

401 Unauthorized. §15.5.2: "the request ... lacks valid authentication credentials." Notice the WWW-Authenticate header in the capture — RFC 9110 requires it on a 401, because it tells the client which login method to use. Despite the name, 401 means unauthenticated, not unauthorized — it is the bouncer asking for ID, not refusing entry.

$ curl -i https://httpbin.org/status/403
HTTP/1.1 403 Forbidden
date: Wed, 04 Nov 2026 10:48:45 GMT

403 Forbidden. §15.5.4: "the server understood the request but refuses to fulfill it." 401 vs 403, said once: 401 = "I don't know who you are — log in"; 403 = "I know who you are — the answer is no." Retrying a 403 with the same credentials is pointless by design: the RFC says the client "SHOULD NOT automatically repeat the request with the same credentials," and the reason may have nothing to do with login at all (IP blocks and geo-restrictions are 403s too).

What does 500 Internal Server Error mean?

500 means "the server broke and cannot even describe how" — the generic crash code. The live capture:

$ curl -i https://httpbin.org/status/500
HTTP/1.1 500 Internal Server Error
date: Wed, 04 Nov 2026 10:48:47 GMT

RFC 9110 §15.6.1: "the server encountered an unexpected condition that prevented it from fulfilling the request." As a visitor you can only wait or report it; as the owner, the fix lives in the server logs, never in the browser. Two sibling codes narrow the diagnosis down:

$ curl -i https://httpbin.org/status/502
HTTP/1.1 502 Bad Gateway
date: Wed, 04 Nov 2026 10:48:48 GMT

502 Bad Gateway. §15.6.3: "the server, while acting as a gateway or proxy, received an invalid response from an inbound server." Translation: your reverse proxy — usually Nginx — is up, but the app behind it is down or crashed. Restart the app, not the proxy.

$ curl -i https://httpbin.org/status/503
HTTP/1.1 503 Service Unavailable
date: Wed, 04 Nov 2026 10:48:49 GMT

503 Service Unavailable. §15.6.4: "the server is currently unable to handle the request due to a temporary overload or scheduled maintenance." This is the code to send during deploys and maintenance windows on your VPS — it tells crawlers "come back later" instead of "this page is gone."

What is a 429 Too Many Requests error?

429 means "slow down — you are asking too fast." It is the polite version of a bouncer holding up a hand.

$ curl -i https://httpbin.org/status/429
HTTP/1.1 429 Too Many Requests
date: Wed, 04 Nov 2026 10:48:47 GMT

RFC 6585 §4: "The 429 status code indicates that the user has sent too many requests in a given amount of time ('rate limiting')." APIs are the main place you will meet it. The spec says responses "MAY include a Retry-After header indicating how long to wait before making a new request" — notice the capture above carries none, which is legal but unhelpful. Good APIs send it; good clients honor it instead of hammering harder.

HTTP status code list: every code covered in this guide

The complete reference table — one row per code tested above, all captures live this run:

Want more? The IANA HTTP Status Code Registry is the authoritative, continuously updated list — worth bookmarking over any static blog table. Two entries worth knowing exist beyond the table above: 103 Early Hints (RFC 8297), which lets a server send preliminary headers while it is still thinking, and 418, which the registry lists as "(Unused)" — a reserved April Fools' joke from RFC 2324 that will never be assigned to anything real.

Sources

Every code meaning in this guide is quoted from the specification it comes from, and every capture was run fresh this run (2026-11-04) against codexfuse.dev or httpbin.org's status simulator:

• RFC 9110 "HTTP Semantics" (IETF, June 2022) — the current HTTP specification; every code definition and class wording quoted verbatim.
• RFC 6585 "Additional HTTP Status Codes" (IETF, April 2012) — the 429 definition and the Retry-After guidance.
• IANA HTTP Status Code Registry — confirms all 14 codes are registered; source of the 103 Early Hints and 418 notes.
• Google Search Central, "Redirects and Google Search" — the current wording on permanent vs temporary redirects and canonicalization signals.
• Live captures: codexfuse.dev (the 200 and 301) and httpbin.org (201, 204, 302, 304, 400, 401, 403, 404, 429, 500, 502, 503) — all run 2026-11-04.

Frequently Asked Questions

Do I need to memorize all HTTP status codes?

No. The first digit tells you the class, so the ten codes in the table above plus the first-digit rule cover almost everything you will ever see. New codes still get registered (103 Early Hints is a recent example), so reading the class beats memorizing the list.

Why does 404 say "Not Found" instead of "page deleted"?

Because 404 doubles as a privacy answer: RFC 9110 says a server may return it when it is "not willing to disclose that one exists." Treating every 404 as "the page is gone forever" is the mistake — the resource may exist and simply not be for you.

Should my site return 301 or 302 for a domain move?

301 — a domain move is permanent by definition, and 301 is the permanent code, the one that carries the page's standing to the new address. Reserve 302 for genuinely temporary moves: maintenance pages, login gates, A/B tests.

What is the difference between 401 and 403?

401 means the server doesn't know who you are — log in (it must send a WWW-Authenticate header naming the login method). 403 means it knows who you are and refuses anyway — retrying the same credentials is futile by design.

Can I test these codes myself?

Yes — replace the URL in any command in this guide with https://httpbin.org/status/{code} (for example, curl -i https://httpbin.org/status/418) and read the first line of the response. Every capture in this guide was produced exactly that way.