HTTP Status Codes Explained — The Full List (1xx to 5xx)

Every time your browser, a script, or a mobile app talks to a web server, the server replies with a three-digit number: the HTTP status code. That number tells you what happened with the request — was it successful, did the page move, is the server on fire. Knowing what each code means is one of those small pieces of knowledge that pays for itself constantly.

This guide is the practical reference: the codes you actually see, what they mean, and what to do about them. For a searchable list of every code, the Uttir HTTP Status Code Lookup lets you filter by category and find the one you need in under a second.

The shape of the system

All status codes are three digits. The first digit tells you the category, the second and third digits add specificity. Five categories:

• 1xx — Informational — the server is still working on it, expect more soon
• 2xx — Success — the request worked, here is the result
• 3xx — Redirection — the resource moved, go look there instead
• 4xx — Client error — you (the client) did something wrong
• 5xx — Server error — the server messed up, not your fault

You will spend 95% of your time on 2xx, 3xx, 4xx, and 5xx. 1xx exists but most people never see it in the wild.

2xx — Success

The request worked. The body of the response has what you asked for.

200 OK

The default "everything worked" code. The body has the data you asked for. This is the right response for a successful GET on a page or a successful POST that returns the created resource.

201 Created

The request created a new resource. The right response for a successful POST on a collection (creating a new user, creating a new order, etc.). The response usually includes a Location header with the URL of the new resource.

204 No Content

The request worked, but there is no body to return. The right response for a DELETE that succeeded, or a form submission that redirects to a new page. If your endpoint always returns 200 with an empty body, switch to 204 — it makes the API clearer.

206 Partial Content

The server is sending you a portion of a larger file. Used for range requests (download managers, video streaming, resumable downloads). You will not see this unless you are building or debugging one of those features.

3xx — Redirection

The resource is not at the URL you asked for. Go look at the URL in the Location header instead.

301 Moved Permanently

The resource is permanently at a new URL. The browser will cache this and never ask the old URL again. The right response when you change a URL for SEO reasons (consolidating duplicate content, moving to a new domain, switching to HTTPS). The new URL is in the Location header.

Most static site generators, including the one this site uses, return 301 for every URL change. The URL encoder is the right tool if you need to safely put a URL inside another URL or in a query string.

302 Found

Temporary redirect. The browser will follow the redirect but still try the original URL next time. The right response when the redirect is conditional (e.g. "send logged-in users to their dashboard, send anonymous users to the login page").

303 See Other

Like 302, but explicitly for the case where the response to the new URL should always be a GET, even if the original request was a POST. Used after a form submission that should not be re-submitted if the user refreshes.

304 Not Modified

The resource has not changed since the last time you asked. The browser's cache is still valid, use that. This is how HTTP caching works. If you are building an API and you see lots of 304s, that is a good sign — it means caching is working.

307 Temporary Redirect / 308 Permanent Redirect

Same as 302 and 301, but with the explicit guarantee that the method and body of the request will not be changed. 308 is increasingly preferred over 301 for the same reason: clients can trust the semantics. Modern best practice is 308 for permanent, 307 for temporary.

4xx — Client error

