URLエンコード・デコード

URLエンコード・デコードをオンラインで、入力と同時に実行できます。スペース、アクセント付き文字、日本語、& や ? などの記号を %20 のようなパーセントエンコードの形式に変換し、読めるテキストに戻すこともできます。2つ目のタブは URL 解析ツールです。アドレスをプロトコル、ホスト、パス、クエリパラメータに分割し、パラメータの編集、無効化、トラッキングタグの削除ができ、正しくエンコードされた URL を書き戻します。処理はすべてブラウザ内で行われます。

URLエンコード・デコードの使い方

1. エンコード / デコード タブの入力欄に、テキストを入力または貼り付けます。結果 は1文字ごとに更新されます。
2. 変換方向 を選びます。エンコード は URL で安全に使える形にし、デコード は caf%C3%A9%20au%20lait を café au lait に戻します。空の入力欄に %20 のようなシーケンスを含むテキストを貼り付けると、ツールが自動で デコード に切り替わります（エンコードに切り替える で元に戻せます）。エンコードが必要なプレーンテキストを デコード モードで貼り付けた場合も同様に エンコード に切り替わり、デコードに切り替える で戻せます。
3. エンコードするときは、エンコード対象 でテキストの種類を選びます（次のセクションを参照）。初期設定の パラメータの値 は、クエリの値1つに向いています。
4. コピー は結果をクリップボードにコピーします。入れ替え は結果を入力欄に移し、変換方向を切り替えます。これは往復の確認に便利です。エンコードした結果をデコードすると、元のテキストに戻るはずです。

ツールが変更した文字は、結果の中でハイライトされます。カーソルを重ねると、その文字、Unicode のコードポイント、バイト列が表示されます。例：é U+00E9 %C3%A9。入力欄の下には 文字数、UTF-8 バイト数、エンコードした文字数（または デコードした文字数）が表示されます。サンプルで試す は 50%オフ、お茶 & お菓子? 今日だけ！ という文を読み込みます。この文は 21 文字ですが UTF-8 では 47 バイトです。日本語の文字は1文字が3バイトで、ASCII の文字は1バイトだからです。

エンコード時に 行ごとに処理 をオンにすると、各行を個別にエンコードし、改行はそのまま残します。値やリンクの一覧に向いています。オフの場合は改行もエンコードされ、%0A になります。テキストがパラメータ付きの URL のときは 部分に分割する が表示され、クリックするとそのアドレスが解析タブで開きます。

パラメータの値、URL全体、フォームデータのエンコード

すべての場所ですべての文字をエンコードする必要はありません。スラッシュはパスではフォルダの区切りですが、パラメータの値の中ではただのデータです。そのため、正しい結果はエンコードする対象によって変わります。エンコード対象 には4つのモードがあります。

• パラメータの値 は JavaScript の encodeURIComponent と同じ動作で、クエリの値1つやパスの一部に向いています。英字、数字、- _ . ! ~ * ' ( ) 以外をすべてエンコードするため、値の中に &、=、/、? があっても URL が壊れません。café & crème をエンコードすると caf%C3%A9%20%26%20cr%C3%A8me になり、q= の後ろにそのまま使えます。
• URL全体 は、整えるだけでよい完全なアドレス用です。スペース、非 ASCII 文字、制御文字、バッククォート、" < > \ ^ { | } をエンコードし、URL の構造を作る文字 : / ? # [ ] @ ! $ & ' ( ) * + , ; = はそのまま残します。たとえば https://example.com/search?q=café au lait&lang=fr は https://example.com/search?q=caf%C3%A9%20au%20lait&lang=fr になります。すでにエンコード済みのシーケンスはそのままで、単独の % は %25 になります。この点が JavaScript の encodeURI との違いです。encodeURI は既存の %20 を %2520 にし、http://[2001:db8::1]:8080/ のような IPv6 アドレスの角括弧もエンコードします。
• フォームデータ は、HTML フォームや URLSearchParams が生成する application/x-www-form-urlencoded（英語）の形式に従います。スペースは + になり、エンコードされずに残るのは英字、数字、* - . _ だけなので、! ' ( ) ~ もエンコードされます。
• 厳密な RFC 3986 は、RFC 3986（英語）の非予約文字である英字、数字、- . _ ~ だけをエンコードせずに残します。OAuth 1.0（RFC 5849）や AWS Signature Version 4 はまさにこの形式を要求します。! や * のエンコード方法が両側で同じでないと、署名が一致しないためです。

各モードでの同じ文字の扱いは次のとおりです。

文字	パラメータの値	URL全体	フォームデータ	厳密な RFC 3986
空白	%20	%20	+	%20
&	%26	&	%26	%26
/	%2F	/	%2F	%2F
+	%2B	+	%2B	%2B
~	~	~	%7E	~
!	!	!	%21	%21
*	*	*	*	%2A
é	%C3%A9	%C3%A9	%C3%A9	%C3%A9

