すべての処理はブラウザ内で実行されます — ファイルや入力はサーバへ送信されません。
完全な URL(`https://example.com/?a=1&b=2#frag`)、あるいはクエリ文字列だけ(`?a=1&b=2` や `a=1&b=2`)を貼り付けてください。パーサが編集可能なキー / 値の行に分解します。ペアを追加・削除・改名すると、下部の再構築されたクエリ文字列がリアルタイムで更新されます。「+ for spaces」をオンにすると HTML フォーム形式(`+ = スペース`、`URLSearchParams.toString()` の出力形式)、オフにすると厳格な RFC 3986 形式(`%20 = スペース`、現代の API が好む形式)を切り替えられます。
アナリティクス、リダイレクトチェーン、アフィリエイト URL のデバッグに使ってください。UTM タグ・セッションキー・トラッキング ID の長い羅列が、テーブルとして読めるようになります。欠けているパラメータを足したり、キーのタイポを直したり、リンクを共有する前にトラッキングのゴミを取り除き、整理された結果をコピーし直せます。フラグメント(`#…`)はクエリ層に属さないため取り除かれます。処理はすべてネイティブ URL / URLSearchParams API でブラウザ内完結なので、トークンやセッション ID を含むリンクもマシン外には出ません。
https://shop.example.com/products?utm_source=newsletter&utm_medium=email&utm_campaign=spring_sale&product_id=42&ref=alice
utm_source newsletter utm_medium email utm_campaign spring_sale product_id 42 ref alice
5 個のクエリ文字列が、スキャンと編集ができる綺麗なテーブルになります。リンクを共有する前にトラッキング系を削るなら、`utm_*` の 4 行と `ref` を削除し、再構築されたクエリをコピーしてください。残るのは `?product_id=42` だけです。
?tag=react&tag=typescript&tag=performance&page=2
tag react tag typescript tag performance page 2
同じキーの繰り返しは、「このフィルタが複数の値を持つ」ことを表す URL の標準的な慣例です(検索ファセット、複数選択ドロップダウンなど)。バックエンドフレームワークによって露出方法が異なります。Express では `req.query.tag = ["react", "typescript", "performance"]`、Rails では `params[:tag] = "performance"`(最後の 1 つだけ。`tag[]=` 形式を書かない限り)、Django では `request.GET.getlist('tag')` といった具合です。パーサは順序を保持するので各行を点検できます。
query (raw): q=hello world&lang=ko plusForSpaces: off
q=hello%20world&lang=ko
「+ for spaces」をオフにするとスペースが `%20` になり、`application/x-www-form-urlencoded` の厳格な変種と一致します。さまざまなクライアントを跨ぐ予測可能なエンコードが必要なときに使ってください。古い PHP や特定の Java サーブレットなど、`+` の解釈をフォームボディに対してのみ正しく行い、クエリ文字列では誤るバックエンドがあります。
どちらもクエリ文字列内で有効ですが、出自が異なります。`%20` は RFC 3986 の汎用的なスペースのパーセントエンコードで、どこでも動きます。`+` は `application/x-www-form-urlencoded` の慣例で(元々 1990 年代の HTML フォーム由来)、多くのクエリパーサで動きますが厳密にはフォームボディ用です。現代の指針は、両端を制御するなら `%20` を出力し、受信側は両方を許容することです。JavaScript の `URLSearchParams.toString()` は常に `+` を吐くため、世の中に手書きの代替実装がたくさんあるのはこのためです。
4 つの慣例があり、いずれも普遍ではありません。**重複キー**(`?tag=a&tag=b`)が最もポータブルで本ツールが出力する形式です。すべてのパーサが扱えます。**ブラケット記法**(`?tag[]=a&tag[]=b`)は PHP の慣例で、Rails も同じ形式を採用しました。**インデックス付き**(`?tag[0]=a&tag[1]=b`)はまれですが、一部の Rails フォームで使われます。**カンマ区切り**(`?tag=a,b`)は OpenAPI 3 の `style: form, explode: false` の出力です。サーバが期待する形式を選んでください。1 つの URL で混在させるとバグになります。
いいえ。本ツールはクエリ層のみを切り出します。完全な URL を貼り付けると、クエリだけを抽出し、スキーム・ホスト・パス・フラグメントを落とし、`key=value&…` の部分だけを再構築します。完全な URL を貼り付け→編集→再構築したい場合は、再構築されたクエリをコピーしてパスに手で連結する(`/products?` + 結果)か、URL のすべての構成要素を扱える URL パースツールを使ってください。
消えません。値が空でも `key=` の行は保持されます。ただし、キーが完全に空の行は再構築時に削除されます。`=value` のようにキーがない形は主要なパーサで意味が定義されていないためです。「`flag` の値が空文字列」を表したい場合は、キーを入れて値セルを空のままにしてください。「`flag` パラメータは存在するが値はない」を表したい場合も値を空のままで構いません。多くのパーサが両者を同じものとして扱います。
はい。エディタは挿入順を保持し、再構築は上から下へ行を辿ります。RFC 3986 は特定の順序を要求しないため、ほとんどのサーバは `?a=1&b=2` と `?b=2&a=1` を同一として扱います。ただしキャッシュレイヤ(CDN のキャッシュキー)、Webhook の署名検証、人間によるレビューでは、安定した順序が好まれることが多いです。AWS Signature v4 や OAuth 1.0a は署名前にパラメータをソートすることを明示しています。そういった署名を再現したい場合は、コピー前に行をソートしてください。
URL Encoder は単一の文字列を扱い、ブロブとしてエンコードかデコードを行います。Query String Parser は *構造* を扱い、キー / 値の行に分解して編集し、再構築します。リダイレクト先やトークンなど単一の値を URL に貼り付ける前にエスケープしたい場合は URL Encoder、入力がクエリ文字列全体で個別パラメータを点検・修正したい場合は本ツールを使ってください。
URL のクエリ文字列とは、`?` の後ろから `#` の前までを指し、RFC 3986 §3.4 では不透明なバイト列として定義されています。「`&` で区切られたキー / 値のペア」という慣例は URI 仕様ではなく、HTML フォーム送信と `application/x-www-form-urlencoded` メディアタイプから来ています。ほとんどのサーバとブラウザがフォーム形式をデフォルトとして採用していますが、URI 仕様はそれを要求しません。すべてのフレームワークが微妙に挙動の異なる独自パーサを同梱し続けているのはこのためです。
大きな揺れは **スペースのエンコード** です。form-urlencoded は `+` を、RFC 3986 のパーセントエンコードは `%20` を使います。`URLSearchParams.toString()` は `+` を吐き、WHATWG URL Standard はそれを必須とし、ほとんどのブラウザがそれに従います。`encodeURIComponent` は `%20` を吐きます。受信側はたいてい両方を許容し、送信側がどちらかを選びます。リクエストの署名時は要注意で、AWS Signature v4 は `%20`、OAuth 1.0a も `%20` を要求するため、`+` を吐くと署名検証が静かに失敗します。
クエリ文字列の周辺には 4 つの隣接概念があります。**ハッシュフラグメント**(`#…`)はサーバに送信されません。ブラウザ内にのみ存在し、シングルページアプリのクライアント側ルーティングに使われます。紛らわしいことに、古いコードではフラグメント内からクエリパラメータを切り出すものもあります(`#?a=1`)。**フォームエンコード**(`application/x-www-form-urlencoded` の POST ボディ)はクエリ文字列と同じ構文で、置き場所がボディに移っただけです。両者で同じパーサが使えます。**Cookie のパース** はまったく別のルール(区切りは `;`、既定でパーセントエンコードなし)です。**JSON リクエストボディ** は 2010 年頃から多くの POST / PUT API でクエリ文字列を置き換えましたが、GET ではブックマーク可能・キャッシュ可能・コピー & ペースト可能という性質が効いて、依然としてクエリ文字列が主流です。
パラメータがありません — URL を貼り付けるか追加してください。
—