ネットワーク

HTTP メッセージパーサー

生の HTTP メッセージ、cURL コマンド、Chrome DevTools の「fetch としてコピー」スニペットを貼り付けると、リクエスト行、ステータス、headers、Query、Cookie、body を構造化ビューに展開し、cURL、HTTPie、fetch、axios、Python requests、Go、PHP など 30 種類以上のクライアント形式に再出力します。処理はすべてブラウザー内で行われ、メッセージや Cookie はこのページから外に出ません。

  • 1 つの入力欄で 生 HTTP・cURL・fetch の貼り付け形式を自動判別
  • リクエストもレスポンスも解析でき、headers / Query / Cookie / Set-Cookie をテーブルに展開
  • Body は Content-Type に応じて JSON / フォーム / XML / テキストに分類し、シンタックスハイライト付き
  • 1 回の貼り付けから 30 種類以上のクライアント形式に再出力
工具/HTTP メッセージパーサー

ここから開始

生 HTTP メッセージ、cURL コマンド、または DevTools の fetch スニペットを左の入力欄に貼り付けると、解析結果がここに表示されます。

サンプルを試す
サンプル

概要

散らばったリクエストやレスポンスを貼り付けるだけで、構造を展開し、軽いチェックをかけ、必要に応じて別の呼び出し形式に再出力します。

  1. 01

    3 種類の貼り付け形式を自動判別

    生 HTTP メッセージ、cURL コマンド、Chrome DevTools の「fetch としてコピー」スニペットを 1 行目の特徴から判別します。手動で形式を指定することもできます。

  2. 02

    リクエストとレスポンスの両方に対応

    リクエスト行・ステータス行・headers・Query・Cookie をテーブルに展開し、body は Content-Type に応じて JSON・フォーム・XML・テキストとしてハイライト表示します。

  3. 03

    Cookie を細かく分解

    リクエスト Cookie と Set-Cookie を別々に表示し、Domain・Path・Expires・Max-Age・HttpOnly・Secure・SameSite・Partitioned をそれぞれ独立した属性として抽出します。

  4. 04

    30 種類以上のクライアント形式に再出力

    cURL・HTTPie・wget・fetch・axios・got・ky・Python requests・Go・Rust・PHP Guzzle・Java OkHttp などをワンクリックで出力し、ドキュメント、移行スクリプト、回帰テストにそのまま貼り付けられます。

  5. 05

    中立的なセキュリティと形式のヒント

    レスポンスに HSTS、Content-Security-Policy、X-Content-Type-Options が無い、Cookie に Secure や HttpOnly が無い、__Host- プレフィックスが規約を満たしていない、といった点を控えめに通知します。判断はあなたに委ねます。

  6. 06

    ブラウザー内で完結

    判別・解析・変換・エクスポートはすべてこのページ内で行われ、メッセージや Cookie はネットワーク経由で外部に送られません。

使い方

1 つの入力欄で「判別 → 解析 → エクスポート」の流れが完結します。

  1. 01

    生 HTTP メッセージ、cURL コマンド、または DevTools の fetch スニペットを左の入力欄に貼り付けます。

  2. 02

    形式は自動で判別されます。誤判別の場合は上部のツールバーで 生 HTTP・cURL・fetch を手動指定できます。

  3. 03

    右側の概要でメソッド、ステータス、ホスト、Body サイズを確認し、headers・Query・Cookie・ヒントを開きます。

  4. 04

    Body ビューで本文を確認します。JSON とフォームは整形と原文を切り替えられます。

  5. 05

    別の形式が必要なら エクスポートビューに切り替え、ドロップダウンから出力先を選び、結果をコピーしてエディターに戻します。

詳細

キャプチャ・リクエスト再現・ドキュメント整備という日常作業を、同じワークスペースで止めずに進められます。

  • 生 HTTP は空行で headers と body を分け、1 行目のパターンでリクエストとレスポンスを区別します。
  • cURL の解析でメソッド、URL、headers、Cookie、body、主要なフラグを復元します。
  • fetch の解析は DevTools の標準形式に対応し、URL・method・headers・body を抽出します。
  • JSON body は自動的に整形され、原文との切り替えでそのままコピーできます。
  • Cookie のチェックには SameSite=None と Secure の組み合わせ、__Host- および __Secure- プレフィックスの制約が含まれます。
  • レスポンスのチェックは HSTS、Content-Security-Policy、X-Content-Type-Options、Referrer-Policy を対象にしています。

活用シーン

