クエリ文字列

JSON

クエリ文字列から JSON は何をするツール?

左側にクエリ文字列を貼り付けます — 先頭の ? は付けても付けなくてもかまいません — すると右側に JSON オブジェクトが埋まります。値はその過程で URL デコードされ(なので customer=Ava%20Chen は "customer": "Ava Chen" になります)、同じキーが複数回現れた場合は JSON 配列にまとめられます。最後のところは、その場しのぎの文字列分割では大体間違える部分で、このページが存在する理由でもあります。

解析にはブラウザ組み込みの URLSearchParams を使っています。これはあらゆるモダンな Web フレームワークで request.query を支えているのと同じものです。URLSearchParams は WHATWG URL Standard の application/x-www-form-urlencoded ルールに従います。これはフォームが POST する際にブラウザが送るのと同じ形式です。出力はその後 JSON.stringify で RFC 8259 に従ってシリアライズされます。

すべてブラウザ内で動きます。入力が完全な URL であってもページは寛容で、クエリ部分を抜き出してくれます。URL のコンポーネント自体(ホストやパスなど)が欲しいなら URL から JSON を使ってください。JSON を残さずパラメータをただ眺めたいだけなら URL Parser ページの方が向いています。ここで関係するパーセントエンコードのルールは RFC 3986 §2.1 で定義されています。

クエリ文字列を JSON に変換する方法

3 ステップ。それぞれがこのページのボタンに対応しています。

クエリ文字列を貼り付ける

クエリ文字列を左パネルに入れます。先頭に ? が付いていてもかまいません — パーサーが取り除きます。サンプルをクリックすると、パーセントエンコードされた値、ブラケット記法、繰り返しの tag キーを含む現実的な EC のフィルター URL が読み込まれます。サンプル:

?customer=Ava%20Chen&status=active&total%5Bgte%5D=49.99&page=2&tag=premium&tag=verified

<code>https://shop.example.com/orders?...</code> のような完全な URL を貼り付けてもよく、ページがクエリ部分を抜き出してくれます。

JSON オブジェクトを読む

右パネルは入力するそばから更新されます。各パラメータがキー、値はデコード済みで、繰り返しのキーは配列になります。なので上のサンプルは "customer": "Ava Chen"、"total[gte]": "49.99"、そして "tag": ["premium", "verified"] を生成します。数値も文字列のままです — クエリ文字列には型情報がないので、勝手に変換するとバグを隠すだけです。

コピー、ダウンロード、または圧縮

コピーで JSON をクリップボードへ、ダウンロードで querystring.json として保存、圧縮で 1 行にまとめます。クリアは入力パネルをリセットします。

実際にこれが必要になる場面

リクエストログのデバッグ

サーバーログにはリクエスト行がそのまま、クエリ文字列ごとダンプされます。ある顧客の検索で何も返ってこなかった理由を追っているとき、ログから ?customer=Marco%20Rivera&status=cancelled&date_from=2026-04-01&date_to=2026-04-30 をこのページにコピーする方が、各値を頭の中で URL デコードするより早いです。JSON にすれば実際のフィルター値が一目瞭然になります。

実トラフィックからテストフィクスチャを生成する

12 個のクエリパラメータを取るエンドポイントに対するテストを書いているとします。本番から実際の URL を取り、クエリ文字列をここに貼り付けて、得られた JSON をテストのパラメータオブジェクトとして使います。実際の名前、実際の形、実際に拾えるバグ — 頭の中で customer: "ORD-1001" を作るより遥かに優れています。

クエリ文字列の規約間で移行する

スタックによって配列のエンコード方法が違います — ?tag=red&tag=blue、?tag[]=red&tag[]=blue、?tag=red,blue。最初に JSON に変換すれば中立的な中間形式になります。そこから先、目的の規約に変換するのは正規表現の考古学ではなく 5 行のスクリプトで済みます。

OAuth、Webhook、解析コールバック

OAuth コールバックは ?code=abc&state=xyz として戻ってきます。Stripe や GitHub のようなサービスからの Webhook URL はクエリ文字列にメタデータを詰め込みます。解析リダイレクトは UTM やトラッキングパラメータをドカドカ重ねます。クエリ部分だけをここに貼り付ければ、ホストを先に剥がさなくてもパラメータオブジェクトに直行できます。

よくある質問

先頭の疑問符は付けないといけない?

いいえ — 付けても付けなくても貼り付けてください。パーサーは先頭の ? があれば取り除きます。https://api.shop.example.com/orders?customer=Ava%20Chen のような完全な URL を貼り付けても、ページがクエリ部分を抜き出してくれます。

繰り返しのキーはどう扱われる?

JSON 配列にまとめられます。なので ?tag=premium&tag=verified は "tag": ["premium", "verified"] になります。これは URLSearchParams.getAll() の挙動、および Express、FastAPI、ASP.NET、Spring がクエリ文字列を解析する方法と一致します。

?debug や ?dry-run のような値なしのキーは?

空文字列になります — "debug": ""。URLSearchParams は WHATWG URL Standard に従って、= のないキーを key= と同じものとして扱います。本物の真偽値が必要なら、obj.debug = "debug" in obj のような後処理で JSON を加工してください。

?items[]=1&items[]=2 のようなブラケット記法は?

ブラケットはキーの一部として残ります — 出力には "items[]": ["1", "2"] と表示されます。これは送信されたバイトに対して正直な表現です。フレームワーク(PHP、Rails、qs.js)側でブラケットを取り除いたりネストしたオブジェクトに展開したりする必要があるなら、後処理ステップとして行ってください。

数値や真偽値に見えても、なぜすべての値が文字列なの?

クエリ文字列には型情報がないからです。?count=5 も ?count=true もただのテキストです。数値や真偽値に自動変換すると、ハッピーパスのサンプルでは綺麗に見えますが、顧客名が "1" だったり誰かが ?id=007 と書いた瞬間に静かなバグを生みます。出力は文字列のままにしておき、スキーマを知っているあなたのコードで変換してください。

Unicode と絵文字はどう扱われる?

きれいに扱えます。URLSearchParams はバイトをパーセントデコードし、それを UTF-8 として解釈します — なので ?name=%E4%B8%AD%E6%96%87 は "name": "中文" になり、?reaction=%F0%9F%94%A5 のような絵文字は "reaction": "🔥" になります。JSON.stringify は次に RFC 8259 §7 に従ってエスケープが必要なものをエスケープします。

その他の URL & JSON ツール

クエリ文字列のデコードは一つの操作です。組み合わせて使えるものを紹介します: