URL エンコーダ / デコーダ

URLのパーセントエンコード/デコード。

Loading…

すべての処理はブラウザ内で実行されます — ファイルや入力はサーバへ送信されません。

使い方

右上で Encode / Decode を切り替え、テキストを貼り付けると右パネルに結果がリアルタイムで表示されます。Encode は標準の encodeURIComponent を実行します。非予約文字集合(A–Z・a–z・0–9・`-_.~`)以外のバイトはすべて `%XX` 形式の UTF-8 16 進表記に置き換えられます。Decode はその逆で、不正な `%` エスケープが含まれていればわかりやすいエラーを出します。

URL に値を載せる場面で使います。クエリ文字列のパラメータ、パスセグメント、リダイレクト先などです。フォームや現代の HTTP ライブラリは通常エンコードを自動で処理しますが、手で URL を組み立てるとき、Webhook コールバックをデバッグするとき、同僚から送られたトラッキングリンクを貼り付けるときなどに本ツールが役立ちます。処理はすべてブラウザ内で完結するため、トークンや個人情報を含む URL もマシン外には出ません。

スペースと非 ASCII 文字を含むテキストをエンコード

入力
hello world & 안녕하세요
出力
hello%20world%20%26%20%EC%95%88%EB%85%95%ED%95%98%EC%84%B8%EC%9A%94

スペースは %20 になります。日本語や韓国語など非 ASCII テキストはまず UTF-8 に変換されるため、ハングル 1 文字が 3 バイト(%XX%XX%XX)に展開されます。アンパサンドもエスケープされるのは、encodeURIComponent が値レベルの文字として扱うためで、そのままクエリ文字列に入れても安全です。

パーセントエンコードされたパスをデコード

入力
%2Fposts%2F%ED%95%9C%EA%B8%80-%EC%A0%9C%EB%AA%A9%2F
出力
/posts/한글-제목/

スラッシュがエンコードされているのは、encodeURIComponent が値レベルの文字として扱うためです。デコードすると元の UTF-8 文字列が復元されます。リクエストログに %2F が現れる場合、生成側が URI レベルではなくコンポーネントレベルのエンコーダを使った合図です。

不正なエスケープを検出

入力
hello %2 world
出力
URI malformed

decodeURIComponent は `%` の直後に 16 進数 2 桁が続かないと例外を投げます。よくある原因は、貼り付け元で一部の文字がすでにデコードされていて `%` だけ残っているケースです。

よくある質問

URL エンコードは暗号化と同じですか?

いいえ。パーセントエンコーディングは鍵なしで誰でも復元できる可逆変換です。任意のテキストを URL の構文(`?`・`&`・`=`・スペース・`#` がすでに構造的な意味を持つ)に収めるための仕組みであり、内容を隠す目的ではありません。セキュリティ層として使ってはいけません。

encodeURI と encodeURIComponent — このツールはどちらを使いますか?

encodeURIComponent です。この違いは重要です。encodeURI は `:` `/` `?` `&` `#` といった URL の構造文字を保持し、URL 全体を扱うのに向きます。一方 encodeURIComponent はそれらもエスケープし、URL に埋め込む個別の値を扱うのに向きます。URL 全体を貼り付けてクエリ値だけを変換したい場合は、先に手で分割してください。

デコードしたとき `+` がスペースにならないのはなぜですか?

encodeURIComponent はスペースを `%20` でエンコードし、`+` は生成しません。`+` = スペースという規約は、HTML フォーム送信が使う古い `application/x-www-form-urlencoded` 形式のものです。入力が `+` をスペースとして使っているなら、本ツールでデコードする前に `+` を `%20` に置換するか、フォーム urlencoded 用デコーダを使ってください。

ブラウザの URL バーには `日本` と表示されるのに、貼り付けると `%E6%97%A5%E6%9C%AC` になるのはなぜですか?

現代のブラウザは可読性のためにパーセントエンコードされた UTF-8 を元の文字として表示しますが、正確な伝送のため内部的にはエンコード済みの生の形を保持し、コピーします。両者は同じ URL の等価表現であり、本ツールではどちらも同じ文字列にデコードされます。

国際化ドメイン名(IDN)に対応していますか?

対応していません。本ツールは値側(パス・クエリ・フラグメント)のみを扱います。非 ASCII 文字を含むホスト名はパーセントエンコーディングではなく Punycode(`xn--…`)を使い、別の変換が必要です。現代のブラウザは Unicode 形式で表示しますが、内部では Punycode で伝送します。

エンコーダが `-`・`_`・`.`・`~` をそのまま残すのはなぜですか?

これら 4 文字は RFC 3986 で *非予約* 文字集合と定められており、URL の構造文字と紛れる余地がないためエスケープ不要です。encodeURIComponent は意図的にそのまま通します。

関連する概念

パーセントエンコーディング(別名 URL エンコーディング)は RFC 3986 で定義されています。非予約文字集合(A–Z・a–z・0–9・`-` `_` `.` `~`)以外のバイトは `%` の後ろに大文字 16 進数 2 桁が続いた形になります。URL はバイト指向のため、非 ASCII テキストはまず UTF-8 に変換されてから各バイトがパーセントエスケープされます。3 バイトの韓国語音節が 9 文字(`%XX%XX%XX`)に膨らむのはそのためです。

JavaScript には関連する関数が 4 つあり、挙動が異なります。`encodeURI` と `decodeURI` は URL の構造文字(`: / ? & = # @`)を保持し、URL 全体を扱うのに向きます。`encodeURIComponent` と `decodeURIComponent` は構造文字もエスケープし、URL に埋め込む個別の値を扱うのに向きます。本ツールは後者のペアを使います。別の形式である `application/x-www-form-urlencoded` はスペースを `%20` ではなく `+` でエンコードし、HTML フォームが生成します。多くのバックエンドフレームワークは両方を受け付けます。

パーセントエンコーディングと混同されやすい隣接概念が 3 つあります。**Base64** はバイナリを ASCII テキストに詰めますが `+` と `/` を含み、それ自体が URL エスケープを必要とします(base64url がこの問題を解きます)。**HTML エンティティ**(`&`・`😀`)は HTML 向けのエスケープで、URL 向けではありません。**Punycode**(`xn--…`)はホスト名がパーセントエンコーディングを使えないため、国際化ドメイン名を扱います。

関連記事

関連ツール