URL エンコーダー／デコーダー

文字	%XX コード	デフォルトの範囲	エンコード例
スペース	%20	なし	a b → a%20b
「+」	%2B	パス、完全な URL	a+b → a%2Bb
「&」	%26	クエリ、パス、URL	a&b → a%26b
「=」	%3D	クエリ、パス、URL	a=b → a%3Db
「/」	%2F	パス、完全な URL	a/b → a%2Fb
「?」	%3F	完全な URL	a?b → a%3Fb
「#」	%23	完全な URL	a#b → a%23b
「é」	%C3%A9	なし、UTF-8 で 2 バイト	été → %C3%A9t%C3%A9

URL の「エンコード」「デコード」とは何を意味する？

URL をエンコードする （「url encode」「urlencode」）は、アドレスで禁止されている文字 — スペース、アクセント、アンドサイン、プラス記号 — を、パーセント記号とそのバイトの 16 進 2 桁からなるシーケンスに変換します。 URL をデコードする （「url decode」「decoder url」）はこのシーケンスを逆に読みます：バイト列を復元し、宣言されたエンコード（多くは UTF-8）に従って文字に変換します。まさにこの 2 つが「encoder decoder url」「percent encoding online」と検索する人が探しているものです。

percent-encoding は圧縮でも暗号でもありません：アクセント付きの単語は 2 倍の長さになり、誰でも目で読めます。役割は URL に任意のバイトを通すことだけで、URL はデフォルトで ASCII の一部しか受け付けません。逆に Base64 は完全にテキストのチャンネルでバイトを運ぶためのもの — 見た目は似ていますが、互換性はありません。

URL を percent-encoding でエンコードする方法

ステップ 1：テキストは選択した文字セット（デフォルトは UTF-8）でバイトに変換されます。ステップ 2：各バイトについて、対応する文字が選択範囲の許容文字リストに含まれるかを確認します。ステップ 3：含まれていればそのままコピーされ、それ以外は %XX（XX はバイトの 16 進 2 桁）です。ステップ 4：スペースを + にするオプションが有効な場合、バイト 32 はプラス記号に置き換えられ、従来の値は %20.

具体例：「 café & été 」をコンポーネント範囲でエンコードすると caf%C3%A9%20%26%20%C3%A9t%C3%A9。エンコーダーにこのテキストを入力するだけで、結果、入力サイズ、出力サイズ、オーバーヘッドがキーを離す前に表示されます。

4 つのエンコード範囲

そのうち、 コンポーネント範囲 が保持するのは文字と数字、そして - _ . ! ~ * ' ( ) のみです。パラメータ値の範囲であり、対応するのは encodeURIComponentです。さらに クエリ文字列 はアンドサインとイコールも保持するので、query string 全体を再構築できます。さらに パスセグメント が許可するのは / : @ & = + $ , ; で、スラッシュを壊さないためです。完全な URL がさらに加わるのは ?, #, [ と ] で、ほぼ何もエスケープされません。スペースと非 ASCII 文字だけが %XX.

エンコード済み URL をデコードする方法

デコードは文字列を左から右へ走査します：パーセント記号＋16 進 2 桁で 1 バイトを得て、それ以外の文字は選択したエンコードに従って変換後にそのまま残します。バイトはまとめて文字に変換され、「é」は 2 バイト、「日」は 3 バイト、絵文字は 4 バイトです。「デコード」タブには、見つかった各シーケンス、文字列内の位置、対応するバイトとテキストが表示されます。

パーセント記号の後に有効な 16 進 2 桁がない場合は、理由が明確に表示されます：シーケンス不完全か、16 進文字が無効か。「% を修正」ボタンは孤立したパーセント記号を次の %25に変換し、情報ロスなしで文字列をデコード可能にします — 部分的にエスケープされた URL を扱う際に最も安全な方法です。

スペース：%20 と + — フォームのルール

%20 は厳密な percent-encoding のスペースです。パス、クエリ、フラグメント、ヘッダーのどこでも使えます。一方、記号 +は次の形式でのみスペースとして扱われます： application/x-www-form-urlencoded 。これは HTML フォームや従来の query string が使う形式で、それ以外では文字通りのプラス記号のままです — 混同しやすいので、値をエンコードするときは必ず次の %2B にエスケープします。

実践：フォームの項目に入力する場合、または <form>の振る舞いを再現する場合は、「スペースを + 」。リダイレクト URL、canonical、共有リンクでは常に %20。デコーダーは + をデフォルトでスペースとして扱い、この動作は 1 クリックで無効化できます。

RFC 3986：unreserved、sub-delims、gen-delims

RFC 3986 は ASCII 文字を 3 つのカテゴリに分けます。 非予約文字 （文字と数字、 - _ . ~ ）が常にそのまま保持されます。さらに、 サブデリミタ ! $ & ' ( ) * + , ; = と、 ジェネリックデリミタ : / ? # [ ] @ は構造的な意味を持ちます：オーサリティ、パス、クエリ、フラグメントを分ける役目です。それ以外 — スペース、引用符、山括弧、波括弧、パーセント記号 — はすべてエンコードが必要です。

