HTTP Status Codes & Headers Reference

Interactive developer reference for HTTP/1.1 and HTTP/2/3 response status codes and security headers. Complete with RFC standards, caching semantics, and common pitfalls.

Private by architecture: All processing is 100% client-side memory. Your data never leaves this browser tab.

Initial part of request received; client should proceed with the rest of request body.

Server agrees to switch protocols (e.g. HTTP to WebSocket via Upgrade header).

Standard response for successful HTTP requests with payload representation.

Request succeeded and a new resource was created. Location header often points to it.

Request accepted for background processing, but batch execution has not completed.

Action succeeded but returns zero message-body (e.g. successful DELETE or PUT).

Delivering only part of resource due to Range header sent by client (e.g. video streaming).

Resource permanently moved to new URI in Location header. User-Agents may rewrite method to GET.

💡 Historical behavior rewrites POST to GET. Use 308 if original HTTP method must be preserved.

Temporary redirect. Client should continue using original URI for future requests.

💡 May rewrite method to GET. Use 307 if original HTTP method must be preserved.

Client cached version is still fresh according to ETag or If-Modified-Since headers.

Temporary redirect requiring the client to reuse the exact same HTTP method (e.g. POST remains POST).

Permanent redirect requiring the client to reuse the exact same HTTP method (e.g. POST remains POST).

Server cannot process request due to client error (malformed syntax, invalid JSON, or framing error).

Authentication is required and has either failed or not yet been provided.

💡 Means Unauthenticated. WWW-Authenticate header must indicate acceptable challenge schemes.

Client identity is known, but client lacks necessary permissions or scope to access resource.

💡 Unlike 401, authenticating with same credentials will not change the outcome.

Server cannot find current representation for target resource or endpoint URI.

Target resource does not support the request HTTP method (e.g. POSTing to read-only resource).

Request conflicts with current state of target resource (e.g. duplicate key or version edit conflict).

Hyper Text Coffee Pot Control Protocol easter egg: teapot refuses to brew coffee.

Request syntax is valid JSON/XML, but semantic instructions or payload fields are invalid.

Client has exceeded rate limits. Response should include Retry-After header.

Server encountered unexpected condition that prevented it from fulfilling the request.

Server acting as proxy received invalid or crashed response from upstream origin server.

Server currently unable to handle request due to temporary overload or scheduled maintenance.

Server acting as gateway did not receive timely response from upstream server.

Standard HTTP Headers

Essential security, caching, CORS, and authentication headers.

Content-Security-Policy Security

Restricts resource loading (scripts, images, frames) to prevent XSS and data injection.

Example: default-src 'self'; script-src 'self' https://trusted.cdn.com

Strict-Transport-Security Security

Enforces HTTPS-only communication and prevents SSL-stripping man-in-the-middle attacks.

Example: max-age=63072000; includeSubDomains; preload

X-Content-Type-Options Security

Prevents MIME-sniffing away from declared Content-Type header.

Example: nosniff

Cache-Control Caching

Directs caching behavior across client browsers, CDNs, and intermediate proxies.

Example: public, max-age=31536000, immutable

ETag Caching

Unique content hash used for conditional validation with If-None-Match header.

Example: "33a64df551425fcc55e4d42a148795d9f25f89d4"

Access-Control-Allow-Origin CORS

Declares which origins are permitted to access resource via browser fetch/XHR.

Example: https://yourstand.art

Authorization Auth

Transmits client authentication credentials (e.g. Bearer JWT tokens or Basic auth).

Example: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

About This Tool

Searchable reference directory for HTTP status codes and standard headers. Every entry carries its spec, caching behavior, and common pitfalls inline. Pick the right status code for a response, double-check what a header does, or copy a ready-to-use status line without retyping.

Static reference with zero telemetry. To parse live network traffic or build requests, use cURL to Code or URL Parser.

Key Features

Instant search: Matches against code, phrase, and description at once, or header name, description, and example.
Category tabs: Filter to 2xx, 3xx, 4xx, 5xx, or switch to the Headers-only view.
One-click status line copy: The Copy pill writes HTTP/1.1 {code} {phrase} straight to your clipboard.
Cacheable indicator: Each status card flags whether that response is cacheable by default.
RFC spec tags: Every code and header links back to the defining spec, such as RFC 9110 or RFC 6585.
Contextual notes: Callouts like the 301-vs-308 method preservation distinction directly on the card.

Frequently Asked Questions

What does the search box match?

It matches against the status code, phrase, and description (or header name, description, and example) all at once, so searching 404, not found, or unauthorized all work.

What do the category tabs do?

All, 2xx Success, 3xx Redirect, 4xx Client, 5xx Server filter the status grid by category. The Headers tab hides the status grid and shows only the headers section.

What does the Cacheable tag mean?

It flags whether that response status is cacheable by default per the HTTP spec, e.g. 200 OK and 404 Not Found are cacheable, while 429 Too Many Requests is not.

Where do the RFC spec tags come from?

Each status code and header links to the RFC (or W3C spec) that defines it, e.g. RFC 9110 for most HTTP semantics or RFC 6585 for 429 Too Many Requests.

Does copying a status line require a network request?

No. The Copy button writes HTTP/1.1 {code} {phrase} straight to your clipboard from data already loaded on the page.