Innomerc Learn
English is the default.
Web & Backend Technology

HTTP Status Codes

Read the server’s response as a useful signal, without mistaking a status code for the whole story.

Foundational6 min explorationReviewed
My learningNot started

Choose your depth. Learn at your own pace.

Simple explanation

Understand it

An HTTP status code describes the result of a request. The first digit groups the response: 1xx is informational, 2xx successful, 3xx redirection, 4xx a client-error response and 5xx a server-error response. The details depend on the specific code.

For example, 200 commonly means the request succeeded, 404 means the target resource was not found or the server is unwilling to disclose it, and 503 means the service is temporarily unable to handle the request. Read the response context rather than guessing from one number.

Technical explanation

Under the hood

401 indicates that the request lacks valid authentication credentials. A server generating it must include a WWW-Authenticate header containing an applicable challenge. 403 indicates that the server refuses the request; signing in again is not necessarily the solution. 304 is a conditional-request result that allows reuse of a stored representation, not a normal page body.

201 indicates creation, often with a Location header. 204 indicates success without response content. Redirect methods matter: 307 and 308 preserve the request method, while historical handling of 301 and 302 can change POST to GET. Clients need correct redirect behavior.

Practitioner explanation

Practitioner perspective

A reverse proxy may generate 502 or 504 before the application receives the request. Correlate upstream logs, application traces and request identifiers. A burst of 403 responses can be policy enforcement, scanner traffic or a deployment mistake; it does not establish intent alone.

Define retry behavior by operation safety, idempotency and server guidance. A failed response does not prove that a write had no effect. For 429, honor Retry-After when provided and use bounded backoff rather than amplifying overload.

See the decision happen

Watch it work

A fictional, simplified model. Select a component to inspect it, or follow the steps in order.

Interactive Lab

HTTP response map

Select a status and watch where the request is handled.

Steps1. GET guide 2. Forward 3. 200 4. 200
Click a box or choose its name to learn what it means.
BrowserReadyGatewayReadyAPI serviceReadyBrowserReadyGatewayReadyAPI serviceReady
Ready to trace200 OK
Before you start · 4 steps200 OK

A successful request returns a representation.

How to use this example

Select Next step to read at your own pace, or Animate step to watch one exchange. Nothing advances until you choose.

Inspect components & read every step
  • Browser

    The program you use to open websites.

    Example: Your browser requests a web page and displays the response.

  • Gateway

    A system between a client and services that routes requests and may apply checks.

    Example: It may reject a request over a configured rate limit before it reaches a service.

  • API service

    A system that accepts structured requests from other software and returns results.

    Example: A weather service returns the forecast requested by an app.

200 OK

A successful request returns a representation.

  1. Browser Gateway: GET guide. The request reaches the edge.
  2. Gateway API service: Forward. This example passes the edge checks.
  3. API service Gateway: 200. A successful request returns a representation. Example response: Representation returned
  4. Gateway Browser: 200. The gateway returns the response to the client.

201 Created

Creation succeeds; the Location header can identify the new resource.

  1. Browser Gateway: POST order. The request reaches the edge.
  2. Gateway API service: Forward. This example passes the edge checks.
  3. API service Gateway: 201. Creation succeeds; the Location header can identify the new resource. Example response: Location: /orders/42
  4. Gateway Browser: 201. The gateway returns the response to the client.

204 No Content

The operation succeeds without response content.

  1. Browser Gateway: DELETE item. The request reaches the edge.
  2. Gateway API service: Forward. This example passes the edge checks.
  3. API service Gateway: 204. The operation succeeds without response content. Example response: No response body
  4. Gateway Browser: 204. The gateway returns the response to the client.

301 Moved Permanently

The client learns a permanent redirect; method handling requires care.

  1. Browser Gateway: GET old URL. The request reaches the edge.
  2. Gateway API service: Forward. This example passes the edge checks.
  3. API service Gateway: 301. The client learns a permanent redirect; method handling requires care. Example response: Location: /new
  4. Gateway Browser: 301. The gateway returns the response to the client.

400 Bad Request

