HTTP ステータスコード一覧無料・登録不要
主要 25+ の HTTP ステータスコード（1xx-5xx）を一覧表示。カテゴリ別絞り込み + コード番号/名前/説明での検索。各コードの利用シーンと SEO 影響まで網羅。
| コード | 名前 | 説明 | 主な利用シーン |
|---|---|---|---|
| 100 | Continue | クライアントはリクエストを継続してよい | Expect: 100-continue ヘッダの応答 |
| 101 | Switching Protocols | プロトコル切替成功 | HTTP → WebSocket アップグレード時 |
| 200 | OK | リクエスト成功 | 最も一般的な成功応答（GET / POST 等） |
| 201 | Created | リソース作成成功 | POST でリソース新規作成成功時。Location ヘッダに新 URL |
| 202 | Accepted | リクエスト受理（処理は未完） | 非同期処理の受付（バッチジョブ起動等） |
| 204 | No Content | 成功・本文なし | DELETE 成功時 / PUT 更新成功時に本文不要なケース |
| 206 | Partial Content | 一部内容応答 | 動画 / 大ファイルのレンジリクエスト（Range ヘッダ） |
| 301 | Moved Permanently | 恒久的移動 | ドメイン引越し / URL 変更時。SEO 評価引き継ぎ |
| 302 | Found | 一時的移動 | 一時的なリダイレクト（メンテ等）。SEO は元 URL 評価維持 |
| 303 | See Other | 別 URL 参照 | POST 後の GET リダイレクト（PRG パターン） |
| 304 | Not Modified | キャッシュ有効 | If-Modified-Since / ETag 一致時。帯域節約 |
| 307 | Temporary Redirect | 一時的移動（メソッド維持） | 302 の HTTP メソッド保持版 |
| 308 | Permanent Redirect | 恒久的移動（メソッド維持） | 301 の HTTP メソッド保持版 |
| 400 | Bad Request | リクエスト構文不正 | JSON パース失敗 / 必須パラメータ欠落 |
| 401 | Unauthorized | 認証必要 | Authorization ヘッダ未設定 / トークン期限切れ |
| 403 | Forbidden | 認証はあるが権限なし | 一般ユーザが管理 API にアクセス時等 |
| 404 | Not Found | リソース不在 | 存在しない URL / ID |
| 405 | Method Not Allowed | メソッド非対応 | GET のみ対応 URL に POST 等。Allow ヘッダに対応メソッド明示 |
| 409 | Conflict | リソース競合 | 楽観ロック失敗 / 重複登録 / 更新衝突 |
| 410 | Gone | 恒久削除 | 削除済 API / 廃止済 URL。SEO 削除シグナル |
| 422 | Unprocessable Entity | 構文 OK だが意味的エラー | バリデーションエラー（フォーマットは合うが値が不正） |
| 429 | Too Many Requests | レート制限超過 | API レート制限 / DDoS 緩和。Retry-After ヘッダ推奨 |
| 500 | Internal Server Error | サーバ内部エラー | 未捕捉の例外 / コードバグ |
| 502 | Bad Gateway | ゲートウェイ不正 | プロキシが上流サーバから不正応答受領（Nginx → App down 時） |
| 503 | Service Unavailable | サービス利用不可 | メンテ中 / 過負荷。Retry-After ヘッダ推奨 |
| 504 | Gateway Timeout | ゲートウェイタイムアウト | プロキシが上流サーバ応答待ちタイムアウト |
- 1xx: 情報（処理中継続）
- 2xx: 成功（200 OK / 201 Created / 204 No Content）
- 3xx: リダイレクト（301 恒久 / 302 一時 / 304 キャッシュ）
- 4xx: クライアントエラー（400 Bad Request / 401 認証 / 403 権限 / 404 不在 / 429 レート制限）
- 5xx: サーバエラー（500 内部 / 502 Bad Gateway / 503 メンテ / 504 タイムアウト）
- SEO 観点: 404 は許容 / 410 で「恒久削除」を Google に通知 / 301 で URL 変更を伝達
- 関連: 正規表現テスター / JSON 整形
良いHTTP ステータスコード一覧の判断基準
エラー画面や API レスポンスで見慣れないステータスコードに出会ったら、まず本ツールでコードの意味と利用シーンを調べ、下の判断基準で原因の切り分けを進めてください。コードは「どちら側に原因がありそうか」を示すヒントであり、コード単体で原因を断定するものではありません。
百の位のカテゴリから切り分けを始めたか
4xx はクライアント側（リクエスト内容）起因、5xx はサーバー側起因という大分類がスタート地点です。個別のコードの意味を調べる前に、まずどちら側を疑うべきかを百の位で判断します。
コードだけで原因を断定していないか
同じコードでも原因は複数あり得ます。コードはあくまで分類で、実際の原因はレスポンスボディのエラーメッセージやサーバーログと合わせて特定します。
4xx ならリクエスト内容を見直したか
URL の打ち間違い・必須パラメータの欠落・認証情報の不足など、送っている側の内容をまず確認します。サーバー障害を疑う前に、自分のリクエストが仕様通りかを見直すのが先です。
5xx ならサーバー側の状態を確認したか
サーバーログ・直前のデプロイ・依存している外部サービスの稼働状況を確認します。5xx は受け取る側では直せないことが多いため、運用側への連絡や時間を置いた再試行が基本の対応になります。
似た者同士のコードの定義を確認したか
認証まわりの 401 と 403、リダイレクトの 301 と 302 など、混同しやすいコードがあります。API 設計やドキュメント作成で使う前に、一覧で定義の違いを確認してから選びます。
キャッシュやリダイレクトの影響を考えたか
3xx 系はブラウザや中間サーバーのキャッシュに影響され、古い挙動が残ることがあります。挙動が説明できない時は、キャッシュを無効にした状態で再確認すると切り分けが進みます。
ありがちな失敗例（NG → 改善）
NG404 が出た時点で「サーバーが壊れている」と判断して運用側に問い合わせる。
改善4xx はまず URL のつづり・リクエスト先のパス・パラメータなど自分側の内容を見直す。
→ 4xx はクライアント側起因の分類です。送っている内容の確認を飛ばすと、原因が手元にあるのに調査が空回りします。
NGAPI がエラー時も常に 200 を返し、ボディの中身だけでエラーを表現する設計にする。
改善エラーの内容に合ったコード（4xx / 5xx）を返し、詳細をボディで補足する設計にする。
→ 全部 200 だと監視ツールやキャッシュがエラーを正常と誤認します。コードの分類に沿って返すのが HTTP の前提です。
NG認証エラーに 401 と 403 を区別なく使う。
改善認証情報がない・不正なら 401、認証は通ったが権限が足りないなら 403 と使い分ける。
→ 401 と 403 は「ログインし直せば解決するか」の判断材料になります。混同すると利用者が正しい対処にたどり着けません。
HTTP ステータスコード一覧の使い方
- 1テキストを入力またはペーストします
- 2「変換する」ボタンをクリックします
- 3結果を確認してコピーします
よくある質問
HTTP ステータスコード一覧は無料ですか？
はい、完全無料でご利用いただけます。会員登録も不要です。
スマートフォンでも使えますか？
はい、スマートフォン・タブレット・PCなど、ブラウザがあればどのデバイスでもご利用いただけます。
入力したコードやデータは安全ですか？
はい、入力データはブラウザ上で処理され、サーバーに送信されません。安心してご利用ください。
関連ツール
HTTP ステータスコード一覧について
API 設計でコードを毎回調べ直す手間
バックエンド開発で API 設計する時、「リソース作成成功は 200？ 201？」「バリデーションエラーは 400？ 422？」「レート制限は 429？」と毎回 MDN を見に行くのは時間の無駄。本ツールは主要 26 コードを一覧 + 検索 + カテゴリ絞り込みで瞬時に確認。各コードの「利用シーン」も併記しているため、設計判断にすぐ使えます。
コードカテゴリ別ガイド
【1xx Informational】100 Continue / 101 Switching Protocols（プロトコル切替） 【2xx Success】200 OK（一般成功）/ 201 Created（POST 成功）/ 204 No Content（DELETE 成功） 【3xx Redirection】301 恒久移動 / 302 一時 / 304 キャッシュ / 307 メソッド維持一時 / 308 メソッド維持恒久 【4xx Client Error】400 構文エラー / 401 認証 / 403 権限 / 404 不在 / 409 競合 / 422 バリデーション / 429 レート制限 【5xx Server Error】500 内部 / 502 Bad Gateway / 503 メンテ / 504 タイムアウト
よく迷うコードの使い分け
【200 vs 201 vs 204】データ返す = 200 / リソース作成 = 201 / 削除成功で本文不要 = 204
【301 vs 302 vs 307 vs 308】恒久移動 + メソッド変更可 = 301 / 一時移動 + メソッド変更可 = 302 / 一時 + メソッド維持 = 307 / 恒久 + メソッド維持 = 308。SEO では 301 / 308 がリダイレクト先に評価引き継ぎ。
【401 vs 403】認証情報なし or 不正 = 401 / 認証 OK だが権限不足 = 403。WWW-Authenticate ヘッダの有無で判別。
【400 vs 422】JSON パース失敗 / 必須欠落 = 400 / フォーマットは合うが値が不正（email 形式違反等） = 422
【404 vs 410】「もう存在しない」を SEO に伝えたい = 410（Gone）。404 は「将来復活するかも」のニュアンス
今回試した検索条件
実際の挙動を確かめるため、実在するコード（404、および混同しやすい 401）と、実在しない番号（999）を検索窓に入れて結果を見ました。以下はいずれも本ツールの実際の表示です。
実処理結果（実在するコードと存在しない番号を引いたとき）
「404」を検索すると、1 件が表示され、内容は次のとおりでした。 404 | Not Found | リソース不在 | 存在しない URL / ID
混同しやすい「401」を検索したときも 1 件が表示され、内容は次のとおりでした。 401 | Unauthorized | 認証必要 | Authorization ヘッダ未設定 / トークン期限切れ
一方、実在しない「999」を検索すると、表示件数は 0 件となり、結果の表は空になりました。このとき「見つかりません」といった案内メッセージは出ず、表が空のまま残るだけでした。
検索して分かったクセ
実在するコードを入れると、コード番号・名前・説明・主な利用シーンが1行の表として返ります（404 なら「Not Found／リソース不在／存在しない URL・ID」という具合です）。検索窓はコード番号のほか名前や説明でも絞り込める作りで、画面にはカテゴリ（1xx Informational 〜 5xx Server Error）での絞り込みも用意されています。表示件数は「1 件表示」「0 件表示」のように件数が出ます。これらは今回引いた3件（404・401・999）で観測できた挙動であり、収録された全コードで内容の正しさまで確認したわけではありません。
崩れた点と、構造上の限界
はっきり崩れたのは、実在しない番号を引いたときの扱いです。999 を検索すると 0 件になりますが、「そのコードは一覧にありません」といった案内は出ず、表が空になるだけでした。検索した本人は、番号の打ち間違いなのか、そもそも一覧に無いコードなのかを、画面から判断できません。また、今回試した 999 のように一覧に無い番号は 0 件になります。本ツールは主要な標準コードの早見表であり、あらゆる独自拡張番号まで収録したものではない点は踏まえておく必要があります。
このツールに任せないほうがよい判断
実装時に「このケースで何番を返すべきか」の最終判断を、この一覧の一言説明だけで決め切るのは避けたほうが安全です。たとえば 401 と 403、400 と 422 のように意味が近いコードは、上の「よく迷うコードの使い分け」も併せて読み、要件に照らして選んでください。仕様の厳密な定義が要る場面では、一次情報（各 RFC や MDN のドキュメント）で裏を取るのが確実です。
表示された説明をそのまま使うかの判断基準
表示される説明は、短い早見表として使う分には十分です。そのまま設計メモや社内ドキュメントに引き写してよいのは、今回 1 件で返った 404 や 401 のように定義がはっきりしたコードを、概要として共有する場面までです。API のレスポンス仕様書のように厳密さが問われる文書へ転記するときは、コードの意味を一次情報で確認し、自社の要件に合わせて説明文を書き足してください。実在しない番号で 0 件になったときは、コードの打ち間違いか、標準外の番号かをまず疑うと切り分けが早くなります。
ステータスコード運用でやりがちな誤り
1つ目: 全部 200 で返す → エラー時も 200 + body にエラー JSON は anti-pattern。HTTP セマンティクス壊す。
2つ目: 5xx を「クライアント原因」で返す → サーバ無関係のクライアント不正は 4xx。5xx は CloudWatch / Datadog のアラート対象。
3つ目: 認証関連で「401 Forbidden」と書くドキュメント → 「Forbidden」は 403。本来は「401 Unauthorized」。混同が業界全体で多い。
4つ目: Retry-After ヘッダ忘れ → 429 / 503 は Retry-After（秒数 or HTTP-date）を付けると親切。
5つ目: CORS のプリフライト失敗 → ブラウザは「CORS エラー」と表示するが、実態は 4xx / 5xx の HTTP レスポンス。サーバログで確認。