テキストは常に UTF-8 でエンコードされ、16進数の英字は常に大文字です。入力にすでに %20 のようなシーケンスが含まれている場合は、その旨のメモと デコードに切り替える が表示されるので、うっかり二重にエンコードすることを防げます。

JSON をクエリパラメータで渡すには、JSON整形ツールで JSON を圧縮し、パラメータの値 でエンコードします。{"id":7,"tags":["a","b"]} は %7B%22id%22%3A7%2C%22tags%22%3A%5B%22a%22%2C%22b%22%5D%7D になります。逆の手順も可能です。パラメータをここでデコードしてから、JSON 整形ツールで整形します。

URLデコードで困るケース：プラス記号、%2520、不正なシーケンス

デコードはたいていそのまま成功しますが、つまずきやすい場面が4つあります。このツールは、エラーで止まらずにそれぞれに対応します。

• プラス記号は、フォームデータやほとんどのクエリ文字列ではスペースを表します。+ を空白としてデコード は初期設定でオンなので、caf%C3%A9+au+lait は café au lait にデコードされます。URL 全体の場合、スペースとして扱われるのは ? より後ろのプラス記号だけです。パスの中ではプラスは普通の文字だからです。プラス記号をそのままの意味で使いたい場合は、このオプションをオフにしてください。%2B としてエンコードされたプラスは、常にプラス記号のままです。
• 二重エンコードは、2つの処理がそれぞれ同じ値をエンコードしたときに起こります。RFC 3986 もこれを避けるよう注意を促しています。% が %25 になるため、スペースは %20 から %2520 に変わります。デコードした結果にまだ %20 のようなシーケンスが残っている場合、ツールはテキストが二重にエンコードされていた可能性を知らせ、もう一度デコード を提示します。
• 不正なシーケンス、つまり 100% や %G1 のように % の後ろに16進数が2桁続かないものがあると、JavaScript の decodeURIComponent は URIError を投げます。このツールでは、そのようなシーケンスはそのまま残して赤で表示し、件数を数えたうえで、残りのテキストをデコードします。
• 古い Latin-1 のリンクは UTF-8 が普及する前のもので、一部のサイトは é を1バイトの %E9 でエンコードしていました。caf%E9 は UTF-8 として正しくないため、decodeURIComponent は失敗し、Python の unquote は caf の後ろに置換文字 U+FFFD を付けた結果を返します。このツールはそのようなバイトを Windows-1252 として読み取り、caf%E9 を café にデコードして、その旨のメモを表示します。

デコードしたテキストに含まれるタブやヌルバイトなどの制御文字は ␉ や ␀ のような見える記号で表示されますが、コピー で実際にコピーされるのは本物のテキストです。

URL解析：URLを分割してクエリパラメータを編集

URLの解析と編集 タブの URL 欄にアドレスを貼り付けると、プロトコル、ホスト、ポート、パス、フラグメント に分割されます。URL に含まれている場合は ユーザー名 と パスワード も表示されます。値はデコードされた状態で表示されるので、このタブは URL パラメータをデコードして読む最も手軽な方法でもあります。%E3%83%A9%E3%83%B3%E3%83%8B%E3%83%B3%E3%82%B0+%E3%82%B7%E3%83%A5%E3%83%BC%E3%82%BA ではなく ランニング シューズ と読めます。編集は双方向で、ブラウザのアドレスバーや Postman のパラメータ表と同じです。欄を変更すると URL が即座に正しくエンコードされて書き換わり、URL を変更するとすべての部分が読み直されます。触っていない部分は、1文字も変わらずそのまま残ります。

クエリパラメータ の表には、すべてのパラメータが 名前 と 値 とともに並びます。URL に含める のチェックを外すと、パラメータを削除せずに URL から除外できます。リクエストを壊しているパラメータを探すときに便利です。パラメータを追加、パラメータを削除、名前順に並べ替え は名前のとおりの動作です。tag=a&tag=b のような同名の繰り返しや、?debug のような値のない名前もそのまま保持されます。パラメータ内の空白 は、スペースを %20 と + のどちらで書くかを決めます。初期設定では、貼り付けた URL に合わせます。

ログインや決済のリンクには、別の URL がパラメータの中に入っていることがよくあります。内側の ? や & が外側のものと混ざらないよう、エンコードされています。

https://auth.example.com/authorize?client_id=abc&redirect_uri=https%3A%2F%2Fapp.example.com%2Fcallback%3Ftab%3D2

値そのものが URL である場合（たいてい redirect_uri、return、url、next）、中の URL を編集 ボタンが表示されます。内側のアドレス https://app.example.com/callback?tab=2 は、独自の部分とパラメータを持つ別の階層として開き、パンくずリスト（メインURL › redirect_uri）で戻ることができます。変更はすべてエンコードされて外側の URL に書き戻されます。メインURLをコピー で結果をコピーできます。これは何階層でも使えます。

