HTTP Status Code Reference

How to Use the HTTP Status Code Reference

This HTTP status code reference provides a comprehensive list of all common HTTP response status codes, organized by category. Use the search filter at the top to quickly find any status code by its number or name. The tool displays all codes from 1xx informational responses through 5xx server errors, with a clear description of each code meaning and typical use case. All data is displayed client-side with no server calls needed.

Understanding HTTP Status Code Categories

HTTP status codes are divided into five categories. 1xx codes are informational responses indicating the request was received and processing continues. 2xx codes indicate successful processing, with 200 OK being the most common. 3xx codes handle redirections, telling the client to look elsewhere for the resource. 4xx codes represent client errors where the request contains bad syntax or cannot be fulfilled. 5xx codes indicate server errors where the server failed to fulfill an apparently valid request.

Common Status Codes for Web Developers

The most frequently encountered status codes in web development include 200 (OK) for successful requests, 301 and 302 for redirects, 404 for missing resources, and 500 for server errors. Understanding these codes is essential for debugging API integrations, configuring web servers, and building robust error handling in web applications. The 429 status code is increasingly important for rate-limited APIs, while 401 and 403 are critical for authentication and authorization flows.

HTTPステータスコードリファレンスについて

主要なHTTPステータスコードをカテゴリ別に一覧表示し、番号や名前で即座に検索できるリファレンスツールです。1xx情報レスポンスから5xxサーバーエラーまで網羅しており、各コードの意味と用途を確認できます。API開発やWeb開発のデバッグに便利です。

HTTPステータスコード一覧の使い方

検索フィルタにコード番号（例: 404）、名前の一部（例: Forbidden）、説明中のキーワード（例: cache）を入力すると、一覧が即座に絞り込まれます。カテゴリごとに色分けされているため、「4xxだからクライアント側の問題」「5xxだからサーバ側」という切り分けが視覚的に行えます。

1. API設計でのステータスコード選定

REST APIのレスポンス設計では、成功をすべて200で返すのではなく、リソース作成は201 Created、ボディ不要の成功は204 No Content、楽観ロックの競合は409 Conflictと使い分けると、クライアント実装が分岐しやすくなります。設計レビューの際に「この操作に最も適切なコードはどれか」を本ツールで確認できます。

2. 障害調査・アクセスログの解析

本番障害でアクセスログに502 / 503 / 504が並んだとき、意味の違い（上流から不正な応答 / 過負荷・メンテナンス中 / 上流の応答タイムアウト）を即座に確認することで、ロードバランサ側かアプリケーション側かの切り分けが速くなります。504が多発していればアプリの処理時間、502ならプロセスのクラッシュやポート設定をまず疑う、といった初動判断に使えます。

3. サイト移転・URL変更時のリダイレクト設計

ドメイン移転やURL構造変更では、301/308（恒久）と302/307（一時）の違いに加え、HTTPメソッドが保持されるか（307/308は保持、301/302はGETに変換され得る）が重要です。SEO評価の引き継ぎとフォームPOSTの挙動を、設定前に本ツールで再確認してください。

よくある落とし穴 / Common Pitfalls

ステータスコード自体はエラーを「出す」ものではありませんが、選び方・返し方を誤ると実害が出ます。現場で頻出する誤用をまとめました。

Status codes do not throw errors themselves, but choosing or returning the wrong one causes real-world problems. Here are the most common misuses.

言語別コード例 / Code Examples by Language

ステータスコードの取得・分岐をコードで行う場合の最小サンプルです。

Minimal snippets to read and branch on HTTP status codes programmatically.

JavaScript (fetch)

const res = await fetch("/api/users");
console.log(res.status); // 200, 404, ...
console.log(res.ok);     // 200-299 なら true / true for 200-299

if (res.status === 429) {
  // 待機秒数 / seconds to wait
  const wait = res.headers.get("Retry-After");
}

Python (requests)

import requests
from http import HTTPStatus

r = requests.get("https://api.example.com/users")
print(r.status_code)                     # 200, 404, ...
print(HTTPStatus(r.status_code).phrase)  # "OK", "Not Found"
r.raise_for_status()  # 4xx/5xx で例外 / raises on 4xx/5xx

Go (net/http)

resp, err := http.Get("https://api.example.com/users")
if err != nil {
    log.Fatal(err)
}
defer resp.Body.Close()

fmt.Println(resp.StatusCode)                  // 200
fmt.Println(http.StatusText(resp.StatusCode)) // "OK"
if resp.StatusCode == http.StatusTooManyRequests {
    // レート制限時の処理 / handle rate limiting
}

Shell (curl)

# ステータスコードだけ取得 / Status code only
curl -s -o /dev/null -w "%{http_code}" https://example.com

# レスポンスヘッダを確認(リダイレクト追跡) / Inspect headers, follow redirects
curl -sIL https://example.com

Before / After 実例 / Request & Response Examples

例1: 301 恒久リダイレクト / Permanent redirect

GET /old-page HTTP/1.1
Host: example.com

↓

HTTP/1.1 301 Moved Permanently
Location: https://example.com/new-page
Cache-Control: max-age=31536000

Locationヘッダが移転先。Cache-Controlの期間だけブラウザが転送を記憶します。

The Location header carries the new URL; browsers remember the redirect for the Cache-Control lifetime.

例2: 401 と 403 のレスポンス比較 / 401 vs 403 responses

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="api"

↓ 認証後も権限が足りない場合 / after authenticating, if still not allowed:

HTTP/1.1 403 Forbidden
Content-Type: application/json

{"error": "insufficient_scope"}

例3: 429 レート制限 / Rate limiting with Retry-After

POST /api/search HTTP/1.1
Host: api.example.com

↓

HTTP/1.1 429 Too Many Requests
Retry-After: 30
Content-Type: application/json

{"error": "rate_limited", "retry_after": 30}

Why browser-only? / なぜブラウザ完結か

Status codes themselves are public knowledge, but the way you search for them is not. During an incident, the terms you type — an internal endpoint path, a vendor name, the exact code your gateway keeps returning — reveal what is breaking inside your infrastructure. A server-backed reference would receive and log every one of those queries. This page ships the entire status code table as static data inside the HTML, and the search filter runs in memory in your browser: no query ever leaves the tab, and there is no per-request latency or rate limit. You can verify this yourself by opening DevTools → Network and typing in the filter — no requests appear. Once the page has loaded, the reference even keeps working if your network goes down, which is exactly when you tend to need it.

ステータスコード自体は公開情報ですが、障害対応中に検索する語句（社内APIのパスやゲートウェイが返し続けるコードなど）は社内事情そのものです。本ツールはコード表をページ内に静的データとして持ち、絞り込みはブラウザのメモリ上で完結します。検索語が外部に送信されることはなく、DevTools → Networkタブで通信が発生しないことを確認できます。一度読み込めばオフラインでも参照できるため、ネットワーク障害時の調査にも使えます。