HTTP status codes explained: 200, 301, 404, 429, 500 and more

Every time your browser, an app or a script talks to a web server, the server answers with a three-digit HTTP status code. Most of the time you never see it, because the page simply loads. But when something goes wrong, the code is the fastest clue to what happened and who needs to fix it: you, the website, or something in between.

This guide explains how status codes are grouped, what the codes you will actually meet mean, and how to troubleshoot them as a visitor, a site owner or a developer calling an API.

How to read a status code

The first digit tells you the class of the response:

• 1xx – informational. The request was received and processing continues. Rarely visible.
• 2xx – success. The request worked.
• 3xx – redirection. The resource is somewhere else, or the cached copy is still valid.
• 4xx – client error. Something about the request is wrong: the address, the login, the permissions or the data sent.
• 5xx – server error. The request may be fine, but the server or a gateway in front of it failed.

A useful rule of thumb: with a 4xx code, change the request before trying again; with a 5xx code, the same request may work later.

You can see the code yourself

In Chrome, Edge or Firefox press F12, open the Network tab and reload the page. The Status column shows the code for the page and every image, script and API call. From a terminal you can ask for headers only:

curl -I https://versuss.space/
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8

Add -L to follow redirects and see each hop, which is handy when a page bounces between addresses.

2xx: success codes

• 200 OK – the normal answer for a page or a successful API read.
• 201 Created – a POST created something new; the response often includes its address in the Location header.
• 204 No Content – success with nothing to return, common after a DELETE or a settings update.
• 206 Partial Content – only part of a file was sent, used for video streaming and resumable downloads.

3xx: redirects and caching

• 301 Moved Permanently – the address changed for good. Browsers remember it and search engines move rankings to the new URL. Use it when you rename a page or move from http:// to https://.
• 302 Found and 307 Temporary Redirect – a temporary move, for example to a login page. Search engines keep the original address.
• 308 Permanent Redirect – like 301, but the client must repeat the same method and body, which matters for API POST requests.
• 304 Not Modified – the browser asked “has this changed since my cached copy?” and the server said no. This is a good thing: nothing is downloaded again. It is the heart of how browser cache works.

Redirect loops. If the browser reports “too many redirects”, two rules are sending visitors back and forth, typically an HTTPS rule on the server fighting a different rule in the CMS or a proxy. Clearing cookies sometimes helps visitors, but the real fix is on the site.

4xx: problems with the request

• 400 Bad Request – the server could not understand the request: malformed JSON, a broken query string, or an oversized cookie. For visitors, clearing cookies for that site often fixes a 400 that appears suddenly.
• 401 Unauthorized – you are not authenticated. The login, token or API key is missing, expired or wrong. See API keys vs OAuth.
• 403 Forbidden – the server knows who you are (or does not care) and still refuses. Typical causes: missing permissions, IP or country blocking, a firewall rule, or wrong file permissions on the server.
• 404 Not Found – nothing exists at that address. Check spelling; if a link on a site leads to a 404, the site owner should fix the link or add a redirect.
• 405 Method Not Allowed – the address exists, but not for that method, for example sending POST to a read-only endpoint. See REST API methods.
• 408 Request Timeout – the client took too long to send the request, often a slow or unstable connection.
• 409 Conflict – the request clashes with the current state, such as creating a user that already exists or saving an outdated version.
• 410 Gone – the resource was removed on purpose and will not come back. Search engines drop 410 pages faster than 404 pages, so it is the right answer for deleted content.
• 413 Payload Too Large – an upload exceeds the server limit.
• 415 Unsupported Media Type – the body is in a format the endpoint does not accept, often a missing Content-Type: application/json header.
• 422 Unprocessable Content – the format is fine but the data fails validation, for example an invalid email address.
• 429 Too Many Requests – you hit a rate limit. Wait for the time in the Retry-After header and slow down. More in API rate limits explained.

5xx: problems on the server side

• 500 Internal Server Error – a generic crash in the application: a code error, a broken plugin, a full disk or a database problem. The server error log contains the real reason.
• 502 Bad Gateway – a proxy, load balancer or CDN reached the application behind it and received an invalid answer, usually because the application crashed or restarted.
• 503 Service Unavailable – the server is overloaded or in maintenance. Well-behaved services add Retry-After.
• 504 Gateway Timeout – the proxy waited too long for the application. Slow database queries and long-running scripts are common causes.

As a visitor you cannot fix a 5xx error. Reload after a minute, check whether the service has a status page, and try again later. As a site owner, start with the error log and with whatever changed most recently: an update, a new plugin, a configuration edit.

Status codes and search engines

Search engines read status codes literally. A 200 page can be indexed; a 301 passes the page’s signals to the new address; 404 and 410 pages are eventually removed; repeated 5xx errors make crawlers slow down and can temporarily drop pages. Two mistakes are especially common:

• Soft 404 – a page says “not found” but returns 200. Search engines treat it as low-quality duplicate content. Missing pages should return a real 404 or 410.
• Redirect chains – http://www → https://www → https:// → new URL. Each hop costs time; point old addresses directly to the final one.

Handling status codes in your own code

When you call an API, do not assume success. A simple and safe pattern:

const res = await fetch(url, { headers: { Accept: 'application/json' } });
if (res.status === 429 || res.status >= 500) {
  // temporary: wait and retry with exponential backoff
} else if (!res.ok) {
  // 4xx: log the body, fix the request, do not retry blindly
  throw new Error(`HTTP ${res.status}: ${await res.text()}`);
}
const data = await res.json();

Retry only temporary failures (429, 502, 503, 504 and network errors), add a growing delay between attempts, and cap the number of retries. Retrying a 400 or 401 just repeats the same mistake faster.

Quick troubleshooting table

• 401 / 403 – check login, token, permissions and IP restrictions.
• 404 – check the URL; owners should add a 301 if the page moved.
• 429 – slow down and respect Retry-After.
• 500 – read the server error log.
• 502 / 504 – check that the application behind the proxy is running and fast enough.
• Too many redirects – look for two rules redirecting in opposite directions.

Key takeaways

• The first digit tells you where the problem is: 4xx on the request side, 5xx on the server side.
• Use 301 for permanent moves and 410 for content removed for good.
• Retry only temporary errors, with backoff; fix the request for other 4xx codes.
• The browser’s Network tab and curl -I show the real code in seconds.