You sent a request the server cannot or will not fulfill. The fix is on your side (or the user's).

400 Bad Request

The server cannot parse the request at all — usually malformed JSON, missing required fields, or a bad URL. The most common cause in APIs is a client sending invalid JSON. Use the JSON Validator on the request body to find the syntax error.

401 Unauthorized

Authentication is required, and you did not provide it (or the credentials were invalid). The right response when the request needs to be authenticated but no auth header (or a bad one) was sent. Despite the name, "Unauthorized" really means "Unauthenticated" in HTTP.

403 Forbidden

You are authenticated, but you are not allowed to do this. The right response when the user is logged in but lacks the required role or permission. The distinction from 401: 403 means "I know who you are and the answer is still no".

404 Not Found

The resource does not exist at this URL. The most well-known status code. The right response when the path is valid but no resource matches. A custom 404 page is the standard fix for a good user experience.

405 Method Not Allowed

You sent a method (GET, POST, etc.) that the server does not support for this URL. The right response when a server only allows GET on a path and the client sent POST. The Allow header lists the methods that are allowed.

408 Request Timeout

The server gave up waiting for the rest of the request. The right response when the client takes too long to send the body. Usually indicates a network problem or a misbehaving client.

409 Conflict

The request would put the resource in an inconsistent state. The right response when trying to create a user with an email that already exists, or updating a resource with stale data.

410 Gone

The resource used to be here but is permanently gone. Unlike 404, the server knows it was deleted (it is in the database, just marked deleted). Used for content moderation, expired job postings, and intentionally removed pages.

413 Payload Too Large / 414 URI Too Long / 431 Request Header Fields Too Large

The request exceeded a size limit. The right response for file uploads over the limit, URLs over the limit, or headers over the limit. These are usually server configuration issues, not user errors.

415 Unsupported Media Type

You sent a content type the server does not know how to handle. The right response when an API expects application/json and the client sent text/plain.

418 I'm a Teapot

An April Fools' RFC from 1998. Real code, real spec, never use it in production. If you see it in a server response, the developer is signaling "I am being playful".

422 Unprocessable Entity

The request was syntactically valid, but the server cannot process it. The right response for "the JSON parses fine but the values are wrong" — e.g. an email field that does not look like an email, or a date in the past when the API only accepts future dates.

429 Too Many Requests

You are being rate-limited. The right response when the client has made too many requests in a window. The Retry-After header tells the client how long to wait. This is the response you get from most public APIs when you exceed your quota.

5xx — Server error

The request reached the server, but the server could not fulfill it. The fix is on the server side. These are the codes you page someone about.

500 Internal Server Error

Generic "something blew up on the server". The right response when the server hits an unhandled exception. If you see 500s in production, the next step is to look at the server logs to find the actual exception. Almost every framework has a way to capture these (Sentry, Rollbar, etc.) and notify you automatically.

501 Not Implemented

The server does not support the feature the request requires. The right response when a server is configured for a feature it does not have (e.g. WebDAV is not enabled but the client tried to use a WebDAV method).

502 Bad Gateway

The server is a proxy or gateway, and the upstream it was talking to gave a bad response. The right response when a CDN cannot reach the origin, or a reverse proxy is in front of a service that crashed. The first place to look is the upstream service.

503 Service Unavailable

The server is temporarily down or overloaded. The right response for planned maintenance or when the server has hit its capacity. The Retry-After header tells the client when to try again. This is the right response for "we are deploying, try in 5 minutes" — not 500.

504 Gateway Timeout

The server is a proxy or gateway, and the upstream did not respond in time. The right response when an upstream service is slow or hung. The first place to look is the upstream service.

507 Insufficient Storage

The server has run out of disk space (for WebDAV). Rarely seen in regular web traffic.

Status codes you will never see

A few codes are reserved or part of obscure extensions. You will not see them in normal traffic, but they are in the spec:

• 103 Early Hints — server hints about resources the client will need (used by some CDNs)
• 421 Misdirected Request — TLS handshake issue
• 425 Too Early — anti-replay protection, used in some security-focused setups

If you see one of these in a real-world scenario, the server is doing something unusual and the spec is the right reference.

Picking the right code is its own skill

Most APIs and sites get status codes wrong in subtle ways. The common mistakes:

• Returning 200 for everything, with an error in the body. Easy to build, but you lose all the benefits of HTTP semantics. Clients cannot retry on 5xx, cannot cache 304s, and cannot show "not found" pages on 404s without parsing the body.
• Using 403 when they mean 401. 403 means "I know who you are, the answer is no". 401 means "I do not know who you are". The right code for "you need to log in" is 401.
• Using 500 for validation errors. 500 means "the server is broken". 400 or 422 means "you sent something I cannot accept". A bad email is not a server error.
• Using 404 for "you are not allowed to see this". Leaks the existence of the resource. 403 is the right code if the user is logged in but lacks permission.

Common questions

What is the difference between 401 and 403?

401: I do not know who you are, prove it. 403: I know who you are, and the answer is no. The common mistake is using 403 for "you need to log in" — that is a 401.

What is the difference between 500 and 503?

500 is unhandled error — something unexpected broke. 503 is planned unavailability — the server is temporarily down for maintenance or capacity. Use 503 with Retry-After for planned downtime, not 500.

Should I use 301 or 308 for permanent redirects?

308 preserves the HTTP method and body, 301 may change POST to GET (theoretically — in practice, most clients preserve the method). 308 is the right modern choice. The URL encoder is the right tool if you need to safely put a URL with query params inside another URL.

Why is my API returning 200 with an error in the body?

Because someone decided to do that. It is a common shortcut, and it works, but it loses the standard HTTP semantics. If you are debugging, look in the body for the actual error code. If you are designing the API, switch to the right HTTP status code — clients can then use standard tools to handle 4xx and 5xx without parsing your custom format.

Bottom line

HTTP status codes are the universal contract between client and server. The five categories — 1xx informational, 2xx success, 3xx redirect, 4xx client error, 5xx server error — cover everything. The Uttir HTTP Status Code Lookup is a searchable reference for every code, with the description and the recommended action for each. Bookmark it.