2xx success status codes

2026-09-04 Updated: 2026-09-05

A 2xx status code means the request was received, understood and accepted: the server did what was asked. The individual codes differ in what came back with that success. A body, a location, nothing at all, or only part of the resource.

What the 2xx family covers

Success is not a single condition. A browser fetching a page, a form posting a new record, a background job accepting work for later and a video player asking for bytes 5,000,000 to 6,000,000 are all successful, but they need different answers. That is what the 2xx codes encode. RFC 9110 defines 200 through 206; a handful of others come from extensions such as WebDAV.

For everyday web traffic, the overwhelming majority of successful responses are plain 200s. The rest matter mostly to API clients, upload paths and media delivery.

The 2xx codes and when each one appears

200 OK. The standard success. For a GET the body is the requested resource; for a POST it is the result of the action. This is what a healthy page returns.
201 Created. The request created a new resource. A well-behaved API returns 201 with a Location header pointing at the thing it just made. You see this in API logs, rarely in a browser.
202 Accepted. The request was accepted for processing but is not finished. Used for asynchronous work such as a bulk import or a report that will be generated in the background. A 202 is a promise, not a result, so the client normally has to poll a status URL.
203 Non-Authoritative Information. Success, but a proxy or transforming intermediary modified the response on the way. Uncommon on modern sites.
204 No Content. Success with deliberately no body. Typical for a DELETE, a PUT that saved without needing to echo anything back, or an autosave endpoint. The browser stays on the current page.
205 Reset Content. Success, and the client should reset the form or document view that sent the request. Rarely used in practice.
206 Partial Content. The server is returning only the byte range the client asked for with a Range header. This is how video seeking, resumable downloads and large-file transfers work, so 206 is normal and expected on media endpoints.
207 Multi-Status and 208 Already Reported come from WebDAV, where one request can act on many resources and needs to report a per-resource outcome. 226 IM Used comes from the delta-encoding extension and is very rarely deployed.

Why a 200 does not prove the page is healthy

A status code describes the outcome of the HTTP transaction, not the correctness of what came back. A branded "we are down for maintenance" page is served with a 200. So is an application error page, when the framework catches the exception and renders a friendly apology through the normal template with its default status. A client-rendered page whose API call failed returns 200 for the empty shell around the missing content, and a soft 404 returns 200 for a "page not found" message, which also confuses search engines.

In every one of those cases a status-code check reports success while your visitors see a broken site. The fix is a content check: assert that a known string is present in the response body, or that a known error string is absent, in addition to checking the code.

How to check what a URL really returns

Ask for headers only and read the status line:
```
curl -sI https://example.com/ | head -n 1
```
If it is a 200, fetch the body too and confirm it contains what it should. Grep for a string that only appears on a working page, such as a heading or a footer marker.
For an API endpoint, verify the code matches the semantics: a create should be 201 with a Location, a delete should be 204, and a long-running job should be 202 with a status URL.
For media, confirm the server advertises Accept-Ranges: bytes and answers a ranged request with 206. If it answers 200 to a ranged request, seeking will be slow because the whole file is resent.
Repeat the check from a different network. A response that is 200 for you and an error elsewhere points at DNS, CDN or geographic routing rather than at the application.

Checking the body, not only the code

A status-code check will report a green site that is serving an error page, so pair it with a content assertion on the same request. HostTracker has been monitoring websites since 2004 and offers 13 monitor types, so one URL can be watched for its status code, for a keyword in the response and for response time at once. Run a URL through the HTTP check tool to see the code and headers it returns right now, then read what a 200 OK really means and the 5xx server error codes for the failures a 200 can mask.