URLエンコード/デコード

URLエンコード/デコードの使い方

1. 1エンコードまたはデコードを選択します
2. 2URLまたはテキストを入力します
3. 3「変換する」ボタンをクリックして結果をコピーします

URLエンコード/デコードの例文・サンプル

https://example.com/検索?q=東京 観光

良いURLエンコード/デコードの判断基準

日本語や記号を含む URL の作成・解読が必要になったら、変換結果をそのまま使う前に下の判断基準で確認してください。URL エンコードの失敗は「どの範囲を・何回変換したか」のずれから生まれることがほとんどです。

• エンコードする範囲を決めたか

  URL 全体を変換するのか、パラメータの値だけを変換するのかで、正しい処理が異なります。「://」や「?」「&」のような区切りまでエンコードすると URL として機能しなくなるため、対象は値の部分だけに絞るのが基本です。

• 二重エンコードになっていないか

  すでにエンコード済みの文字列を再度エンコードすると、「%」自体が「%25」に変換されて壊れます。変換前の文字列に「%」+英数字 2 桁のパターンが含まれていたら、エンコード済みでないかを疑います。

• デコード結果は意図した文字列に戻ったか

  デコード後の文字列を読み、日本語の文字化けや記号の欠落がないかを確認します。1 回のデコードで読める形にならない場合は、二重エンコードされた文字列の可能性があります。

• 「+」とスペースの扱いを確認したか

  フォーム送信由来のデータでは、スペースが「+」で表現されている場合があります。デコード結果に不自然な「+」が残る時は、その仕様のデータでないかを送信元の仕様で確認します。

• 実際にブラウザで動作確認したか

  エンコードした URL は、机上の確認で終わらせず実際にブラウザで開いて、目的のページ・検索結果に到達するかを確認します。共有リンクは別の環境（スマホ等）でも開けるかを見ると確実です。

• エンコード後の URL が長すぎないか

  日本語はエンコードすると 1 文字が 9 文字程度に膨らみます。URL の長さには環境ごとの上限があるため、長文をパラメータに詰める設計なら別の受け渡し方法も検討します。

ありがちな失敗例（NG → 改善）

日本語や記号を含む URL をそのまま貼って直す

URLには使えない文字（スペース、日本語、特殊記号など）が含まれている場合、URL エンコード（パーセントエンコーディング）が必要です。検索クエリパラメータ・SNS共有リンク・API リクエストパラメータなどで、文字化けや動作不良の原因になります。逆に、エンコードされた URL を読み解きたい場合は、デコードします。本ツールは URL の任意の文字列をエンコード・デコードし、コピー&ペーストですぐ使える形で出力します。

画面にあるのは「テキスト」の入力欄と「変換方向」の選択（エンコードとデコードの2つ）だけです。以下では、編集部が実際に5パターンを変換し、返ってきた文字列をそのまま載せます。どこが変わってどこが変わらないかを並べて見ると、このツールが実際に何をしているのかがはっきりします。

検索リンクの作成・API パラメータ・ログ解析で使う場面

【1. 検索URL や共有リンクの作成】SNSに投稿する時、日本語キーワードを含むURLが正しく動くようエンコードできます。

【2. API リクエストの作成】REST API のクエリパラメータに日本語や特殊記号を含む値を渡す時、エンコードしてから送信してください。

【3. ログ・URL解析】サーバーログや解析ツールで見るエンコード済みURLを、人間が読める形にデコードして内容を理解できます。

3つのうち、いちばん取り違えが起きやすいのは2つ目です。パラメータの値だけを変換したいのか、URL 全体を変換したいのかで、必要な処理が変わります。この違いは考え方の話ではなく、実際に変換した結果の見た目にそのまま出ました。次の項目で、変換された文字と変換されなかった文字を並べます。

日本語混じりの URL をエンコードして戻した実処理結果

変換方向に「エンコード」を選び、次の URL を入れました。

入力: https://example.com/検索?q=テスト 出力: https://example.com/%E6%A4%9C%E7%B4%A2?q=%E3%83%86%E3%82%B9%E3%83%88

この出力をそのまま貼り直して「デコード」に切り替えると、元の https://example.com/検索?q=テスト に完全に戻りました。

注目したいのは、変換されたのが日本語の部分だけで、https の後ろのコロンとスラッシュ、パラメータの区切りである ? と = はそのまま残っている点です。つまり本ツールは、URL の骨格を壊さない範囲で変換します。パラメータの値だけを厳密に変換する処理（プログラムでいう encodeURIComponent）とは対象の範囲が違い、値の中に ? や & が入っている場合は、この結果のままでは意図どおりに届きません。