# より後ろの部分がパラメータの形をしている場合、たとえば OAuth のインプリシットフローの #access_token=...&state=... や、シングルページアプリのルートの #/search?q=shoes のような場合は、2つ目の表 フラグメントのパラメータ にもそれらが一覧表示されます。

パーサーは問題も指摘します。プロトコルのない URL（ブラウザは相対リンクとして扱います）、0 から 65535 の範囲外のポート、スペース、アクセント付き文字、" や < などエンコードが必要な文字です。最後のものは エンコードする で一度に修正できます。a=1&b=2 のようにアドレスのないテキストは、クエリ文字列として読み取られます。国際化ドメイン名の場合は DNS やブラウザが使う Punycode 形式を表示するので、münchen.de は xn--mnchen-3ya.de になり、xn-- で始まるドメインは読みやすい形が表示されます。

URLをコピー は完成したアドレスをコピーし、開く は新しいタブで開きます（http と https のリンクのみ）。JSONでコピー は、パラメータを JSON オブジェクトとして取得します。同名の繰り返しは配列にまとめられます。

URLからUTMなどのトラッキングパラメータを削除

ニュースレター、広告、SNS のリンクには、訪問者がどこから来たかをサイトに伝えるだけのパラメータが付いています。UTMパラメータの utm_source、utm_medium、utm_campaign、utm_term、utm_content は、Google アナリティクスの前身である Urchin に由来します。fbclid（Facebook）、gclid（Google 広告）、msclkid（Microsoft 広告）などのクリック ID は、各プラットフォームが自動で付けます。

パーサーはこれらに 計測用 タグを付け、トラッキングを削除（n） で一括削除できます。utm_* のほかにも、ttclid（TikTok）、mc_cid（Mailchimp）、_hsenc（HubSpot）など、20以上のパラメータを認識します。ページが必要とするパラメータはそのまま残ります。サンプルで試す で読み込まれるショップのリンクでは、トラッキングを削除（4） が utm_source、utm_medium、utm_campaign、fbclid を削除し、q、size、return と #reviews のフラグメントを残します。

QRコードにするリンクは、先にここで整えておくと効果的です。トラッキングパラメータがなければリンクが短くなり、短いリンクほどコードの密度が下がって読み取りやすくなります。

パーセントエンコーディングとは：文字が %XX になる仕組み

パーセントエンコーディングは URL エンコードとも呼ばれ、文字を % と2桁の16進数で表す方法です。URL に使える ASCII 文字は限られており、その一部には役割があります。? はクエリの開始、& はパラメータの区切り、# はフラグメントの開始です。RFC 3986 はこれらを予約文字（: / ? # [ ] @ と ! $ & ' ( ) * + , ; =）と呼んでいます。英字、数字、- . _ ~ は非予約文字で、エンコードの必要はありません。それ以外の文字と、単なるデータとして使われる予約文字はエンコードされます。

ASCII 以外の文字は、まず UTF-8 のバイト列に変換され、各バイトがそれぞれ %XX になります。

• é は U+00E9 で、UTF-8 では C3 A9 の2バイトで保存されるため、%C3%A9 になります。
• € は U+20AC で3バイトです：%E2%82%AC。
• U+1F600（にっこり笑った顔）のような絵文字は4バイトで、%F0%9F%98%80 になります。

%c3%a9 と %C3%A9 は同じ意味ですが、RFC 3986 は大文字を推奨しており、このツールも大文字で出力します。よく目にする文字のパーセントエンコード表です。

文字	エンコード後	文字	エンコード後
space	%20	+	%2B
!	%21	,	%2C
"	%22	/	%2F
#	%23	:	%3A
$	%24	;	%3B
%	%25	=	%3D
&	%26	?	%3F
'	%27	@	%40
(	%28	[	%5B
)	%29	]	%5D
*	%2A	改行	%0A

JavaScript、Python、PHPでのURLエンコード

どの言語にも関数が用意されていますが、スペース、スラッシュ、! ' ( ) * ~ の扱いに主な違いがあります。

JavaScript には、値用の encodeURIComponent、アドレス全体用の encodeURI、フォーム形式用の URLSearchParams があります。

encodeURIComponent("café & crème")                     // "caf%C3%A9%20%26%20cr%C3%A8me"
encodeURI("https://example.com/a b?q=café")            // "https://example.com/a%20b?q=caf%C3%A9"
new URLSearchParams({ q: "café & crème" }).toString()  // "q=caf%C3%A9+%26+cr%C3%A8me"
decodeURIComponent("caf%C3%A9")                        // "café"

