エンコード

URL エンコード / デコード

単一のパラメータ値、完全な URL、または a=1&b=hello world のような Query 文字列を貼り付けると、文脈に合ったパーセントエンコード方式で処理できます。通常のテキストは 1 つのパラメータ値として扱い、完全な URL ではプロトコル、パス、Query、フラグメントの構造を保ち、Query モードでは各パラメータを個別に処理します。フォームモードは+ が空白を表す古い慣例に対応し、厳密デコードは API 検証に、寛容デコードは壊れたログの確認に向いています。処理はすべてブラウザ内で行われるため、コールバック URL、OAuth state、JWT パラメータ、プライベートな値がアップロードされることはありません。

  • パラメータ値、完全な URL、Query パラメータを分けて処理できるため、構造用の文字を誤ってエンコードしにくくなります
  • Query モードでは key と value の両方を処理するか、value だけを処理するかを選べ、バックエンドごとの仕様に合わせやすくなります
  • application/x-www-form-urlencoded で使われる+ が空白を表すルールにも対応します
  • 厳密デコードは不正なパーセントエンコードをすぐ報告し、寛容デコードは読める形への復元を試みます
  • 完全な URL、フォーム形式の Query、中国語テキスト、Emoji のサンプルで、実データを貼り付ける前に挙動を確認できます
  • 完全にローカルで処理するため、コールバック URL、署名付きパラメータ、Webhook 内容、プライベートなフィールドはブラウザ内に留まります
工具/URL エンコード / デコード
入力待ち
結果がここに表示されます...
エンコード · テキストまたは値

テキストまたは値モードでは、入力全体を 1 つの値として扱います。そのため、?、&、= も内容としてエンコードされます。

URL コマンド

概要

URL エンコードの問題は、文字そのものよりも、間違った文脈に間違ったルールを使うことで起きがちです。このページでは、まずパラメータ値、完全な URL、Query 文字列を区別し、それぞれに合った処理を行います。

  1. 01

    3 種類の処理対象

    テキストまたは値モードは、入力全体を 1 つの値としてエンコードします。完全な URL モードは、プロトコル、ホスト、パス、Query、フラグメント構造を保ちます。Query モードは各パラメータを個別に処理します。正しい対象を選ぶことが、安定した結果につながります。

  2. 02

    Query モードでは value だけの処理も可能

    Query モードでは、key と value の両方を処理することも、key はそのままにして value だけを処理することもできます。サーバーが key 名をそのまま期待し、value だけ URL セーフにしたい場合に便利です。

  3. 03

    完全な URL の構造を保持

    すでに組み立て済みの URL を貼り付けた場合、ツールはエンコードが必要な部分だけを処理します。プロトコル、ホスト、パス区切り、Query 区切り、フラグメントはそのまま保たれます。

  4. 04

    フォーム空白モード

    標準のパーセントエンコードと、フォーム送信で使われる慣例を切り替えられます。標準では空白をパーセントエンコードで表し、フォームデータでは + で表します。完全な URL の構造を壊さないよう、この切り替えは完全な URL モードでは非表示になります。

  5. 05

    厳密デコードと寛容デコード

    厳密デコードは、孤立した % や不完全なバイト列で失敗するため、プロトコル検証に向いています。寛容デコードは、よくある壊れた断片を先に補正し、ログ調査で読めるテキストを返すことを優先します。

  6. 06

    往復確認

    エンコード後の結果を入力に戻し、もう一度デコードできます。選択中のモードで元の内容に戻せるかをすばやく確認できます。

  7. 07

    インラインの検証状態

    変換に成功すると出力ヘッダーに成功状態が表示され、入力形式が無効な場合はエラー状態が表示されます。データが壊れているのか、ツールの挙動なのかを切り分けやすくなります。

  8. 08

    完全にローカルで処理

    エンコード、デコード、コピー、往復確認はすべて現在のブラウザタブ内で行われます。コールバック URL、OAuth state、署名付きリンク、JWT パラメータ、顧客検索語、プライベートなフィールドが端末の外へ出ることはありません。