これらのカテゴリは、まさに「RFC 3986 & リファレンス」タブが 1 文字ずつ表示しているものです。タイルをクリックすると、16 進コード、カテゴリ、その文字を保持する範囲がわかります。「この文字はエスケープすべきか？」に答えるための最速リファレンスです。

アクセント文字、絵文字、UTF-8

URL は安全な ASCII バイトしか運ばないため、U+007F を超える文字はすべてエンコードが必要です。UTF-8 で「é」は C3 A9 で、次のようになります： %C3%A9。また「日」は 3 バイトで 3 つのシーケンスになり、絵文字は 4 バイトでエンコード後は 8 文字になります。長いと感じてもバグではありません：すべてのプロトコルと共存するための代償です。最後に元の文字セットにも注意を — Latin-1 でエンコードした文字列を UTF-8 でデコードすると化け文字が出ます。だから「デコード」タブに 4 つの選択肢があるのです。

なぜ encodeURIComponent だけでは足りないのか

encodeURIComponent は次を除くすべてをエンコードします A-Z a-z 0-9 - _ . ! ~ * ' ( )。パラメータ値には適していますが、スラッシュ、コロン、アンドサインまでエスケープするため、完全な URL は壊れます。 encodeURI は逆のことをします：URL の構造は保ちますが、スペースやアクセントは通してしまうため、生のテキストには使えません。この 2 つはどちらもカバーしています — それ以上に、「クエリ文字列」範囲と「パスセグメント」範囲がその間を埋めます。

percent-encoding と Base64：違う 2 つのツール

percent-encoding はバイト単位で置き換え、元テキストの可読性を保ちますが、その代償としてかなり長くなります。Base64 はバイトを 3 つずつまとめ、64 文字のアルファベットで書き直します：コンパクトですがまったく読めず、URL-safe 変種なしでは URL にそのままは使えません。「相互エンコード」タブで両方を一目で比較でき、おまけとして 16 進バイト、HTML エンティティ、エスケープ済み JSON 文字列も — コピーする前に正しい表現を選べます。

よくある間違い：二重エンコードと孤立した %

最もよくあるのは、同じ文字列を 2 回エスケープすることです：スペースは %20、次に %2520となり、サーバーが文字通り「%20」を受け取ってしまいます。2 つ目はパーセント記号自身を忘れることで、これは次の %25 にしなければなりません。さもないとデコードはシーケンスの先頭と誤認して停止または打ち切りになります。最後に、フォームパラメータで + を未エスケープのまま残すのは、意図しないスペースを挿入するのと同じです。デコードは不正なシーケンスを検知し、「% を修正」ボタンがこのケースをロスなく直します。

エンコード済み URL はどこに潜むのか

トラッキング用 query string の UTM、さらには redirect_uri や OAuth、さらには webhooks で、ターゲット URL にネストしたパラメータが含まれるものは、 署名付きコールバック URL 、サーバーログ、sitemap、canonical、さらに次の <a href> で生成されたもの、 JWT で payload が Base64URL のもの、さらに data: や次の Locationヘッダー、そして GET で送信されるすべての HTML フォームにも含まれます。1 秒でエンコードとデコードを使いこなせば、文字列 1 つのためにターミナルを開く必要はなくなります。

パフォーマンスとベストプラクティス

ブラウザーではエンコードもデコードも線形で、数メガバイトでも目立ったコストはありません：各文字は 1 回だけ処理され、再帰も文字ごとの割り当てもありません。注意すべきは二重エンコード — 保存前に必ず往復を確認すること — と、複数キロバイトある URL で、2 000 文字を超えるとプロキシに切り詰められがちな点です。生成した文字列のそばに使った範囲を書きましょう：「コンポーネント」と「完全な URL」では、同じテキストでも結果が変わります。

こんな方におすすめ

バックエンド／フロントエンド開発者（query string、リダイレクト、OAuth）、インテグレーターと技術ライター（UTM リンク、canonical、トラッキング）、管理者と DevOps（Webhook、署名付き URL、ログ）、テスターとペネトレーションテスター（パラメータの fuzzing、フィルタ回避）、学生（UTF-8・ASCII・RFC 3986 の学習）、そして次のものが必要なオンラインの URL エンコーダー／デコーダー を、速く・充実して・安心して使えるものとして — 補完は次のBase64 エンコーダー／デコーダー と JSON フォーマッター.

100 % ローカルの URL エンコーダー／デコーダー：データはパソコンから出ません

一般的なオンライン URL エンコーダーと違い、文字列は一切送信されません：エンコード、デコード、URL 解析、パラメータの再構築はすべてブラウザー内で完結します。そのため、内部のリダイレクト URL、署名付きトークン、接続文字列、コード片を、機内モードや公開ネットワークでも安心してエスケープできます。履歴と最後の入力はローカル（localStorage）に保存され、端末から出ません。

また、 Premium Volade は、ツールとは独立したオプションの暗号化クラウド同期を追加します — それ以外はすべて無料・無制限・登録不要のままです。