§

デコードするテキストを入力：

デコードしたいURLエンコード済みテキストを入力してください。このツールはパーセントエンコードされた文字を元の形式に変換します。
§

Output

decoded

国内マーケターやエンジニアは、Google アナリティクス 4 や Yahoo! 広告の UTM パラメータの日本語キーワード、ZOZOTOWN や Amazon JP の検索ログ、Shopify Japan の Webhook ペイロードを読み解くたびに URL デコードを行います。OAuth state の検証や、AWS WAF (Tokyo) のブロックログから攻撃シグネチャを抽出する SOC 業務でも頻用されます。FISC 準拠の銀行系案件では外部 SaaS への貼り付けが禁じられるため、本ツールが安全な代替となります。

// 関連ツール

./url-encoder
URL エンコーダー
URL で安全に転送するために文字列をパーセントエンコードします。
→
./url-parser
URL パーサー
URL をパーツに分解し、クエリ文字列をデコードして再構築します。
→
./base64-encoder
Base64 エンコーダー
テキストやファイルを Base64 形式にエンコードします。
→
./
すべてのツール
Ultim8Soft のオンラインツール一覧をご覧ください。
→

詳細オプション

+ をスペースに変換

有効にすると、+ 文字がスペースに変換されます。クエリパラメータをデコードする際に便利です。

ライブモード

有効にすると、入力中にテキストが自動的にデコードされます。

これらのオプションは、URL内のエンコードされた文字のデコード方法を制御するのに役立ちます。

URL デコードとは何ですか？

URL デコードは パーセントエンコーディング を逆に変換します。エンコードされた URL に含まれる %XX エスケープシーケンスを読み取り、それが表す文字に戻します。ブラウザ・API・ログ行がエンコードした状態で渡してきたクエリ文字列・フォーム値・パスセグメントを、人が読める形で復元できます。

URL デコードはどのように機能しますか？

URL デコードは、パーセントエンコードされたシーケンスを元の文字に戻すための特定のプロセスに従います：

  1. 入力文字列からパーセントエンコードされたエスケープシーケンス（%XX）を走査する
  2. 各 %XX を2桁の16進数から元のバイト値に変換し直す
  3. 連続するデコード済みバイトを UTF-8 文字に再構成する（マルチバイトシーケンスが1文字になる）
  4. クエリ文字列のコンテキストでは、+ は空白にデコードされ（application/x-www-form-urlencoded）、%2B はリテラルの + のまま残る
  5. 非予約文字とすでにデコードされたテキストは変更されずにそのまま通過する

URL デコーダーを使う理由は何ですか？

  • 読めるアウトプット：%20・%40・%3D をスペース・@・= に戻し、URL が実際に何を伝えているか読み取れるようにする
  • 多言語テキスト：アクセント付き文字や非 ASCII 文字を UTF-8 バイト列から復元し、%C3%A9 を再び é として読めるようにする
  • デバッグ：クエリ文字列・OAuth リダイレクト・webhook ペイロード内の実際の値を、処理する前に確認する
  • 標準準拠：ブラウザやサーバーと同じルールである RFC 3986 に従ってデコードし、まったく同じ結果を得る

URL デコードの一般的な用途は何ですか？

URL デコードは多くの Web 開発シナリオで不可欠です：

  • フォーム送信：application/x-www-form-urlencoded の GET・POST データから元のフィールド値を読み戻す
  • API 開発：API エンドポイントに届いたパーセントエンコードされたパス・クエリパラメータを展開する
  • ファイルシステム：URL 内を転送するためにパーセントエンコードされたファイルパスやファイル名を復元する
  • リンクのデバッグ：共有またはログに記録された URL をデコードし、含まれる特殊文字や多言語テキストを確認する

URL デコードの例はどのようなものですか？

URL デコードの一般的な例を示します：%20（または +）はスペースに、%40 は @ に、%23 は # に、%26 は & に、%3D は = になります。%C3%A9 のような UTF-8 シーケンスは国際文字 é になります。

パーセントエンコーディングとは何ですか？

パーセントエンコーディングは RFC 3986 §2.1 で定義されたメカニズムで、URI 内で安全でない、または予約された文字を表現するために使われます。ルールは機械的です：そのままでは現れることができないすべてのバイトは、パーセント記号に続く 2 桁の 16 進数 — %XX 形式 — として書かれ、XX はそのバイトの値です。é のような非 ASCII 文字は、まずその UTF-8 バイト列としてエンコードされ、その後それぞれのバイトが個別にパーセントエンコードされます。開発者はこれにほぼ毎日遭遇します：クエリ文字列、フォーム送信、OAuth コールバック URL、REST API のパスパラメータ、そして URL が句読点・空白・非予約集合 A–Z a–z 0–9 - _ . ~ 外の文字を運ぶ必要があるあらゆる場所で。

%C3%A9 を é にデコードする処理は実際どう動くのですか？

エンコード済みのクエリ文字列 ?q=caf%C3%A9&lang=fr を例にします。デコードすると ?q=café&lang=fr が得られます。以下はバイト単位の解説です：

  • 入力: ?q=caf%C3%A9&lang=fr
  • 出力: ?q=café&lang=fr
  1. %C3 → バイト 0xC3（2 進 11000011）— 2 バイト UTF-8 シーケンスの先頭バイト。
  2. %A9 → バイト 0xA9（2 進 10101001）— 継続バイト。合わせると C3 A9 は U+00E9 の UTF-8 エンコーディング、つまり é です。
  3. ?、=、& の各文字は構造的であるためそのまま残されます — これらはクエリとそのキー/値ペアを区切ります。リテラルの caf も変換されずに通過します。小文字の ASCII 文字は非予約集合に属しているからです。

decodeURIComponent と decodeURI の違いは何ですか？

JavaScript は組み込みのデコーダを 2 つ提供しており、これらを取り違えることは URL 処理で最もよくあるバグの一つです：

  • decodeURIComponent(str) は、&、=、?、/、# のような予約文字を含むすべてのパーセントエンコード列をデコードします。クエリ文字列の個別の値やパスセグメントに対して使い、URL 全体に対しては絶対に使わないでください。
  • decodeURI(str) は意図的に保守的で、予約文字をスキップします。%26 を渡してもリテラル文字列 %26 が返り、& にはなりません。これは構造を往復させても保持したい URI 全体のために用意されています。

経験則：文字列が URL の一部（単一のパラメータ、フラグメント、エンコードされたファイル名）であれば、decodeURIComponent を使いましょう。このツールは decodeURIComponent と同じように振る舞います — 入力中のすべての %XX シーケンスは予約文字を含めてデコードされます。

URL をデコードすることで、その中に本当に何が入っているかがわかります。上部にエンコードされた文字列を貼り付けると、すべての %XX シーケンスがブラウザ内で即座に文字に戻ります。クエリパラメータのデバッグ、OAuth リダイレクトの確認、アクセント付きファイル名の復元をサーバーに何も送らずに行えます。