使い方

手順は短く 5 つです。コントロールを変更すると、出力はすぐに再計算されます。

  1. 01

    変換モードでエンコードまたはデコードを選びます。

  2. 02

    処理対象を選びます。単一のテキスト値、すでに組み立てられた完全な URL、または Query パラメータの集合から選択します。

  3. 03

    Query パラメータを処理する場合は、key と value の両方を処理するか、value のみを処理するかを選びます。デコード時は、厳密モードまたは寛容モードも選べます。

  4. 04

    データが HTML フォーム送信由来、または+ が空白を表す古いシステム由来の場合は、フォームモードを有効にします。このオプションは完全な URL モードでは自動的に非表示になります。

  5. 05

    出力状態がエンコード済みまたはデコード済みになったら結果をコピーします。確認したい場合は、出力を入力に戻して逆方向の変換を実行します。

詳細

同じ文字でも、ある場所では内容であり、別の場所では区切り文字や構造を表す記号になります。処理対象は、エンコーダーにその文字をどう解釈すべきか伝える役割を持ちます。

  • 単一のパラメータ値、検索キーワード、フィルター、slug にはテキストまたは値を使います。?、&、= は内容としてエンコードされるため、URL を誤って分割しません。
  • 入力がすでに組み立て済みの完全な URL で、空白や Unicode だけを処理したい場合は完全な URLを使います。プロトコル、ホスト、パス区切り、Query 区切り、フラグメント記号は有効なまま保たれます。
  • 生の Query 断片を持っている場合はQuery パラメータを使います。各項目が独立して処理され、key をそのまま残すかどうかも選べます。
  • フォームモードは、HTML フォーム投稿、古いコールバック、または+ が空白を表すと明確に決まっているシステムでだけ有効にしてください。通常の URL パラメータでは多くの場合不要です。
  • 切り詰められたログ、コピー中に壊れた文字列、部分的にエンコードされた値を調べるときは寛容デコードを使います。まず読めるテキストを得て、次の処理を判断しやすくします。
  • プロトコル検証、API 契約テスト、無効な内容を即座に失敗させる必要がある処理では、厳密デコードを使います。

活用シーン

ここに挙げるのは、繰り返し発生する開発作業です。モードを選び、内容を貼り付け、結果をコピーする同じ流れで対応できます。

  1. OAuth コールバック URL と state

    ネストしたパラメータを含む完全なコールバック URL をエンコードして認可リンクに入れたり、コールバックから state 値をデコードしてクライアントが実際に送った内容を確認したりできます。

  2. 検索とフィルターの Query パラメータ

    ユーザーが入力した検索語、複数選択フィルター、ページング cursor、多言語タグを、query string に追加する前にエンコードできます。

  3. API リクエスト URL の組み立て

    REST URL を作るときに、パスセグメント（slug、ID、日付）とパラメータ値を別々にエンコードし、サーバーへ壊れず届くようにできます。

  4. Webhook 署名の調査

    ログから取得した signature、state、nonce パラメータをデコードし、パートナーが実際に送信した内容を再構成できます。

  5. UTM とトラッキングリンクの整理

    広告リダイレクト、短縮リンク、ランディングページが重なった多層トラッキングリンクをデコードし、各階層の UTM フィールドを読み取って、アトリビューション、保管、トラブルシュートに使えます。

  6. フォーム投稿のトラブルシュート

    ブラウザの開発者ツール、API ゲートウェイログ、バックエンドのアクセスログからフォーム内容をコピーし、デコードしてユーザーが実際に送信した内容を確認できます。

  7. CJK と Emoji パラメータの処理

    中国語、英語、日本語、韓国語、Emoji のパラメータを一貫してエンコードし、ブラウザ、プロキシ、フレームワーク間の差を減らせます。

  8. 二重エンコードの救出

    ログ内のテキストが複数回エンコードされているように見える場合、元の値が見えるまで 1 層ずつデコードできます。

  9. 事前入力済み URL の共有

    事前入力メールリンク、Google Forms、Slack deep link、マーケティング用共有リンクを作るときに、メッセージとパラメータを先にエンコードしてから URL に組み込めます。

  10. JWT と SAML コールバックの確認

    JWT や SAML コールバック内の URL パラメータを先にデコードし、その結果を対応する検査ツールへ渡してさらに詳しく確認できます。

