HTTPクッキー解析ツール

GeekFormat について

HTTP Cookie パーサー

ブラウザから送信された Cookie ヘッダーを解析し、キーと値のペア、URL エンコーディング、重複名をすぐに表示します。

解析結果

4 個の Cookie

#1session

元の値: abc123

デコード値: abc123

#2theme

元の値: dark

デコード値: dark

#3locale

元の値: zh-CN

デコード値: zh-CN

#4callback

元の値: https%3A%2F%2Fgeekformat.com%2Fdone

デコード値: https://geekformat.com/done

JSON プレビュー

[
  {
    "index": 0,
    "raw": "session=abc123",
    "name": "session",
    "value": "abc123",
    "decodedValue": "abc123"
  },
  {
    "index": 1,
    "raw": "theme=dark",
    "name": "theme",
    "value": "dark",
    "decodedValue": "dark"
  },
  {
    "index": 2,
    "raw": "locale=zh-CN",
    "name": "locale",
    "value": "zh-CN",
    "decodedValue": "zh-CN"
  },
  {
    "index": 3,
    "raw": "callback=https%3A%2F%2Fgeekformat.com%2Fdone",
    "name": "callback",
    "value": "https%3A%2F%2Fgeekformat.com%2Fdone",
    "decodedValue": "https://geekformat.com/done"
  }
]

Cookieリクエストヘッダーを専門に分解し、属性は推測せず「このリクエストで実際に何が送信されたか」だけに答えます。

HTTPクッキー解析ツールとは？

HTTPクッキー解析ツールは、`Cookie:`リクエストヘッダーと`document.cookie`文字列に特化したデバッグツールです。これが解決する核心的な問題は「Cookieとは何か」ではなく、開発者、テストエンジニア、クローラーエンジニア、運用担当者が連携時に最もよく直面する現実のシナリオです。つまり、ブラウザが実際にどのクッキーを送信したか、特定のCookie値がURLエンコードされているか、同名のCookieが重複していないか、そして現在のCookieヘッダーをcurl、Postman、スクリプトにそのままコピーして問題を再現するにはどうすればよいかということです。

`Set-Cookie`レスポンスヘッダーとは異なり、HTTPリクエストヘッダーのCookieはフラットな`name=value`のリストです。これは「現在のリクエストで実際に何が送信されたか」を示すだけで、SameSite、HttpOnly、Secure、Path、Domain、Expires、Max-Ageなどの属性情報は含まれません。だからこそ、「APIがログイン状態を認識しないのはなぜか」「ブラウザのリクエストにどのクッキーが欠けているのか」「document.cookieのこの値が文字化けしているのはなぜか」を調査する際、リクエストヘッダー解析ツールは汎用的なCookieツールよりも直接的です。

この種のツールの最も一般的で低レベルな実装は、単純な`split(';')`で文字列を分割してレンダリングするだけですが、実際のデバッグでは分割するだけでは不十分です。値がURLエンコードされているか、重複する名前が存在するか、正規化されたヘッダーの内容を直接コピーできるか、解析結果をスクリプトやドキュメントで再利用できるかを知る必要があります。現在のページは、これら開発者の実際のアクションを中心に設計されています。

確認したいのが「リクエストに何が含まれているか」ではなく「サーバーから配信されたSet-Cookieがなぜブラウザに拒否されたのか」である場合は、このページに留まらず、レスポンスヘッダーの属性チェックに適した「Set-Cookie解析ツール」に移動してください。したがって、このツールの位置づけは明確です。Cookieリクエストヘッダー/document.cookieのデバッガーであり、レスポンスヘッダーの属性監査ツールではありません。

ユースケース

ログイン状態の喪失やセッション異常をトラブルシューティングする際に、リクエストヘッダーに含まれるクッキーを確認する
URLエンコードされたクッキーをデバッグする際に、元の値とデコード値を比較して実際の内容を確認する
複数の同名クッキーがブラウザやサーバーの処理異常を引き起こしていないかチェックする
ブラウザのCookieヘッダーをすばやく正規化してPostman、curl、スクリプトにコピーし、リクエストを再現する
document.cookieの出力結果を分析し、フロントエンドから現在見えるクッキーのセットを確認する

使い方

Cookieリクエストヘッダーまたはdocument.cookie文字列を入力エリアに貼り付ける
各クッキーの名前、元の値、URLデコード値を確認する
重複名の通知と正規化されたCookieヘッダーの結果を確認する
正規化Cookieヘッダーをコピーするか、JSONプレビューを表示してさらにデバッグを進める

特徴

