Base64・URLエンコードのやり方と使いどころ

どちらも「そのままでは運べないデータを運ぶ」ための変換

Base64とURLエンコードは名前が似た印象を与えますが、解決している問題が異なります。

• Base64：画像やファイルのような「バイナリデータ」を、英数字と少しの記号（A-Z a-z 0-9 + / =）だけの文字列に変換する方式。テキストしか運べない場所（メールの仕組み、JSON、設定ファイルなど）にデータを通すために使います
• URLエンコード：URLに使えない文字（日本語・空白・&や?などの記号）を「%＋16進数」の表記に置き換える方式。「検索キーワードに日本語を含むURL」が壊れずに機能するのはこの変換のおかげです

見分け方は簡単で、%が多発していればURLエンコード、英数字の塊で末尾に=が付いていることが多いのがBase64です。

実務での「使いどころ」具体例

開発やIT関連の作業では、次のような場面で日常的に登場します。

• APIの認証情報：Basic認証では「ユーザー名:パスワード」をBase64にした文字列をヘッダーに載せます。kintoneのAPIトークン連携など、業務システムのAPI設定画面でBase64文字列を求められることがあります
• APIテストでのレスポンス確認：APIが返すBase64のデータをデコードして中身を確認する、逆にテスト用データをエンコードして送る
• 画像のデータURI：小さなアイコン画像をBase64にしてHTMLやCSSに直接埋め込む手法。ファイルを分けずに1ファイルで完結させたいときに使われます
• メールやログの調査：メールのソースや送信ログに現れるBase64の件名・本文を読める形に戻す
• リンクの生成：検索結果ページへの直リンクや、パラメータ付きURLを手作業で組み立てるときのURLエンコード

最重要の注意：エンコードは「暗号化」ではない

Base64もURLエンコードも、誰でも1秒で元に戻せる可逆変換であり、秘密を守る機能は一切ありません。見た目がランダムな文字列に見えるため「暗号化されているように見える」のが危険なところで、実際に次のような事故が起きています。

• 「パスワードはBase64にして保存してあるから安全」→ デコードすれば平文と同じです
• URLのパラメータに個人情報をBase64で載せる → URLはアクセスログや履歴に残るため、実質平文で個人情報をばらまいているのと同じです

秘密にしたいデータには暗号化（および保存ならハッシュ化）という別の技術が必要です。「読める形に戻されて困るものはエンコードで隠さない」と覚えてください。ハッシュについてはハッシュ値照合の記事で解説しています。

ツールで変換するときの小ネタ

• 日本語をBase64にすると、データ量は元の約1.33倍になります（3バイトを4文字で表す仕組みのため）。「Base64にしたら軽くなる」は誤解で、むしろ増えます
• URLエンコードには「空白を%20にする方式」と「+にする方式」の2流派があり、貼り付け先によって期待される方式が違うことがあります。デコード結果に+が残って不自然な場合はこの違いを疑ってください
• 変換対象に認証情報などが含まれることも多いため、変換ツールは入力内容が外部に送信されないものを選ぶのが安全です。Base64・URLエンコード/デコードツールはブラウザ内だけで変換します

よくある質問

Q. デコードしたら文字化けしました。なぜですか？
A. Base64を解いた先のデータの文字コード（UTF-8/Shift-JISなど）が想定と違うか、そもそもテキストではなく画像などのバイナリデータである可能性があります。また、文字列の途中で改行や空白が混入していると正しくデコードできないことがあります。

Q. 「%E3%81%82」のような文字列はデコードできますか？
A. はい、それはURLエンコードされた文字列です（%E3%81%82は「あ」）。%と16進数の並びが特徴で、URLエンコードのデコード欄に貼り付ければ元の文字列に戻せます。

あわせて使いたいツール