関連情報

URL に含まれる値が、認証情報、不透明な token、インライン画像のように Base64 で包まれている場合は、まず Base64 エンコーダー・デコーダー で往復確認できます。コールバック URL に埋め込まれた Bearer token や 3 セグメントの JWT を扱う場合は、JWT インスペクター を開いて header、claims、signature を確認してください。1 つのパラメータから、host、path、Query、fragment を含む完全な URL へ作業が広がった場合は、URL ツール と組み合わせると便利です。

使い方のヒント

URL の問題の多くは、エンコード規則そのものではなく、文脈の読み違いから起こります。次の習慣を持つと、結果が予測しやすくなります。

  • 変更する前に、入力が 1 つの値なのか、完全な URL なのか、生の Query 文字列なのかを判断してください。この判断で使うルールが決まります。
  • 単一の値にはテキストまたは値モードを使い、すでに組み立て済みの URL には完全な URLモードを使います。この 2 つの文脈を混ぜないでください。
  • 入力がすでにパーセントエンコードを含んでいる場合は、再エンコードする前に一度デコードして元の値を確認してください。そうしないと二重エンコードになりやすくなります。
  • フォームモードは、双方がフォーム送信ルールに従うことが明確な場合だけ使ってください。通常の URL パラメータや多くの API では、空白は標準のパーセントエンコードで扱います。
  • 切り詰められた行、半端なバイト列、コピー＆ペーストで壊れた文字列など、現実の汚れたログでは、まず寛容デコードを使います。値が読める状態になったら、厳密モードでクリーンな版を再デコードして確認します。
  • 空白、Unicode、配列パラメータ、コールバック URL の扱いについて、チームの取り決めを文書化してください。フロントエンド、モバイル、バックエンドがこの細部でずれることは、本番の URL 問題のよくある原因です。
  • URL エンコードは転送形式であり、セキュリティ機構ではありません。XSS 対策、token 保護、署名検証には、それぞれ専用の安全対策が必要です。
  • リリース前に往復確認をしてください。まずエンコードし、出力を入力として使い、デコードして、元の値に戻ることを確認します。

制限事項

境界を理解しておくと誤用を避けられ、別のツールを使うべき場面も判断しやすくなります。

  • これはエンコードツールであり、暗号化ツールではありません。パーセントエンコードは内容を隠したり、ハッシュ値を保護したり、セキュリティ上の保証を提供したりしません。
  • 寛容デコードはヒューリスティックな復元です。よくある孤立した % は修復できますが、すべての壊れた UTF-8 シーケンスを復元できるわけではありません。
  • このツールは、テキストが二重エンコードされているかを自動判定しません。1 回デコードすべきか、複数回デコードすべきかは、業務フローに依存します。
  • Query モードは、標準的な & と = の区切りを前提としています。フレームワークがセミコロン、ネストしたパラメータ、独自区切りを使う場合は、先にルールを手動で確認してください。
  • フォームモードが扱うのは+ と空白の違いだけです。フォーム全体のシリアライズ、ファイル、配列、ネストしたオブジェクトを完全に再現するものではありません。
  • このページは文字列を扱うもので、ファイルは扱いません。ファイルをパーセントエンコードされた blob としてアップロードする場合は、専用ツールを使ってください。
  • 内部的にはブラウザの標準的な URL エンコード / デコード機能を使います。一部のレガシーシステムでは予約文字の扱いが異なるため、結果が一致しないことがあります。