HTTP に関わる日常作業のいくつかを、手作業の写し直しなしで進められます。

  1. 本番のリクエストをローカルスクリプトに移す

    DevTools から cURL や fetch をコピーし、Python requests、Go、Java OkHttp に変換して、自動化スクリプトや回帰テストの出発点にします。

  2. API 不具合の調査

    プロキシから取り出した生メッセージを貼り付け、headers・ステータス・Set-Cookie・body を 1 項目ずつ確認して、バックエンドとクライアントで食い違うフィールドを特定します。

  3. レスポンスのセキュリティ設定確認

    HSTS、CSP、X-Content-Type-Options が揃っているかをベースラインで点検し、より詳細なセキュリティ評価に進むかを判断します。

  4. 多言語 API ドキュメントの同期

    同じ例リクエストを cURL・HTTPie・fetch・axios・Python・Go などに同時に書き出し、言語ごとに手書きで揃える手間をなくします。

  5. Cookie の編集と再生

    Cookie ヘッダーを 1 項目ずつ分解し、Domain・Path・SameSite を調整したうえで再構築し、ブラウザーやスクリプトに貼り直して挙動を再現します。

  6. チーム共有用のサンプル整備

    実際のトラフィックを 1 本の cURL や .http ファイルに整え、フロントエンド・バックエンド・QA・SRE が同じサンプルから調査を始められるようにします。

関連情報

同じキャプチャに読み取りづらい User-Agent が混ざっている場合は、 User-Agent パーサー でブラウザー・OS・デバイス・ボットの兆候に分解できます。Query が二重エンコードされていたりリダイレクトが長く連なっている場合は、 URL ツール で各要素を分解し、トラッキングパラメータを除去できます。Authorization ヘッダーや Cookie に JWT が含まれていれば、 JWT インスペクター で payload をデコードし、署名を確認したうえで内容を扱えます。

使い方のヒント

メッセージはテキストで、目視は漏れます。構造化ビューに最初のチェックを任せ、必要に応じて原文に戻って確認しましょう。

  • cURL をコピーするときはマルチライン形式の方がフラグの境界が安定しやすく、解析も安定します。
  • 共有やスクリーンショットの前に、構造化ビューで Cookie・Authorization など機密項目をマスクしてください。
  • 2 つのレスポンスを比較する場合は、Body を整形してから JSON 差分ツールに渡すと、空白やキー順に惑わされません。
  • レスポンス系のヘッダーヒントは基礎信号にすぎません。重要な資産には別途、本格的なセキュリティレビューが必要です。
  • 本番の Cookie や token を、このページを含むオンラインツールに長く置かないでください。使い終わったら入力欄をクリアします。
  • エクスポートしたコードに含まれるサンプルドメインやプレースホルダー token は、コミット前に環境変数や実値に置き換えてください。

制限事項

このツールが扱わない範囲を把握しておくと、プロキシやスキャナーの代わりに使ってしまう事故を避けられます。

  • ネットワークリクエストは一切送信せず、貼り付けたテキストを解析するだけです。トラフィックのキャプチャや再送には使えません。
  • TLS ハンドシェイクや HTTP/2、HTTP/3 のフレーム構造は解析対象外で、入力は可読なメッセージである必要があります。
  • gzip や brotli で圧縮された body は自動展開しません。事前にプロキシ側で展開してください。
  • レスポンスヘッダーのチェックは基礎的なヒントであり、本格的なセキュリティレビューや侵入テストの代替にはなりません。
  • fetch の解析は DevTools が出力する標準形式に合わせています。手書きや高度にラップされたコードは完全には解析できない場合があります。

よくある質問

判別、Cookie の扱い、エクスポートの正確さ、データの所在に関するよくある質問です。

形式を先に切り替える必要はありますか？

不要です。デフォルトの自動判別が 1 行目を見て 生 HTTP・cURL・fetch を判別します。誤判別の場合は上部のツールバーから手動で指定してください。

生 HTTP メッセージに必要な要素は？

リクエストには少なくともリクエスト行（例: GET /path HTTP/1.1）と Host ヘッダーが必要です。レスポンスには少なくともステータス行（例: HTTP/1.1 200 OK）が必要で、headers と body は空行 1 行で区切られます。

エクスポートした fetch や axios のコードはそのまま動きますか？

メソッド、URL、headers、body は保持されているので出発点としては十分です。投入する前に、認証方式・エラー処理・環境変数をプロジェクトの規約に合わせて調整してください。

Set-Cookie はどう扱われますか？

行ごとに名前・値・属性へ分解して表示し、SameSite=None と Secure の組み合わせや __Host- プレフィックスの要件など、よくある問題をヒントとして提示します。

貼り付けたデータは送信されますか？

送信されません。判別・解析・変換はすべてブラウザー内で完結し、メッセージや Cookie がこのページから外に出ることはありません。

レスポンスで cURL エクスポートが空になるのはなぜ？

cURL、fetch、axios はリクエストを表す形式です。レスポンスにはリクエスト行を再構築するための情報が不足するため、レスポンス時のエクスポートは生 HTTP のみが利用できます。

関連ツール

ネットワーク関連の作業を続けましょう。User-Agent の解析、URL の整理、Authorization から取り出した JWT のデコードに進めます。