N2
NanToo
開発者向け

URLエンコード・デコードツール

URLエンコード⇔デコードをリアルタイム変換。encodeURIComponentとencodeURIの両方式に対応。日本語や特殊文字の%変換に。

このツールについて問い合わせる →

URLエンコード・デコードツールについて

URLエンコードとは

URLエンコード（パーセントエンコーディング）は、URLに使用できない文字を %xx の形式に変換する仕組みです。

たとえば、日本語の「あ」はUTF-8で3バイト（E3 81 82）なので、%E3%81%82 に変換されます。スペースは %20、&は %26 になります。

URLにはASCIIの一部の文字しか使えないため、日本語や特殊文字を含むURLやクエリパラメータを正しく送信するにはエンコードが必須です。

encodeURIComponent と encodeURI の違い

JavaScriptには2つのURLエンコード関数があり、用途が異なります。

  • encodeURIComponent（推奨）：: / ? # [ ] @ ! $ & ' ( ) * + , ; = を含むほぼすべての特殊文字をエンコード。クエリパラメータの値をエンコードする場合に使用
  • encodeURI：URL構造を表す文字（: / ? # @ & = など）はそのまま保持し、日本語やスペースのみをエンコード。URL全体をエンコードする場合に使用

一般的には encodeURIComponent を使い、パラメータの値を個別にエンコードするのが安全です。

URLエンコードの主な用途

  • クエリパラメータ：検索キーワードやフォーム入力をURLに含める場合（例：?q=%E6%A4%9C%E7%B4%A2）
  • API通信：GETリクエストのパラメータやリダイレクトURLの受け渡し
  • フォーム送信：application/x-www-form-urlencoded 形式でのデータ送信
  • 日本語URLの共有：SNSやメールで日本語を含むURLを共有する際の文字化け防止
  • Cookie値：特殊文字を含む値をCookieに安全に保存

よくある質問

Q. 入力データはサーバーに送信されますか？
いいえ。すべての変換処理はブラウザ内のJavaScriptで完結しており、データがサーバーに送信されることはありません。
Q. 日本語はどのようにエンコードされますか？
日本語はUTF-8でバイト列に変換され、各バイトが %xx 形式に変換されます。たとえば「日本語」は %E6%97%A5%E6%9C%AC%E8%AA%9E（9バイト＝9つの%xx）になります。
Q. encodeURIComponentとencodeURIのどちらを使うべきですか？
ほとんどの場合、encodeURIComponentが推奨されます。クエリパラメータの値をエンコードする場合は必ずencodeURIComponentを使ってください。encodeURIはURL全体をまとめてエンコードしたい場合にのみ使います。
Q. スペースは %20 と + のどちらになりますか？
encodeURIComponentではスペースは %20 に変換されます。+ に変換されるのは application/x-www-form-urlencoded 形式（HTMLフォーム送信時）の仕様で、本ツールでは %20 を使用します。
Q. エンコード済みの文字列を二重エンコードしてしまった場合は？
デコードを2回実行してください。たとえば %2520 は1回目のデコードで %20 に、2回目のデコードでスペースに戻ります。

関連記事

SNI はなぜ見えていたのか ― TLS Encrypted ClientHello(ECH)と HTTPS の最後の平文

HTTPSでも、TLSハンドシェイクのSNIは長く平文で送られてきました。2026年にRFC 9849として標準化された TLS Encrypted ClientHello(ECH) が何を隠し、何を隠さないのかを、TLS 1.3、ClientHelloInner/Outer、HTTPS/SVCB DNSレコード、DoHとの関係から整理します。

HTTP ステータスコードの設計思想 — RFC 9110 の 5 クラス分類と歴史的コードの運命

HTTP ステータスコードはなぜ 3 桁なのか、なぜ先頭の数字でクラス分類されるのか。HTTP/0.9 (1991) にはステータスコードが存在せず、RFC 1945 (1996) で初めて定義されました。RFC 9110 (2022) で再整理された現在の体系を一次資料で辿り、418 I'm a teapot や 451 Fahrenheit、25 年間 reserved のままの 402 など、個性的なコードの物語も紹介します。

QRコードの誤り訂正レベル L/M/Q/H — ISO/IEC 18004 の設計思想

QRコードには L/M/Q/H の4段階の誤り訂正レベルがあります。それぞれ最大7%/15%/25%/30%の汚損・欠損に耐える設計で、背景にはリード・ソロモン符号の数学があります。ISO/IEC 18004に基づき使い分けを整理します。

Base64 と Base64URL の違い — RFC 4648 で押さえる3つの落とし穴

Base64 は RFC 4648 で定義される標準エンコーディングですが、URL やファイル名で使うには「+/」「=」に関する罠があります。標準形と URL-safe 形の違いを仕様レベルで整理します。

このツールを評価
—(0件)