よくある質問

処理モード、フォーム形式の空白、二重エンコード、プライバシー、URL エンコードとほかのエスケープ処理の違いについて、実用的な回答をまとめました。

パーセントエンコードとは何ですか？

パーセントエンコードは、URL にそのまま置けないバイトを、% と 2 桁の 16 進数で表す方法です。空白、Unicode、予約文字を含む値でも、URL として解析できる形に保つための形式上の約束です。

値のエンコードと完全な URL のエンコードは何が違いますか？

値のエンコードでは、?、&、=、/、# もすべて内容として扱います。完全な URL のエンコードでは、それらの構造用文字を保つため、結果は URL として解析可能なままです。このツールでは処理対象によって両者を分けています。

+ が空白を表すのはいつですか？

HTML フォーム送信と、その古い慣例に従う Query 文字列だけです。そのような場合はフォームモードを有効にしてください。それ以外の URL 文脈では、+ は単なるプラス記号です。

URL が二重エンコードされているように見えるのはなぜですか？

よくある原因は、すでにエンコード済みの文字列をもう一度エンコードしてしまうことです。業務フローに沿って 1 層ずつデコードし、元の値が見えるところまで確認してください。

厳密デコードと寛容デコードはいつ使い分けますか？

プロトコル検証や API 契約テストでは、無効な入力をすぐ失敗させるために厳密モードを使います。ログ調査やインシデント分析では、部分的に壊れた内容からまず読めるテキストを得たいことが多いため、寛容モードが向いています。

URL エンコードで XSS を防げますか？

防げません。URL エンコードは、文字列を URL に入れられる形にするだけです。XSS 対策には、最終的に表示される文脈に応じた出力エンコードが必要です。たとえば HTML、JavaScript、属性文脈ではそれぞれ別の処理が必要です。

完全な URL モードでフォーム切り替えが隠れるのはなぜですか？

URL のパス、Query、フラグメントでは + も有効な文字です。完全な URL 全体で空白を + に書き換えると、Query 以外の部分を壊す可能性があります。この切り替えは、フォーム慣例が意味を持つ値と Query の文脈だけに適用されます。

Query モードは ? を含む URL をどう扱いますか？

入力が完全な URL として認識できる場合、Query モードは query 部分だけを処理し、その後 URL を組み立て直します。プロトコル、ホスト、パス、フラグメントはそのまま保たれます。

データはブラウザの外へ送信されますか？

いいえ。エンコード、デコード、検証、コピー、往復確認はすべて現在のブラウザタブ内で実行されます。コールバック URL、OAuth state、JWT URL、その他のプライベートな内容がアップロードされることはありません。

どれくらい長い URL を貼り付けられますか？

数千文字なら快適に扱えます。数万文字でも処理できますが、やや重くなります。数 MB 規模の URL blob（多くは Data URL）の場合は、ストリーミングまたはファイル対応ツールのほうが適しています。

IDN ドメインに対応していますか？

ブラウザ実行環境が対応している場合、標準の URL パーサーが IDN ドメインを扱います。Punycode と Unicode ホスト名の専用変換が必要な場合は、IDN 専用ツールを使ってください。このページは主にパス、Query、値のエンコードに焦点を当てています。

ブラウザのアドレスバーでは動く URL が、curl や Postman では失敗するのはなぜですか？

ブラウザのアドレスバーは、生の空白や Unicode をある程度許容し、自動でエンコードしてくれることがあります。curl や Postman は、渡されたバイト列をよりそのまま送る傾向があります。コードや API ツールから URL を送る前に、明示的にエンコードしてください。

関連ツール

エンコードカテゴリ内で関連作業を続けられます。Base64 で認証ヘッダーや token を往復確認し、コールバック URL 内の JWT を確認し、QR コードやバーコード系ツールへ切り替えられます。