複数クッキーの自動分割：セミコロンで区切ってCookieリクエストヘッダーとdocument.cookie文字列を項目ごとに解析
デュアル値表示：元の値とURLデコード値を同時に表示し、エンコードの問題をすばやく特定
重複名検出：同名クッキーを自動的に識別し、潜在的な競合を通知
正規化出力：ワンクリックで正規化されたCookieリクエストヘッダーをコピーし、APIデバッグを継続可能
JSONプレビュー：解析結果を構造化して出力し、スクリプト、ログ、テストツールで利用可能
ローカル処理：入力内容はブラウザ内でのみ解析され、サーバーにアップロードされない

このページと他の2つのCookieツールの使い分け方

手元にあるのがリクエストヘッダー、document.cookie、それともサーバーのSet-Cookieレスポンスヘッダーかを確認してから、使用するページを決めてください。

ツール	適した入力	最適な用途	主な強み
HTTPクッキー解析ツール（現在のページ）	Cookieリクエストヘッダー、document.cookie	リクエストに実際に含まれているクッキーの確認、値のエンコード状態のチェック、重複名の検出	リクエストヘッダーの分解、正規化コピー、URLデコード、重複検出に特化
Set-Cookie解析ツール	サーバーから返されるSet-Cookieレスポンスヘッダー	ブラウザがクッキーを受け入れない原因の調査、SameSite/Secure/HttpOnly/Path/Domainのリスク確認	属性の分解がより詳細で、セキュリティ設定のアラートを提供Set-Cookie解析ツールを開く
クッキー解析ツール	Cookie文字列とSet-Cookieが混在するデバッグシナリオ	データの出所が不明確な場合や、統合的なエントリーポイントからすばやく振り分けたい場合	デュアルモード切り替えに対応し、Netscape Cookie Fileのエクスポートをサポートクッキー解析ツールを開く

Best Practices

リクエストヘッダーとレスポンスヘッダーを混同しない

テキストがブラウザDevToolsのRequest Headers、キャプチャツールのリクエスト、document.cookie、サーバーログのCookieヘッダーから取得したものであれば現在のページが適しています。Response HeadersのSet-Cookieから取得したものであれば、ここで属性の問題を分析し続けないでください。

元の値を保持してからデコード値を確認する

Cookieの問題を調査する際は、デコード後の内容だけに注目しないでください。元の値こそが実際に送信された値であり、デコード値は読みやすさのための補助に過ぎません。署名、Base64、JWT、二重エンコードのシナリオでは、元の値が特に重要です。

JWTツール

重複名を見つけても急いで削除しない

重複するクッキーは、特にPath/Domainの違い、環境の切り替え、過去の書き込みの残存時に、問題の根本原因である可能性があります。重複項目を保持して記録してから、ブラウザの動作とサーバーの設定を照合してください。

リクエストを再現する際は正規化ヘッダーを優先的にコピーする

現在のCookieヘッダーをcurl、Postman、テストスクリプトに渡して再現する必要がある場合は、正規化された結果を直接コピーすることで、余分なスペース、改行、フォーマットノイズによる再現のずれを減らすことができます。

curlコード変換

よくある質問

このページはどのようなCookie入力の解析に適していますか？

Cookieリクエストヘッダーと`document.cookie`形式のフラットな文字列（例: `session=abc123; theme=dark`）の解析に特化しています。サーバーから返される`Set-Cookie`レスポンスヘッダーをお持ちの場合は、付属の「Set-Cookie解析ツール」に切り替えてください。リクエストヘッダーのCookieにはSameSite、HttpOnly、Secure、Path、Domainなどの属性情報が含まれていないためです。

Set-Cookie解析ツール

Cookie値が文字化けして見えるのはなぜですか？

多くのCookie値はURLエンコードされています。例えば`%3D`は`=`、`%2F`は`/`を表します。このツールは元の値とURLデコード後の値の両方を表示するため、読みにくいエンコード文字列だけでなく、実際の内容をすばやく確認できます。

重複するCookie名を検出する理由は何ですか？

同名のCookieは異なるPath、異なるDomain、または過去の書き込みの残存によって発生する可能性があります。リクエストヘッダーではフラットな`name=value`の羅列に過ぎませんが、重複する名前はブラウザの動作やサーバー側の処理に不整合を引き起こすことが多いため、ツールは黙って上書きするのではなく、積極的に通知します。

ログイン状態やセッションの問題のトラブルシューティングに適していますか？

適しています。ブラウザのリクエストで実際に送信されているCookieヘッダーを貼り付けると、各クッキーの名前、元の値、デコードされた値を一目で確認でき、特定のセッションフィールドが欠けていないか、値が正しくエンコードされているか、同名のCookieが混乱を引き起こしていないかをすばやく特定できます。

