What's the most common status code?

200 OK by a wide margin — it's the universal success response for GET requests that return data and the default for most other successful operations that produce output. Beyond that, the codes that show up most often are 201 Created when a POST produces a new resource, 204 No Content when a DELETE or PUT succeeds without echoing data, 301 and 302 for redirects, 404 Not Found for missing resources, and 500 Internal Server Error when the backend has trouble. Together those eight cover the vast majority of real API traffic.

When should I use 200 vs 201 vs 204?

200 OK is the right answer when the request succeeded and the response body contains useful data — the common case for GET, and for PUT or DELETE operations that echo back the modified state. 201 Created is the semantically correct response when a POST has produced a new resource, and you should include a Location header pointing to where the new resource lives. 204 No Content fits when the operation succeeded but there's nothing meaningful to send back, like a DELETE that doesn't echo a confirmation or a PUT update that doesn't return the updated entity.

429 Too Many Requests is the standard response when the server is rate limiting the client. The convention is to include a Retry-After header in the response telling the client how long to wait before trying again, either as a number of seconds or as an absolute timestamp. Without that header, clients have to guess and tend to retry too aggressively, which compounds the original problem. Any API with rate limits should be returning 429 with Retry-After rather than something more generic like 503.

What's the difference between 500 and 503?

500 Internal Server Error is the catch-all for unexpected backend failures — the server got a well-formed request but something blew up while processing it. 503 Service Unavailable signals a transient problem that the client should expect to recover from, like a maintenance window, an overloaded backend, or a circuit breaker tripped open. The practical difference matters for client retry logic — 503 implies 'try again in a bit', while 500 implies 'we don't know what happened, retrying might or might not help'. Pair 503 with a Retry-After header when you can.

Are there custom status codes?

Technically the protocol allows them, but inventing new codes is almost always a mistake. Clients, proxies, browsers, and CDNs all behave based on the standard codes — using a non-standard code means none of those layers know how to handle it, which produces strange behavior in production. The right pattern is to pick the closest standard code (the common ones are 400, 401, 403, 404, 409, 422, 429, 500, and 503) and put your specific error details in the response body as JSON. The body is where custom error semantics belong; the status code stays standard.

Is the data sent anywhere?

No. The reference is a static lookup — you type or click a code, and the tool reads from its local catalog and shows you the meaning. There's no request body to send, no analytics on the lookups, and no server-side component for the lookup itself. The only privacy consideration is that the page loads like any other web page.

HTTP Status Code Reference

Searchable HTTP status code reference with descriptions, use cases, and examples. Find any HTTP response code from 1xx to 5xx instantly.

Developer Tools Web & SEO

Instant results

Showing 62 of 62 status codes

About HTTP Status Codes

HTTP status codes are three-digit numbers returned by a server in response to a client request. They indicate whether the request was successful, redirected, resulted in a client error, or caused a server error. Understanding these codes is essential for web development, API design, and debugging network issues.

How to Use HTTP Status Code Reference

Search or browse

Search by the specific code you're looking up (200, 404, 503) or browse by category — informational, success, redirection, client error, server error. Searching by code is faster when you have a number in front of you and want to know what it means; browsing the category lists is more useful when you're picking the right code for a new endpoint and want to see your options.

View code details

Each entry shows the code number, the official short name (OK, Not Found, Service Unavailable), a plain-English description of what the code means, common scenarios where it's the right choice, and related codes that often come up in the same context. The 401-versus-403 distinction and the 500-versus-503 distinction are the two pairs people look up most often.

Use in API design

Pick codes that accurately describe what happened on the server. The HTTP semantics matter — 4xx codes signal client errors that retrying probably won't fix, while 5xx codes signal server-side problems that might recover on retry. Specific codes like 422 for validation errors or 429 for rate limits give clients much clearer signals than always returning a generic 400 or 500.

Document and use

List the codes each endpoint can return in your API documentation, with notes on what each one means in that specific context. The team benefits from a shared understanding of when to reach for 201 versus 204, or when 409 Conflict is more appropriate than 400 Bad Request. Specific codes also make logs and dashboards more diagnostic when something goes wrong in production.

When to Use HTTP Status Code Reference

API development

Choosing the right status code for an API response is one of those small design decisions that has outsized effect on how usable the API feels. 200 for everything works but tells client code nothing; 201 for created resources, 204 for successful deletes, 422 for validation failures all give clients a much better signal. Backend developers designing REST endpoints reference the full taxonomy regularly during the design phase.

