URL エンコーダー・デコーダー
値ひとつ、URL 全体、どちらもエンコードとデコードができます。
クエリパラメータ
- すべて無料登録なし、回数制限なし、有料プランなし。
- アップロードなしファイルは自分の端末で処理され、サーバーには届きません。
- 結果に条件なし透かしなし、勝手な縮小なし、サイズ上限なし。
- 変更はすべて公開修正も新しい工具も、すべて更新履歴ページに書いています。
このツールでできること
URL に含められるのは限られた ASCII 文字だけです。それ以外のもの、すなわちスペース、日本語などの文字、&、=、?、#、そして大半の記号は、リンク、フォーム送信、API 呼び出しで安全にやり取りするために、まず %XX 形式のバイトにパーセントエンコードしなければなりません。このページはそのエンコードを双方向で行い、さらに多くのエンコーダーと異なり結果を分解して表示します。任意の URL やクエリ文字列を貼り付けると、パラメータがデコード済みのキーと値の表として表示されるため、トラッキングリンクや OAuth のリダイレクトを一目で読み取れます。
テキストは UTF-8 として扱われるため、中文 はブラウザやサーバーが期待するとおり %E4%B8%AD%E6%96%87 になります。デコードは寛容で、有効なエスケープでない孤立した % はエラーにならずそのまま残され、フォームデータをデコードする際は + がスペースとして扱われます。
コンポーネントのエンコードと URL 全体のエンコード
「コンポーネントをエンコード」は JavaScript の encodeURIComponent で、英字、数字、-_.!~*'() 以外をすべてエスケープします。クエリパラメータ、パスセグメント、フォームフィールドに入れる単一の値に使ってください。「URL をエンコード」は encodeURI で、構造文字 :/?#[]@!$&'()*+,;= には手を付けず、スペースと非 ASCII テキストだけをエスケープするため、完全なアドレスが有効なアドレスのまま保たれます。使い分けを誤るのが典型的なバグです。URL 全体に encodeURIComponent を適用するとすべての / が %2F になりリンクが壊れ、& を含む値に encodeURI を使うと気づかないうちに 2 つのパラメータに分割されます。
「スペースを + にする」オプションは、%20（RFC 3986、URL で使用）と +（application/x-www-form-urlencoded、HTML フォームの本文や多くの古いクエリ文字列で使用）を切り替えます。ここではどちらも正しくデコードされます。エンコード時は送信先が期待する形式を選んでください。
よくある間違い
二重エンコード：すでにエンコード済みの値をエンコードすると %20 が %2520 になり、サーバーには文字どおりの %20 が届きます。デコード結果にまだ %XX が残っていれば、もう一度デコードしてください。値の中の & や # をエンコードし忘れるとパラメータが途中で切れます。URL 全体を encodeURIComponent でエンコードするとスキームやスラッシュが壊れます。クライアントとサーバーで + と %20 の慣習が食い違うと、ユーザー名にプラス記号が混入します。最後に、パーセントエンコードは暗号化でも難読化でもありません。デコードすれば完全に読めるので、トークンを隠す目的で頼ってはいけません。ペイロードを不透明にしたい場合、通常の転送エンコードは Base64 ですが、これも簡単に元に戻せます。
背景：パーセントエンコードの由来
パーセントエンコードは、Tim Berners-Lee らが書いた最初の URL 仕様 RFC 1738（1994 年）で定義され、現在の URI 構文標準である RFC 3986（2005 年）で洗練されました。% によるエスケープの仕組みは UTF-8 が主流になる前からあるため、古いシステムでは Latin-1 や Shift-JIS でバイトをエンコードすることがあり、UTF-8 としてデコードすると文字化けが起きます。HTML5 の URL Standard（WHATWG）が最終的に新しいエンコードでの UTF-8 を必須にしました。スペースを + にする慣習は URL 標準ではなく別の HTML フォーム仕様に由来し、これが今日 2 種類のスペースのエンコードが併存している歴史的な理由です。
利用される場面
API リクエストの手組み（検索語、フィルター、コールバック URL）、広告プラットフォームのトラッキングリンクのデバッグ（utm_source、gclid、fbclid）、OAuth や SSO のリダイレクトの読み取り（redirect_uri、state、scope）、件名や本文付きの mailto: や tel: リンクの作成、中国語や日本語のパスを含むリンクの共有、フォームデータとして送られた Webhook ペイロードの確認などに使えます。パラメータ表は、サポートチケットの長い URL を貼り付けて何がリクエストされたかを正確に確認するのに便利です。クエリ文字列内の値は JSON や Base64 であることが多いので、まずここでデコードしてから、その値を対応するツールに貼り付けてください。
よくある質問
encodeURI と encodeURIComponent の違いは何ですか？
encodeURIComponent は非予約文字以外をすべてエスケープし、個々の値に使います。encodeURI は URL の構造文字（/ ? & = # :）を残すため、完全なアドレスに使います。URL 全体に encodeURIComponent を適用してはいけません。
スペースは %20 と + のどちらにすべきですか？
URL では %20（RFC 3986）です。+ は application/x-www-form-urlencoded のフォーム本文と、HTML フォームの慣習に従うクエリ文字列の中だけで使います。ここではどちらもスペースとしてデコードされます。
デコードしたテキストに %2520 が含まれるのはなぜですか？
その値は 2 回エンコードされています。もう一度デコードすると元のテキストになります。
日本語や絵文字に対応していますか？
はい。テキストは UTF-8 バイトとしてエンコードされるため、漢字 1 文字は 3 つの %XX に、ほとんどの絵文字は 4 つになります。
サーバーに何か送信されますか？
いいえ。エンコード、デコード、クエリ解析はすべてブラウザ内で実行されます。