The server rejects malformed input without leaking internals.

  1. Browser Gateway: Malformed request. The request reaches the edge.
  2. Gateway API service: Forward. This example passes the edge checks.
  3. API service Gateway: 400. The server rejects malformed input without leaking internals. Example response: Safe client error
  4. Gateway Browser: 400. The gateway returns the response to the client.

401 Unauthorized

The private endpoint requires valid authentication credentials.

  1. Browser Gateway: No valid credentials. The request reaches the edge.
  2. Gateway Browser: 401. The private endpoint requires valid authentication credentials. Example response: WWW-Authenticate

403 Forbidden

The server refuses the operation despite understanding the request.

  1. Browser Gateway: Other user’s record. The request reaches the edge.
  2. Gateway API service: Forward. This example passes the edge checks.
  3. API service Gateway: 403. The server refuses the operation despite understanding the request. Example response: No protected body
  4. Gateway Browser: 403. The gateway returns the response to the client.

404 Not Found

The server cannot find the resource or chooses not to disclose it.

  1. Browser Gateway: Unknown path. The request reaches the edge.
  2. Gateway API service: Forward. This example passes the edge checks.
  3. API service Gateway: 404. The server cannot find the resource or chooses not to disclose it. Example response: Resource unavailable
  4. Gateway Browser: 404. The gateway returns the response to the client.

429 Too Many Requests

This example limiter asks the client to wait; retry guidance is policy-specific.

  1. Browser Gateway: Request burst. The request reaches the edge.
  2. Gateway Browser: 429. This example limiter asks the client to wait; retry guidance is policy-specific. Example response: Retry-After: 30

500 Server Error

An unexpected server failure is recorded privately, not exposed as a stack trace.

  1. Browser Gateway: Valid request. The request reaches the edge.
  2. Gateway API service: Forward. This example passes the edge checks.
  3. API service Gateway: 500. An unexpected server failure is recorded privately, not exposed as a stack trace. Example response: Safe error response
  4. Gateway Browser: 500. The gateway returns the response to the client.

Fictional teaching trace. One moving dot represents an exchange, not a measured network capture.

Open the detailed lesson walkthrough

Explore the system

Request

The client requests an available public guide.

1 / 3

Takeaway Success describes this request, not the security of the entire system.

Read every step without animation

200 OK

  1. Request. The client requests an available public guide.
  2. Application. The application successfully handles the request.
  3. 200 OK. The response carries the guide.

Success describes this request, not the security of the entire system.

403 Forbidden

  1. Request. An authenticated user requests a restricted report.
  2. Policy. The server refuses access under its authorization policy.
  3. 403 Forbidden. No report content is returned.

A valid identity can still lack permission.

429 Too Many Requests

  1. Request burst. The client exceeds a service-specific limit.
  2. Limiter. The service limits further requests.
  3. 429 response. The client should follow retry guidance rather than loop immediately.

Slow down and retry according to policy.

Explore deeper: additional experiment
Change an input. Inspect the consequence.

Choose the response condition

200 OK

The request succeeded. The body and method determine the result’s meaning.

A local teaching model with fictional inputs. It does not test a live system.

Attack view

A service that reveals different statuses for existing and nonexistent accounts can unintentionally disclose information. The right response policy depends on context and should avoid misleading legitimate users.

Defender view

  • Return meaningful, consistent statuses without leaking sensitive internals.
  • Keep detailed diagnostics in protected logs, not public error bodies.
  • Implement bounded retries and idempotency for operations that may be repeated.

Common mistakes

  • 200 does not prove an authorization decision was correct.
  • Every 4xx response is not evidence of an attacker.

Check your understanding

Can a 200 response still expose the wrong user’s data?
Active recall: explain this idea in 30 seconds

An HTTP status code describes the result of a request. The first digit groups the response: 1xx is informational, 2xx successful, 3xx redirection, 4xx a client-error response and 5xx a server-error response. The details depend on the specific code.

Now give an example and name one limitation. Revisit the explanation if you get stuck.

Primary sources

Original explanations informed by these specifications and official resources. Source versions and lesson review are separate from product updates.

Content reviewed 2026-09-10. Read the editorial policy.

What comes next?

Technology fundamentals

Back to topic