HTML Status Codes: Meanings and Troubleshooting

HTML status codes are HTTP response status codes that show what happened when a browser or another tool requested an HTML page. Check the response code, identify its category, and use the specific code to choose the next troubleshooting step.

What do HTML status codes mean?

The phrase “HTML status codes” commonly refers to HTTP response status codes returned by a web server. HTML is the language used to structure many web pages; HTTP is the protocol that carries the request and response.

A status code has three digits. It reports whether the request is continuing, succeeded, led somewhere else, failed because of the request, or failed because the server could not complete it.

The code describes the HTTP response, not necessarily what appears on the screen. A server can return an error code with a helpful HTML page, an empty response, or content that looks normal.

What are the five HTTP status code categories?

• 100–199, informational: The server received the request and the exchange is continuing. Visitors rarely see these codes directly.
• 200–299, successful: The server accepted and successfully handled the request.
• 300–399, redirection: The browser may need to use another location or rely on a cached copy.
• 400–499, client error: The server reports a problem associated with the request, credentials, permissions, rate, or requested location.
• 500–599, server error: The server or an upstream system could not complete an otherwise valid request.

The category narrows the cause, but the complete three-digit code provides the useful meaning.

What do common status codes for HTML pages mean?

• 200 OK: The request succeeded. A 200 response can still contain incorrect or incomplete page content, so it does not prove that every page feature works.
• 301 Moved Permanently: The requested resource has a new permanent location. Browsers and search systems may remember the change.
• 302 Found: The resource is temporarily available at another location. The original address may remain the one used later.
• 304 Not Modified: The browser’s cached copy is still current. The response normally does not include a new copy of the page body.
• 400 Bad Request: The server could not understand or accept the request, often because its syntax, headers, or submitted data are invalid.
• 401 Unauthorized: Authentication is required or the supplied credentials were not accepted.
• 403 Forbidden: The server understood the request but refuses access. Signing in may not help if the account or network lacks permission.
• 404 Not Found: The server cannot find the requested resource at that location.
• 429 Too Many Requests: Too many requests arrived within the server’s allowed period. The response may indicate when to try again.
• 500 Internal Server Error: An unexpected server-side condition prevented completion.
• 502 Bad Gateway: A gateway or proxy received an invalid response from an upstream server.
• 503 Service Unavailable: The service is temporarily unable to handle the request, possibly because of maintenance or overload.
• 504 Gateway Timeout: A gateway or proxy waited too long for an upstream server.

How do you check an HTML page’s status?

Browser developer tools show the response used for the page you opened, including redirects and requests made after the initial document loaded.

1. Open the page in a desktop browser.
2. Open the browser’s developer tools and select the Network panel.
3. Reload the page while the Network panel is recording.
4. Select the request whose type is Document or whose name matches the page.
5. Read the Status or Status Code field in the request details.
6. If redirects occurred, inspect each document request in sequence instead of looking only at the final page.

From a command line, enter curl followed by a space, a capital -I option, another space, and the page address. The -I option requests response headers, which normally include a line beginning with HTTP and the status code. Some servers respond differently to a header-only request, so use a normal browser request when the result seems inconsistent.

What should you do when an HTML page fails?

Visitors should respond to the reported status code without assuming that every failure has the same cause.

1. For 400, check the address and remove malformed or unexpectedly long query information.
2. For 401, sign in again using the expected account and retry the page.
3. For 403, confirm that the account has permission. Contact the site owner if access should be allowed.
4. For 404, check spelling, return to the site’s main navigation, or search for the page by title.
5. For 429, stop repeated refreshes and wait before trying again.
6. For 500, 502, 503, or 504, retry later. If only one device fails, also test another browser or network.

Site administrators should preserve the failing address, time, method, status code, and request identifier before changing the system.

1. Confirm the code with developer tools and server-side logs.
2. For 400-series errors, inspect routing, authentication, permissions, request limits, and recently changed rules.
3. For 500, inspect application errors and recent deployments.
4. For 502 or 504, check proxy settings, upstream health, name resolution, and timeouts.
5. For 503, check capacity, maintenance settings, dependencies, and any retry guidance sent in the response.
6. After correcting the cause, test both the original request and related redirects.

How are status codes, error pages, and redirects different?

An HTTP status code is metadata sent by the server. An HTML error page is visible content that explains a failure, while a redirect tells the browser to request another location.

The visible page alone is not reliable evidence of status. A custom “not found” message may incorrectly return 200, sometimes called a soft 404. A 404 response may also display a polished page that looks like normal site navigation.

After a redirect, the address bar usually shows the destination, while developer tools preserve the earlier 301 or 302 response and the later destination response. To understand status HTML behavior accurately, inspect the full request chain and record both the original code and the final code.