解析結果はAPIデバッグに直接使用できますか？

できます。ツールは正規化されたCookieヘッダーを生成するため、curl、Postman、スクリプト、APIデバッグプラットフォームにワンクリックでコピーして問題を再現できます。また、ログ、Issue、テストケースの記録用にJSONプレビューもサポートしています。

なぜこのページにはSameSite、HttpOnly、Secureが表示されないのですか？

これらの属性は`Set-Cookie`レスポンスヘッダーにのみ存在し、ブラウザがその後送信する`Cookie`リクエストヘッダーには含まれません。現在のページは「リクエスト時に実際に何が送信されたか」に焦点を当てており、「サーバーが当初何を設定したか」ではありません。

document.cookieとCookieリクエストヘッダーは同じものですか？

両者はよく似ており、どちらも`name=value; name2=value2`のフラットな構造ですが、違いもあります。`document.cookie`ではHttpOnlyクッキーを読み取れませんが、リクエストヘッダーのCookieはブラウザが現在のスコープに基づいて自動的に付与する最終的なセットです。この解析ツールは両方のタイプのフラットな入力を処理するのに適しています。

貼り付けたCookieはサーバーにアップロードされますか？

いいえ。現在のページの解析、URLデコード、重複検出、JSONプレビューはすべてブラウザローカルで完結し、Session、Token、ログイン状態のクッキーやユーザーデータがいかなるサーバーにも送信されることはありません。

用語集

Cookieリクエストヘッダー: ブラウザがHTTPリクエストで自動的に送信するクッキーの名前と値のペアの集合で、通常は`name1=value1; name2=value2`の形式です。現在のリクエストで実際に送信されたクッキーを反映しており、セキュリティ属性は含まれません。Set-Cookie解析ツール
document.cookie: フロントエンドのJavaScriptが読み取り可能なクッキー文字列のインターフェースです。通常、リクエストヘッダーのCookieと構造は似ていますが、HttpOnlyクッキーを読み取ることはできず、完全なSet-Cookie設定を逆算することもできません。
URLエンコードされたCookie値: 特殊文字を安全に送信するためにパーセントエンコーディングされたCookie値で、例えば`%3D`、`%2F`、`%3A`などがあります。デバッグ時には元の値とデコード後の値の両方を確認することが一般的です。URLエンコードツール
重複するCookie名: 同じリクエストヘッダー内に複数の同名クッキーが存在することです。異なるPath、異なるDomain、または古い値の残存によって発生する可能性があり、セッションの異常や動作の不整合の重要な手がかりとなることがよくあります。
正規化されたCookieヘッダー: 入力内容をクリーニングして再構成した規格準拠の`name=value; name2=value2`文字列で、curl、スクリプト、Postman、ログにコピーして問題を再現しやすくしたものです。

CookieリクエストヘッダーとSet-Cookieレスポンスヘッダーの比較表

Cookieデバッグの誤解の多くは、リクエストヘッダーとレスポンスヘッダーを混同して見ることから生まれます。

比較項目	Cookieリクエストヘッダー	Set-Cookieレスポンスヘッダー
出現場所	ブラウザからサーバーへのリクエスト内	サーバーからブラウザへのレスポンス内
典型的な形式	name1=value1; name2=value2	name=value; Path=/; HttpOnly; Secure
属性を含むか	含まない	SameSite/Path/Domain/Expires/Max-Ageなどを含む
調査に適した内容	リクエストに実際に何が含まれているか	ブラウザがクッキーを受け入れない理由
より適したツール	現在のページ	Set-Cookie解析ツール

Cookieリクエストヘッダーデバッグのよくある問題対照表

手元にあるのがリクエストヘッダーのCookieの場合、これらの問題が最も頻繁に発生します。

症状	高確率の原因	優先して確認すること
APIがログイン状態を認識しない	リクエストに対象のクッキーが含まれていないか、名前と値が一致しない	正規化されたCookieヘッダーに対象のセッションフィールドが存在するか最初に確認
Cookie値が文字化けしている	値がURLエンコードされている	元の値とデコード値を同時に比較
環境によって動作が異なる	重複するCookie名、古い値の残存、ブラウザのスコープ選択の違い	重複名の通知を確認し、すべての同名項目を記録
スクリプトでの再現に失敗する	コピー時に余分なスペース、改行、フォーマットノイズが混入	正規化されたCookieヘッダーを使用して再コピー

Privacy & Security

Cookieリクエストヘッダーの解析、URLデコード、重複検出、JSONプレビューはすべてブラウザローカルで完結します。入力されたSession、Token、ログイン状態のクッキーはいかなるサーバーにもアップロードされません。