decodeURIComponent は + をスペースに変換せず、100% のような不正なシーケンスでは URIError を投げます。

Python では、関数は urllib.parse にあります。quote は初期設定で / を残し（safe='/'）、それ以外は RFC 3986 の非予約文字を除いてすべてエンコードします。quote_plus はスペースを + にし、/ もエンコードします。

from urllib.parse import quote, quote_plus, urlencode, unquote_plus

quote("café & crème/brûlée")       # 'caf%C3%A9%20%26%20cr%C3%A8me/br%C3%BBl%C3%A9e'
quote("a b/c", safe="")            # 'a%20b%2Fc'
quote_plus("café & crème/brûlée")  # 'caf%C3%A9+%26+cr%C3%A8me%2Fbr%C3%BBl%C3%A9e'
urlencode({"q": "café & crème", "page": 2})  # 'q=caf%C3%A9+%26+cr%C3%A8me&page=2'
unquote_plus("caf%C3%A9+au+lait")  # 'café au lait'

PHP では、urlencode は HTML フォームと同じ方式でエンコードしてスペースを + にし、rawurlencode は RFC 3986 に従ってスペースを %20 にします。

urlencode("café & crème");     // "caf%C3%A9+%26+cr%C3%A8me"
rawurlencode("café & crème");  // "caf%C3%A9%20%26%20cr%C3%A8me"

rawurlencode は 厳密な RFC 3986 と同じ結果になります。urlencode は フォームデータ と一致しますが、* だけは %2A にエンコードします。

よくある質問

スペースは %20 と + のどちらでエンコードすべきですか？

%20 は URL のどこでも使えます。+ がスペースを意味するのは、クエリ文字列と、HTML フォームが送信する形式のフォームデータの中だけです。パスの中では + は普通のプラス記号なので、/a+b は /a+b のままです。クエリの値に本物のプラス記号が必要な場合は、%2B と書きます。このツールでは、フォームデータ はスペースを + にし、ほかの3つのモードは %20 にします。

URL の %20、%2F、%3D は何を意味しますか？

これらはエンコードされた文字で、%20 はスペース、%2F はスラッシュ、%3D はイコールです。ほかによく見るものに、%26（&）、%3F（?）、%3A（:）、%2C（カンマ）、%27（アポストロフィ）があります。2桁の数字は、その文字のコードを16進数で表したものです。アクセント付き文字や日本語などの非 ASCII 文字は、é が %C3%A9 であるように、2から4組のペアになります。文字列全体をデコード側に貼り付けると読めます。

encodeURI と encodeURIComponent の違いは何ですか？

encodeURI はアドレス全体用で、: / ? # & = のように構造を作る文字はそのまま残します。encodeURIComponent はパラメータの値やパスの一部といった1つの部分用で、これらの文字もエンコードするため、https://example.com/?a=1&b=2 は https%3A%2F%2Fexample.com%2F%3Fa%3D1%26b%3D2 になります。このツールでは、パラメータの値 が encodeURIComponent に相当し、URL全体 は encodeURI に近いものの、既存の %20 のようなシーケンスを %2520 にせずそのまま残します。

URL から UTM パラメータを削除するにはどうすればよいですか？

リンクを URLの解析と編集 タブに貼り付けて、トラッキングを削除（n） を押します。utm_* のタグと、fbclid や gclid などのクリック ID が一度にすべて削除されます。そのあと URLをコピー を押してください。一部だけ削除したい場合は、不要な行の パラメータを削除 を使います。

URL エンコードは暗号化や Base64 と同じものですか？

いいえ。URL エンコードは何も隠しません。誰でも caf%C3%A9 を café に戻せるため、パスワードやトークンの保護にはなりません。アドレスの中で文字を安全に使えるようにするだけです。Base64 は別のエンコードで、バイナリファイルを含むあらゆるデータを64種類の文字からなる文字列に変換します。URL 内の Base64 文字列でも、URL セーフ形式を使わない限り +、/、= はエンコードが必要です。URL セーフ形式は Base64エンコード・デコードツールで出力できます。

貼り付けた URL はアップロードされたり保存されたりしますか？

いいえ。エンコード、デコード、解析はブラウザ内で実行され、貼り付けた内容がサーバーに送信されることはありません。URL にはアクセストークン、セッション ID、パスワードリセットコードが含まれることが多いため、これは重要です。ブラウザが記憶するのは選択したタブとオプションだけで、テキストは保存されません。アドレスを読み込むのは 開く だけで、リンクをクリックしたときと同じように新しいタブで開きます。

プログラマー向けのツールは開発者カテゴリに、ある形式を別の形式に変換するツールはコンバーターにまとまっています。2つの長い URL、たとえば動作する API 呼び出しと失敗する API 呼び出しの違いを調べるには、テキスト比較ツールに貼り付けて文字単位で比較してください。