HTTP status codes

THE PRACTICAL GUIDE · NORMANDIN SYSTEMS

Get more from HTTP status codes

HTTP Status Codes is a reference for response status numbers, names, and their general meanings. The first digit identifies a response class: informational, successful, redirection, client-error, or server-error. The precise cause of a response still depends on the request, server behavior, intermediary services, and application logs rather than the numeric code alone. A cheatsheet works best as a memory aid while you practice a concrete task. Read the command or syntax together with its arguments, placeholders, and surrounding context. Similar-looking options can have very different meanings, and an example written for one platform or version may need adjustment elsewhere. Keep the reference beside a small test case, use read-only examples first when possible, and check the relevant help output before applying an unfamiliar command to valuable files or a running service.

Guide updated October 13, 2026

How to use this tool

1. Identify the operation you want to perform and find the matching section of the reference. Read the whole example before copying any part of it.
2. Find the reported status code, read its description, and compare it with the request method and response headers.
3. Review the example below and compare its expected behavior with a small sample of your own input before continuing.
4. Try the adapted example on a small test case, compare the result with the explanation, and save the command with a note about the context in which it works.

SEE IT IN PRACTICE

A worked example

404 Not Found

A reference explanation that the requested resource was not found

A 404 describes the response outcome; it does not by itself tell you whether the URL is misspelled, the resource was removed, or routing is misconfigured.

Response classes guide the first investigation

The first digit groups responses into informational, successful, redirection, client-error, or server-error classes. That grouping helps orient troubleshooting, but the individual response and its context matter. A redirect requires examining Location and method behavior, while an authentication-related response may require relevant headers and application state. A successful status can still carry an application-level error payload in some systems, so inspect the body as well as the number. The reference is a vocabulary aid for interpreting the actual exchange.

The same code can have different causes

A 404 can come from a misspelled path, a removed resource, a routing layer, or an application intentionally hiding existence. A 500 indicates a server-side failure response but does not identify the defective component. Compare the request URL, method, headers, and body with the expected API contract, then use relevant server or proxy logs. Avoid drawing a complete diagnosis from one number. Reproduce the smallest request that shows the issue and retain response context for a useful bug report.

When this tool is useful

• Interpret an API response during debugging
• Explain a redirect or missing-page response
• Review status-code choices in an application

Tips for a better result

• Inspect the URL, method, response body, headers, and relevant server logs alongside the status reference.
• Replace example paths, identifiers, and names deliberately. Copying a reference command unchanged can target a different file, branch, service, or environment from the one you intended.
• Keep the source and the settings used for this result together. That makes a later comparison or correction easier, especially when another person needs to reproduce the same outcome.

Frequently asked questions