ただしこれは今回の1本の URL で見えた範囲で、どんな URL でも骨格が保たれる保証ではありません。

プラス記号・%20・二重エンコードを入れた実処理結果

残りの3パターンです。

入力: a+b c（エンコード） 出力: a+b%20c 半角スペースだけが %20 になり、「+」はそのまま残りました。

入力: a%20b（デコード） 出力: a b %20 は半角スペースに戻りました。

入力: %E6%97%A5%E6%9C%AC%E8%AA%9E%20%E3%83%86%E3%82%B9%E3%83%88（エンコード） 出力: %25E6%2597%25A5%25E6%259C%25AC%25E8%25AA%259E%2520%25E3%2583%2586%25E3%2582%25B9%25E3%2583%2588

3つ目は、すでにエンコード済みの文字列をもう一度エンコードした結果です。「%」そのものが %25 に変わりました。これが二重エンコードで、エラーは出ず、文字列が長くなるだけです。受け取った側が1回デコードしても元に戻らないため、リンクが静かに失敗します。

プラス記号をスペースに戻せない仕様と、この変換のクセ

分かったクセは、区切り文字を変換しないことと、「+」を特別扱いしないことの2つです。エンコードで ? や = が残ったのは、URL 全体を対象にする変換（プログラムでいう encodeURI と decodeURI）を使っているためで、実測の結果はその挙動と一致しました。

このクセが問題になるのは、フォーム送信で作られたクエリ文字列です。この形式ではスペースが「+」で表されることがあり、本ツールでデコードしても「+」は「+」のまま残ります。ログや管理画面からコピーした文字列を読み解くとき、単語の間に不自然な「+」が並んでいたら、その形式のデータだと考えてください。本ツールだけではスペースに戻せません。

弱点は、まさにこの一点です。今回試した5パターンでは、処理が止まる、文字が欠けるといった破綻は起きませんでした。ただし構造上、「+」をスペースとして解釈する形式には対応していません。これも5パターンで見えた範囲であり、どんな文字列でも壊れない保証ではありません。

エンコードに向かない文字列と、二重変換を避ける手順

1つ目は、URL 全体を対象にする変換と、パラメータの値だけを対象にする変換の違いを意識しないことです。前者はURL全体のエンコード、後者はクエリパラメータの値のエンコードに使います。実測では区切り文字の : / ? = が変換されずに残ったため、本ツールの動きは前者にあたります。値の中に & や ? を含む文字列を渡す場合は、送信先の仕様に合わせて値だけを変換する処理が別に必要です。

2つ目は、二重エンコードです。エンコード済みのURLを再度エンコードすると「%25」のような形になり、意図しない結果になります。実測でも「%」が %25 に変わりました。変換前の文字列に「%」と英数字2桁の並びがあるかどうかを見るのが、いちばん早い見分け方です。

3つ目は、URLの最大長です。URL長は実装によって2,000〜8,000文字制限があるため、エンコード後に長くなりすぎる場合は別の手段（POSTでボディ送信など）を検討してください。

向かないのは、フォーム送信由来の「+」を含む文字列を元の形に戻す用途、1文字も変えてはいけない認証情報の加工、そして原文をそのまま保たなければならない提出物の整形です。

開発者ツールや言語標準の関数との使い分け

JavaScript の encodeURIComponent() や Python の urllib.parse.quote() でも変換可能ですが、ブラウザですぐ確認したい時に手間です。本ツールはブラウザ内で完結し、サーバー送信なしで変換できます。会員登録もログインも不要です。

実測を踏まえた使い分けの目安ははっきりしています。手元の1本の URL を今すぐ読める形にしたい、共有リンクを1回だけ作りたい、という場面は本ツールが速い。パラメータの値だけを厳密に変換したい、フォーム形式の「+」をスペースとして扱いたい、大量の URL をまとめて処理したい、という作業は言語側の関数が向きます。前者の用途では、日本語混じりの URL が往復して元の形に戻りました。

変換した URL を共有する前に確認する3点

1つ目は、エンコード後に : / ? = が残っているかを目で見ることです。実測ではこれらが残り、URL の形は保たれました。もし https%3A%2F%2F のように骨格まで変換されていたら、変換の範囲を間違えています。

2つ目は、変換前の文字列に「%」と英数字2桁の並びが無いかです。あれば、すでにエンコード済みの可能性が高く、もう一度かけると %25 が増えます。

3つ目は、実際にリンクを開くことです。エンコードした URL を自分でクリックし、目的のページや検索結果に届くかを確認します。文字列を眺めるだけでは、二重エンコードも「+」の混入も見落としやすいためです。

この3点は、5パターンの変換結果から見えた事実に沿って並べています。