Debugging web issues

When a browser shows '500 Internal Server Error' or the network tab is full of 403s, knowing what each code actually means narrows down where the problem lives. The reference saves you from rote memorization and clarifies subtle distinctions like 502 versus 503. Useful for support engineers, developers fielding bug reports, and anyone investigating why a page won't load.

Documentation reference

API documentation is a lot more useful when it spells out which status codes each endpoint can return and what they mean in context. The reference makes it easy to pick the appropriate code for each scenario without inventing new ones or shoehorning multiple meanings onto one code. Technical writers documenting REST APIs lean on this constantly.

Educational/learning

The HTTP standard has hundreds of codes across five classes, but most APIs use only fifteen or twenty of them in practice. The reference helps web developers learn which ones matter, what they mean, and when to reach for them — and it's a useful interview prep resource for the inevitable 'what's the difference between 401 and 403' question.

HTTP Status Code Reference Examples

Common success

Input

200 OK

Output

The standard success response. The request worked and the response body contains the result. Used for GET requests that return data and most other successful operations that produce output.

By far the most common success code. Almost every endpoint that returns data ends up here. For POST creating new resources, 201 is more semantically appropriate; for PUT updates that don't echo the resource back, 204 is cleaner — but 200 is the universal default that nothing breaks on.

Authentication error

Input

401 Unauthorized vs 403 Forbidden

Output

401 means the client didn't authenticate or sent invalid credentials. 403 means the client is authenticated but doesn't have permission for this specific action.

The most-confused pair in the catalog. The mental model worth holding: 401 asks 'who are you?', 403 says 'I know who you are, and you can't do this.' Many APIs blur this — returning 401 for both — but a properly distinguished pair makes client error handling significantly cleaner.

Server error

Input

500 Internal Server Error

Output

Something broke on the server through no fault of the client. The request was well-formed; the backend couldn't process it.

The catch-all for unexpected backend failures. When you can be more specific — 502 for a bad upstream gateway, 503 for an overloaded or under-maintenance service, 504 for a gateway timeout — using the specific code helps clients decide whether to retry. 500 implies 'we don't know what happened, sorry.'

Tips & Best Practices for HTTP Status Code Reference

1.Reach for semantic codes rather than 200-for-everything. 200 with a response body, 201 for newly created resources (with a Location header), 204 for successful deletes that don't echo data — each gives client code a clearer signal about what just happened.
2.Mind the 4xx versus 5xx distinction. 4xx is the client's fault — bad input, missing auth, requesting something that doesn't exist. 5xx is your fault as the API author. The split tells clients whether retrying makes sense and where to direct the bug report.
3.401 means 'who are you' and 403 means 'you can't do this.' If your API conflates them, client error handling either has to inspect the body or guess. Distinguishing them properly is a small effort that pays off in cleaner integrations.
4.404 versus 410 is a smaller but real distinction. 404 means 'not found, maybe later.' 410 means 'this is permanently gone, stop trying.' For deprecated endpoints or removed resources, 410 prevents clients from polling forever.
5.429 Too Many Requests is the standard rate limit response. Always pair it with a Retry-After header so clients know when they can try again. Without that header, clients have to guess and tend to retry too aggressively.
6.Don't return 200 with an error in the body. Some legacy APIs do this and it makes status-code-driven error handling impossible. The status code is part of the response semantics — 2xx for success, 4xx/5xx for errors. Use it correctly and clients can rely on it.

Frequently Asked Questions

They're three-digit numbers that the server includes in every HTTP response to summarize what happened. The first digit identifies the broad category — 1xx for informational responses you rarely see at the application layer, 2xx for success, 3xx for redirection, 4xx for client errors, and 5xx for server errors. The system has been part of HTTP since the original spec in 1991 and is now codified across RFC 7231 and a handful of extension RFCs that add codes for specific scenarios.

HTTP Status Code Reference

About HTTP Status Codes

How to Use HTTP Status Code Reference

Search or browse

View code details

Use in API design

Document and use

When to Use HTTP Status Code Reference

API development

Debugging web issues

Documentation reference

Educational/learning

HTTP Status Code Reference Examples

Common success

Authentication error

Server error

Tips & Best Practices for HTTP Status Code Reference

Frequently Asked Questions

Related Tools

MIME Type Lookup

Robots.txt Generator

Sitemap Generator

.htaccess Generator

User Agent Parser

URL Parser