HTTP ヘッダーパーサー — HTTP ヘッダーを JSON にオンラインで無料解析
生の HTTP ヘッダーを構造化 JSON に解析します。API のデバッグに最適で、リクエストライン、ヘッダー数、すべてのキーと値のペアを抽出します。完全にブラウザ内で動作します。
HTTP ヘッダーを手でパースするのは退屈で間違いやすいものです。形式は単純——Name: Value、1 行に 1 つ——ですが、サーバーレスポンスから 20 個のヘッダーがあり、Cache-Control が何を言っているか、正しい Access-Control-Allow-Origin が設定されているか、カスタムの X-Request-Id ヘッダーが存在するかをチェックする必要がある場合、テキストブロックをスクロールする時間は無駄です。HTTP ヘッダーパーサーは生のヘッダーブロックを受け取り、検索、コピー、参照できる構造化 JSON オブジェクトに変換します。すべてのヘッダーが JSON のキーになり、リクエストライン（存在する場合）は別フィールドとしてキャプチャされ、何もドロップされていないことを確認するための合計ヘッダー数が含まれます。
パーサーは、3 つの最も一般的なヘッダー形式を扱います。リクエストライン（GET /api/users HTTP/1.1）、レスポンスステータス行（HTTP/1.1 200 OK）、または最初の行すらないヘッダーのみのブロック。正確なヘッダー名の大文字小文字を保持します。正規化もせず、小文字化もしません。実際に送信されたものが表示されます。これはデバッグにおいて重要です。一部のサーバーフレームワークとミドルウェアは予想外に大文字小文字を区別するからです。出力はクリーンな JSON ドキュメントで、インデントされ読みやすく、コードレビュー、インシデントレポート、ドキュメンテーションページにそのまま貼り付けられます。
このツールへの最大のトラフィックを生むユースケースは、開発者が同僚の Slack メッセージから curl コマンドをコピーし、それを実行してレスポンスを受け取り、ヘッダーを検査する必要があるというものです。ターミナル出力は折り返され、ヘッダーはボディと交互に並び、特定のヘッダー値を見つけるにはスクロールと目を細める必要があります。ヘッダーブロックをパーサーに貼り付けると、各ヘッダーが 1 行になる検索可能な JSON ドキュメントが得られます。代替手段——curl -v 出力をパースする単発スクリプトを書くこと——は、まさに専用のツールが排除する種類の摩擦です。ヘッダーデータの全バイトはブラウザ内に留まり、サーバーには送信されません。
使い方
生の HTTP ヘッダーを貼り付ける
ターミナル、ブラウザ DevTools、またはサーバーログから生のリクエストまたはレスポンスヘッダーを貼り付けます。最初の行（GET/POST/HTTP）はリクエスト行として扱われます。各 `Key: Value` 行が、ヘッダー名をキー、値を文字列とする構造化 JSON オブジェクトに解析されます。
出力を確認する
出力には、検出された場合はリクエストライン、各ヘッダーがキーと値のペアとして、そして合計ヘッダー数が表示されます。ドキュメント、デバッグ、監視ダッシュボードやアラートシステムへの統合のために JSON をコピーできます。
JSON をコピーまたはダウンロードする
解析された JSON をクリップボードにコピーするか、ファイルとしてダウンロードできます。出力は可読性のために 2 スペースインデントでフォーマットされており、コードレビューコメント、診断チケット、API ドキュメントページにそのまま貼り付けられます。
よくある質問
ヘッダーはどの形式であるべきですか？
標準の HTTP/1.x ヘッダー形式——1 行に 1 ヘッダー、各行が `Name: Value` の形式です。最初の行はリクエストライン（例：`GET /api/users HTTP/1.1`）またはレスポンスステータス行（例：`HTTP/1.1 200 OK`）のいずれかです。空行は無視されます。パーサーはリクエストラインを必須とせず、ヘッダーだけのブロックも受け入れます。
ヘッダーの検証は行いますか？
本ツールは構文のみを解析し、RFC 9110 に従った有効な HTTP ヘッダー名であるか、そのフィールドタイプの RFC 仕様に値が準拠しているかをチェックしません。入力にあるものをそのまま抽出します。意味的な検証には、専用の HTTP ライブラリまたはプロキシーツールをご利用ください。
複数行のヘッダー値を解析できますか？
いいえ。廃止された複数行（折りたたみ）ヘッダー値構文（空白文字で始まる継続行）を使うものは、RFC 7230 に従って HTTP/1.1 で非推奨となり、HTTP/2 と HTTP/3 で削除されました。パーサーは各行を独立して扱います。
Set-Cookie ヘッダーを正しく解析しますか？
Set-Cookie ヘッダーはセミコロンとカンマを含むことがあり、HTTP では構造的ですが、行ベースのパーサーには曖昧です。パーサーは値の文字列全体をキャプチャし、個々の Cookie 属性を分割しません。個々のディレクティブを分解する必要がある場合は、Cookie 値にクエリ文字列パーサーをご利用ください。
HAR to cURL とどう違いますか？
HAR to cURL は完全な HAR アーカイブ（タイミングを含むリクエスト/レスポンスのペア）を実行可能コードに変換します。HTTP ヘッダーパーサーは生のヘッダーテキストのみを受け取り、それを構造化 JSON に変換します。両者は隣接する目的を果たします。HAR はリプレイとコード生成用、生ヘッダー解析は検査とドキュメント化用です。
制限事項
- HTTP の意味検証なし本ツールは、ヘッダーが HTTP にとって意味的に正しいか（例：CORS に必要なヘッダー、HTTP/1.1 での Host ヘッダーの欠落、無効な組み合わせ）を検証しません。意味チェックには、完全な HTTP ライブラリまたは Charles や mitmproxy のようなプロキシーを使用してください。
- Cookie 分解なしSet-Cookie と Cookie ヘッダーは単一の文字列として返されます。個々の Cookie 属性や値を分割する必要がある場合は、文字列を Cookie パーサーまたはクエリ文字列パーサーツールで処理してください。
- HTTP/2 または HTTP/3 フレーム解析なしHTTP/2 は HPACK で圧縮されたバイナリフレームを使用します。HTTP/3 は QPACK を使用します。本ツールは、ターミナル出力や DevTools に現れるテキスト形式の HTTP/1.x ヘッダーのみで動作します。
プラットフォーム別の注意点
- macOS
- `curl -v https://api.example.com 2>&1 | grep '^[<>]'` を使ってリクエストとレスポンスのヘッダーを抽出し、ここに貼り付けます。`-v` フラグは完全なヘッダー交換を stderr に出力します。
- Windows
- PowerShell の `Invoke-WebRequest` と `Invoke-RestMethod` は `$response.Headers` にレスポンスヘッダーを公開します。ブラウザ DevTools（F12 → Network → Headers タブ）が最も手軽なソースです。生ヘッダーをコピーしてパーサーに貼り付けてください。
- Linux
- 生のヘッダーには `curl -v`、`wget --debug`、または `tcpdump -A`。ライブトラフィックには `ngrep -W byline port 80` がワイヤ上の HTTP ヘッダーをキャプチャします。ブラウザツールは与えられたテキストをすべて後処理します。
- Web
- 完全にブラウザ内で動作します。ヘッダーデータはどのサーバーにも送信されません。オンラインサービスにさらすことなく、内部 API レスポンス、サードパーティの webhook ペイロード、認証トークンのヘッダーを解析するのに便利です。