検索画面や一覧APIでは、URLのクエリパラメータが長くなりがちです。
ブラウザのアドレスバーだけで読むと、どの条件が入っているのか、値がエンコードされているのかを見落としやすくなります。

こんな場面で使う

たとえば、検索画面で次のようなURLを共有されたとします。

https://example.com/users?status=active&role=admin&keyword=%E6%9D%B1%E4%BA%AC&page=2&limit=50

URL Params to JSON ツールにクエリ文字列を貼り付けると、条件をJSONとして確認できます。

{
  "status": "active",
  "role": "admin",
  "keyword": "東京",
  "page": "2",
  "limit": "50"
}

この状態にすると、検索条件をSlackやIssueに貼るときも読みやすくなります。

再現条件:
- status: active
- role: admin
- keyword: 東京
- page: 2
- limit: 50

ブラウザのURLをそのまま貼るより、どの条件で再現したかが伝わりやすく、問い合わせ対応やバグ調査の往復を減らせます。

調査が楽になる理由

JSONにすると、レビューや問い合わせ対応で「この条件で再現した」と共有しやすくなります。
また、keyword のようにURLエンコードされた値も見やすくなるため、検索条件の取り違えに気づきやすくなります。

APIの仕様書やテストケースに貼るときも、クエリ文字列のままより差分が見やすくなります。

実例：配列パラメータと空文字を確認する

検索UIでは、複数選択や未入力の条件がURLに混ざることがあります。

?tag=frontend&tag=api&keyword=&sort=created_at%3Adesc

JSONとして見ると、次の点を確認できます。

{
  "tag": ["frontend", "api"],
  "keyword": "",
  "sort": "created_at:desc"
}

ここでは tag が複数値として扱われるか、keyword の空文字を送ってよいか、sort のコロンが正しくデコードされているかが確認ポイントです。バックエンドが tag=frontend,api を期待しているのにフロントエンドが tag を複数回送っている、といった仕様差も見つけやすくなります。

確認したいポイント

  • 空文字のパラメータが意図したものか
  • page や limit が想定値になっているか
  • 日本語や記号が正しくデコードされているか
  • 同じキーが複数回出る仕様かどうか
  • フロントエンドのフィルタ状態とURLが一致しているか

関連ツール