Every time your browser loads a page, submits a form, or fetches data from an API, the server sends back a three-digit number called an HTTP status code. These codes are the server's way of telling you what happened with your request. Did it work? Did something break? Does the page live somewhere else now?
Understanding these codes is essential for anyone building or maintaining websites. If you are a developer debugging a broken API call, a site owner trying to figure out why Google is not indexing your pages, or an SEO professional tracking down redirect chains, status codes give you the answers. They are the foundation of how the web communicates success, failure, and everything in between.
Status codes are grouped into five categories based on their first digit. The 1xx codes are informational, 2xx means success, 3xx handles redirects, 4xx indicates something went wrong on the client side, and 5xx means the server hit a problem. Each category tells a different part of the story.
This reference covers every standard HTTP status code with plain-language explanations and real-world examples. Whether you are troubleshooting a 502 Bad Gateway from your load balancer or figuring out the difference between a 301 and 308 redirect, you will find what you need here. If you are dealing with redirect issues specifically, try our redirect checker to trace the full redirect chain, or use the bulk redirect checker to test many URLs at once.
The server got the first part of your request and is saying "keep going, send the rest." It is a green light to continue sending the request body.
Use case: A client uploads a large file and first checks if the server will accept it before sending the full payload.
The server agrees to switch to a different protocol that the client requested. Think of it as both sides agreeing to change the language they are speaking.
Use case: A browser upgrades an HTTP connection to a WebSocket connection for real-time chat functionality.
The server received your request and is working on it, but it is not done yet. This prevents the client from timing out while waiting for a complex operation.
Use case: A WebDAV server processes a request that involves copying hundreds of files between directories.
The server sends back some preliminary headers before the final response is ready. It lets the browser start loading resources like stylesheets early.
Use case: A server tells the browser to start downloading CSS and font files while it is still generating the HTML page.
The request worked perfectly. The server found what you asked for and sent it back.
Use case: A user loads your homepage and sees the content successfully.
Your request was successful and the server created a new resource as a result. You will usually get this after a POST request.
Use case: A user signs up for an account and the server creates their new profile in the database.
The server accepted your request but has not finished processing it yet. The work is queued up and will happen in the background.
Use case: You submit a video for processing and the server queues it for encoding while immediately confirming receipt.
The request succeeded, but the response came from a third-party source rather than the original server. The data might be slightly different from what the origin would return.
Use case: A caching proxy returns a modified version of the response with some headers stripped out.
The request was successful but there is nothing to send back. The server did what you asked, it just does not have any content to return.
Use case: A user clicks "Save" on their settings and the server updates them successfully without needing to return any data.
The request was successful and the server wants the client to reset the document view. It is like saying "done, now clear the form."
Use case: After submitting a form, the server tells the browser to clear all the input fields so the user can enter fresh data.
The server is sending only part of the resource because the client asked for a specific range. This is how downloads can be paused and resumed.
Use case: A video player requests only the next 2MB chunk of a movie file instead of downloading the entire thing at once.
The response contains information about multiple resources, each with their own status code. It is a batch response where some items might succeed and others might fail.
Use case: A WebDAV client copies 10 files and gets back a single response showing which copies succeeded and which failed.
The server fulfilled the request and the response represents the result of one or more changes applied to the current version of the resource.
Use case: A server sends only the differences (delta) between the current page and the version the client already has cached.
The server has multiple versions of the requested resource and wants the client to pick one. It is rare in practice but exists for content negotiation.
Use case: A server offers the same document in English, French, and Spanish and asks the browser which language it prefers.
This page has permanently moved to a new URL. Search engines will update their index to the new location.
Use case: You changed your domain from old-site.com to new-site.com and want Google to transfer all rankings.
The resource is temporarily at a different URL. Unlike a 301, search engines will keep the original URL in their index because the move is not permanent.
Use case: You temporarily redirect users to a maintenance page while you deploy updates to your site.
The server is telling you to go look at a different URL using a GET request. It is commonly used after a form submission to prevent duplicate submissions on refresh.
Use case: After a user submits a payment form via POST, the server redirects them to a GET request for the order confirmation page.
The resource has not changed since the last time you requested it. The server is telling your browser to use the cached version instead of downloading it again.
Use case: A browser checks if a CSS file has been updated and the server says "nope, use your cached copy" to save bandwidth.
The requested resource must be accessed through a proxy. This status code is deprecated due to security concerns and most browsers ignore it.
Use case: A corporate network requires all external requests to go through a specific proxy server.
The resource is temporarily at a different URL, and the client should use the same HTTP method for the redirected request. Unlike 302, it guarantees the method won't change.
Use case: An API endpoint temporarily moves to a new server and you need POST requests to stay as POST requests after the redirect.
The resource has permanently moved and the client should use the same HTTP method for future requests. It is like 301 but guarantees the method stays the same.
Use case: An API permanently moves its POST endpoint to a new URL and needs clients to keep sending POST requests to the new location.
The server can not understand your request because something is wrong with how it was formatted. Check your syntax, parameters, or request body.
Use case: An API call sends malformed JSON in the request body and the server can not parse it.
You need to log in or provide valid credentials before you can access this resource. The server does not know who you are.
Use case: A user tries to access their dashboard without including an authentication token in the request.
This code is reserved for future use. Originally intended for digital payment systems, some APIs now use it to indicate a paid feature or expired subscription.
Use case: A SaaS platform returns this when a user tries to access a premium feature without an active subscription.
The server knows who you are but you don't have permission to access this resource. Unlike 401, logging in again won't help.
Use case: A regular user tries to access the admin panel and gets blocked because they don't have admin privileges.
The server can not find the page you are looking for. It might have been deleted or the URL was typed wrong.
Use case: A visitor clicks an old link from another website that points to a page you have since removed.
The HTTP method you used (GET, POST, PUT, etc.) is not supported for this URL. The endpoint exists but does not accept that type of request.
Use case: A client sends a DELETE request to an endpoint that only accepts GET and POST methods.
The server can not produce a response that matches what the client asked for in its Accept headers. It is a content negotiation failure.
Use case: A client requests data in XML format but the API only supports JSON responses.
You need to authenticate with a proxy server before your request can go through. It is similar to 401 but for the proxy rather than the destination server.
Use case: A corporate proxy requires employees to enter their network credentials before accessing external websites.
The server got tired of waiting for your request to arrive. The connection was open too long without the client sending anything.
Use case: A user on a slow mobile connection starts uploading a file but the connection stalls and the server closes it after 30 seconds.
The request conflicts with the current state of the resource. Something changed between when you loaded the data and when you tried to update it.
Use case: Two users edit the same document simultaneously and the second save attempt conflicts with the first.
The resource used to exist here but it has been permanently removed. Unlike 404, this confirms the resource is intentionally gone and won't come back.
Use case: A social media platform permanently deletes a user account and returns 410 for their old profile URL.
The server requires a Content-Length header in the request but you did not include one. It needs to know how much data to expect.
Use case: A file upload endpoint rejects a request because the client did not specify the size of the file being sent.
The server checked the conditions you set in your request headers (like If-Match or If-Unmodified-Since) and they were not met.
Use case: A client tries to update a resource only if it has not changed, but someone else modified it in the meantime.
The data you are trying to send is bigger than the server is willing to accept. You will need to reduce the size or split it into smaller pieces.
Use case: A user tries to upload a 500MB video file to a server that has a 100MB upload limit.
The URL you sent is longer than the server can handle. This usually happens when too much data gets stuffed into query parameters.
Use case: A search form accidentally puts thousands of filter options into the URL query string instead of using a POST body.
The server does not support the format of the data you sent. Check your Content-Type header and make sure you are sending data in an accepted format.
Use case: A client sends form data to an endpoint that only accepts JSON, with the wrong Content-Type header.
You asked for a specific portion of a file that does not exist. The range you requested is outside the bounds of the resource.
Use case: A download manager requests bytes 1000-2000 of a file that is only 500 bytes long.
The server can not meet the requirements specified in the Expect header of your request.
Use case: A client sends an Expect: 100-continue header but the server does not support that expectation.
A playful status code from an April Fools joke RFC. It means the server refuses to brew coffee because it is a teapot. Some developers use it as an Easter egg.
Use case: A developer adds this as a fun response on their API when someone hits an undocumented endpoint.
The request was sent to a server that can not produce a response for it. The connection was reused for a request to a different host or scheme.
Use case: An HTTP/2 connection tries to reuse a connection for a different domain that the server does not handle.
The server understands your request format, but can not process it because the data does not make sense. The syntax is correct but the content has errors.
Use case: A user submits a form with an email field that contains "not-an-email" instead of a valid email address.
The resource you are trying to access or modify is currently locked. Someone else might be editing it, or it has been locked for administrative reasons.
Use case: A user tries to edit a shared document that another team member has checked out for editing.
Your request failed because it depended on another request that also failed. It is a chain reaction where one failure causes another.
Use case: A batch operation tries to move a file after copying it, but the copy step failed so the move can not happen either.
The server is not willing to process this request because it might be a replay attack. It is a security measure for requests sent during TLS early data.
Use case: A server rejects a request sent in TLS 1.3 early data (0-RTT) because it can not verify the request is not being replayed by an attacker.
The server refuses to handle the request using the current protocol and requires the client to switch to a different one.
Use case: A server requires clients to use TLS/HTTPS and rejects plain HTTP connections with instructions to upgrade.
The server requires the request to include conditional headers (like If-Match) to prevent lost updates. It is a safety measure against overwriting changes.
Use case: An API requires clients to include an ETag in update requests to prevent two people from accidentally overwriting each other's changes.
You have sent too many requests in a short period and hit the rate limit. Slow down and try again after the time specified in the Retry-After header.
Use case: A script hammers an API with 1000 requests per minute and gets throttled to protect the server from overload.
The headers in your request are too big for the server to process. This often happens when cookies grow too large.
Use case: A browser accumulates dozens of tracking cookies that make the total header size exceed the server limit.
The server can not provide this resource due to a legal demand. Named after the novel Fahrenheit 451, it means the content is censored or legally restricted.
Use case: A website blocks access to certain content in a specific country due to a government takedown order.
Something went wrong on the server and it can not tell you exactly what. It is the catch-all error when the server crashes or hits an unexpected problem.
Use case: A bug in your application code throws an unhandled exception and the server does not know how to recover.
The server does not support the functionality needed to handle your request. It either does not recognize the HTTP method or can not fulfill it.
Use case: A client sends a PATCH request to a server that has not implemented support for partial updates yet.
The server was acting as a middleman (gateway or proxy) and got an invalid response from the upstream server it was trying to reach.
Use case: Your Nginx reverse proxy tries to connect to your Node.js app server but the app has crashed and is not responding properly.
The server is temporarily unable to handle requests. It might be overloaded, undergoing maintenance, or just needs a moment to recover.
Use case: Your website gets a sudden traffic spike from a viral post and the server can not handle all the concurrent connections.
The server was acting as a gateway or proxy and did not get a response from the upstream server in time. The backend took too long to respond.
Use case: A load balancer waits for a response from your API server, but a complex database query takes longer than the 60-second timeout.
The server does not support the HTTP protocol version used in your request. You might need to downgrade your request to an older HTTP version.
Use case: A client sends an HTTP/3 request to a server that only supports HTTP/1.1 and HTTP/2.
The server has a configuration error in its content negotiation setup. The chosen variant is itself configured to negotiate, creating a circular reference.
Use case: A misconfigured server tries to negotiate content type but the selected variant points back to itself in an endless loop.
The server can not store the data needed to complete your request. It has run out of disk space or hit a storage quota.
Use case: A WebDAV server tries to save an uploaded file but the disk is full and there is nowhere to put it.
The server found an infinite loop while trying to process your request. It stopped to prevent getting stuck forever.
Use case: A WebDAV PROPFIND request encounters a symbolic link loop in the file system that would cause infinite recursion.
The server needs additional extensions to the request before it can fulfill it. The client needs to include more information about what extensions to use.
Use case: A server requires a specific HTTP extension to be declared in the request before it will process it.
You need to authenticate to gain access to the network itself, not just the resource. This is what you see on captive portals like hotel or airport WiFi.
Use case: A user connects to airport WiFi and gets redirected to a login page before they can browse the internet.
Every time your browser requests a page from a server, the server responds with a three-digit number called an HTTP status code. That number tells the browser (and search engines) what happened — did the page load successfully? Did it move somewhere else? Is it gone? Did the server crash?
Understanding these codes is fundamental to web development and SEO. When you see a 301 redirect, a 404 not found, or a 500 server error, you need to know what it means and what to do about it. This reference page covers every standard HTTP status code with plain-English explanations and real-world use cases.
Google's crawler interprets status codes to understand your site structure. The codes you return directly affect how Google indexes your pages:
The wrong status code sends the wrong signal. A page that should return 301 but returns 302 means Google keeps the old URL indexed. A page that should return 404 but returns 200 (a "soft 404") confuses Google about whether the content exists. Getting these right is basic SEO hygiene.
These are provisional responses. The server received your request and is processing it. You rarely see these in practice — they happen behind the scenes. The most notable is 103 Early Hints, which lets the server tell the browser to start loading resources (CSS, fonts) before the full response is ready. It's a performance optimization.
The request worked. 200 OK is the most common — the page loaded successfully. 201 Created means a new resource was created (common in APIs after a POST request). 204 No Content means success but there's nothing to show (used for delete operations). For SEO, 200 is what you want on all your indexable pages.
The page moved and the browser needs to go somewhere else. This is where 301 and 302 redirects live. Also 307 (temporary, preserves HTTP method) and 308 (permanent, preserves HTTP method). Use our redirect checker to trace the full redirect chain for any URL and see every status code along the way.
Something is wrong with the request. 404 Not Found is the most famous — the page doesn't exist. 403 Forbidden means the server refuses to serve it (permissions issue). 410 Gone is like a permanent 404 — it tells Google the page was intentionally removed and won't come back. Use our broken link checker to find all the 404 errors on your site.
The server failed to fulfill a valid request. 500 Internal Server Error is the generic "something broke" response. 502 Bad Gateway means a proxy or load balancer got a bad response from the upstream server. 503 Service Unavailable means the server is temporarily overloaded or under maintenance. These need immediate attention from your development team.
Soft 404s. A page returns 200 OK but shows a "page not found" message. Google sees the 200 and thinks the page has content. Fix this by returning an actual 404 status code when a page doesn't exist.
302 instead of 301. A permanent URL change returns 302 (temporary). Google keeps the old URL indexed and doesn't pass full ranking signals. Switch to 301 for permanent moves. Use our bulk redirect checker to find all 302s that should be 301s.
Redirect chains. URL A → 301 → URL B → 301 → URL C. Each hop adds latency and can dilute link equity. Shorten chains to a single hop. Our redirect checker shows you the full chain for any URL.
5xx errors during crawling. If Googlebot hits 500 errors frequently, it reduces crawl rate for your site. Monitor your server logs and fix 5xx errors immediately. A 503 with a Retry-After header is acceptable for planned maintenance.
HTTP status codes are the language servers use to communicate with browsers and search engines. Understanding them helps you diagnose problems, configure redirects correctly, and keep your site healthy in Google's eyes. Use the reference above to look up any code, and test your own URLs with our redirect checker to see what status codes your pages actually return.