設定 (JSON)

URL

URL ビルダーとは？

URL の各部分（プロトコル、ホスト、パス、クエリパラメータ、ハッシュ）を記述した JSON オブジェクトを渡すと、ツールは適切にパーセントエンコードされた URL を返します。内部ではブラウザのネイティブ URL API を使うので、自分で JavaScript で URL を構築した場合とまったく同じ出力になります。

これが存在する理由はシンプルで、URL を手で組み立てるとバグが潜むからです。顧客名のスペースをエンコードし忘れる、すでにエンコードされたスラッシュを二重エンコードしてしまう、? と & を取り違える、+ を %20 の代わりに使ってしまい値が消える。WHATWG URL 仕様は各入力に対する正解を一つだけ定めており、ここで得られるのはまさにそれです。繰り返しクエリキー（例: tag=red&tag=blue）は配列を渡すことでサポートされ、URLSearchParams が受け付ける形と同じです。

すべてブラウザ内で動きます。JSON 設定も組み立てた URL もマシンから出ません。エンコード規則は RFC 3986 と、その上に積まれた WHATWG の改訂から直接来ています。構造化されたフォームを通して URL を往復させたいときは URL パーサーと組み合わせてください。

URL ビルダーの使い方

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

JSON 設定を貼り付ける

左側に URL の各部分を記述した JSON オブジェクトを貼り付けます。protocol と host は必須、それ以外は任意です。複数のクエリパラメータとハッシュを含む現実的な例を読み込むには サンプル をクリック:

{
  "protocol": "https",
  "host": "api.shop.example.com",
  "pathname": "/v1/orders",
  "searchParams": {
    "customer": "Ava Chen",
    "status": "active",
    "total[gte]": "49.99",
    "page": "2"
  },
  "hash": "summary"
}

任意フィールド: port、username、password、hash。searchParams の中では、文字列は値ひとつ、配列は繰り返しキーになります。

組み立てられた URL を読む

右パネルに組み立てた URL 文字列が表示されます。クエリ文字列ではスペースが +、角括弧は %5B/%5D、パスは正規化されます。これは URL 標準が定めるエンコードと同じです。入力中にリアルタイムで更新されます。

コピーまたはダウンロード

コピー をクリックして URL をクリップボードに送るか、ダウンロード でテキストファイルとして保存できます。やり直すには入力パネルの クリア を使ってください。

実際にこれを使う場面

HTTP クライアントのテストフィクスチャ作成

/v1/orders を 8 個のクエリパラメータで叩くテストを書いていて、そのうち 2 つにスペースが入り、1 つは繰り返しがある。エンコード済み URL をテストに手で打ち込むのはミスを生みます。実際のリクエストログからコピーできる JSON オブジェクトから組み立て、結果の URL をアサーションに貼り付ける。それで終わり。

OAuth 認可 URL の構築

OAuth 認可 URL は client_id、redirect_uri、scope、state、response_type、code_challenge をクエリ文字列に詰め込みます。RFC 6749 はこれら正確な名前と、URL 全体が再エンコードされる前にすでに一度エンコードされた redirect_uri を要求します。ビルダーはそれを透過的に処理してくれるので、生の値を渡せば正しいことをやってくれます。

スクリプトでのアナリティクス／共有 URL 生成

UTM パラメータを含むキャンペーン URL を生成するとき、値はしばしばスプレッドシートから来ます。utm_campaign にはスペース、アンパサンド、たまに絵文字が含まれます。文字列テンプレートよりも URL コンストラクタにエンコードを任せるほうが安全です。出力は Node の URL モジュールと同一になります。

サポートチケットからのバグ再現

顧客から「q=résumé writer での検索が API で 500 を返す」と報告されました。同じリクエストを再現したい。JSON から URL を組み立てて、curl で叩く。e のアクセントもスペースも、ブラウザが送ったのと同じ形でエンコードされます — 推測なし。

よくある質問

URL ビルダーと自分で文字列を連結するのは何が違う？

エンコードです。https://api.example.com/orders?customer=Ava Chen は有効な URL ではありません — スペースが壊しています。ビルダーは内部で URLSearchParams を使い、そのスペースをクエリでは +、パスでは %20 としてエンコードします。手書きの文字列連結は遅かれ早かれどちらかを間違えます。

クエリパラメータを 2 回送るには（例: ?tag=red&tag=blue）？

値に配列を使ってください: "tag": ["red", "blue"]。ビルダーは指定した順で tag=red&tag=blue を出力します。これは URLSearchParams 仕様に一致します。

プロトコルの後のコロン（https:）は付ける？それとも https だけ？

どちらでも動きます。ビルダーは "protocol": "https" も "protocol": "https:" も https: に正規化します。http、ftp、mailto、独自スキームでも同じです。

URL に認証情報（ユーザー名／パスワード）を含められますか？

はい — 設定に "username" と "password" を入れてください。ホストの前に user:pass@host として現れます。ただし RFC 3986 §3.2.1 は本番 URL でこれを使わないよう警告しています。ブラウザ履歴、サーバーログ、プロキシキャッシュに残ってしまうからです。

なぜスペースが %20 ではなく + になるの？

クエリ部分のスペースは application/x-www-form-urlencoded ルールに従って通常 + にエンコードされます — それが URLSearchParams の出力です。パス内のスペースは %20 にエンコードされます。どちらも有効で、サーバーはどちらの形式もデコードします。サーバーが壊れていて %20 しか扱えないなら、それはこのツールよりも大きな問題です。

入力 JSON 自体はどんな形式？

標準 JSON です — 仕様は json.org または ECMA-404 を参照。キーは文字列、値は文字列または（searchParams の場合）文字列の配列。コメントなし。末尾カンマ不可。

他の URL & JSON ツール

組み立ては一方向です。自然に組み合わさるツール: