Base64とは？
Base64は、バイナリデータをASCII文字列に変換するエンコード方式です。名前の由来は、64種類の印刷可能な文字（A-Z、a-z、0-9、+、/）を使ってデータを表現することにあります。パディングには「=」記号が使われます。1993年にRFC 1421で最初に定義され、現在のインターネット標準ではRFC 4648で規格化されています。
Base64は「エンコード」であり「暗号化」ではありません。誰でも簡単に元のデータに復元できるため、機密情報の保護には使えません。あくまでデータの形式を変換する手段として理解することが重要です。
Base64の仕組み ─ 6ビットエンコーディング
Base64の変換プロセスは、元のデータを6ビットずつに区切ることで行われます。通常のバイトデータは8ビット単位ですが、Base64では3バイト（24ビット）を4つの6ビットグループに分割します。各6ビットグループ（0〜63の値）を、対応する64種類の文字に置き換えることで、バイナリデータをテキストとして表現できます。
元のデータが3バイトの倍数でない場合は、不足分をゼロで埋めてからエンコードし、出力の末尾に「=」または「==」のパディングを追加します。この仕組みにより、Base64でエンコードされたデータは元のデータより約33%サイズが大きくなります。3バイトが4文字になるため、4/3倍のデータ量になるのです。
Base64の主な用途
メール添付ファイル（MIME）
電子メールのプロトコル（SMTP）はもともとASCIIテキストしか扱えませんでした。画像やPDFなどのバイナリファイルをメールに添付するために、MIMEという規格でBase64エンコードが使われています。メールクライアントは送信時に添付ファイルをBase64に変換し、受信時に自動的にデコードして元のファイルに復元します。
データURI
HTMLやCSSの中に小さな画像やフォントを直接埋め込むために、データURIスキームが使われます。たとえば、小さなアイコン画像をBase64エンコードしてCSSのbackground-imageに記述すれば、HTTPリクエストを減らしてページの読み込み速度を向上させることができます。ただし、大きなファイルをデータURIにするとHTMLファイル自体が肥大化するため、数KB以下の小さなリソースに限定して使用するのが一般的です。
APIトークンとHTTP認証
HTTP Basic認証では、ユーザー名とパスワードを「ユーザー名:パスワード」の形式で連結し、Base64エンコードしてAuthorizationヘッダーに含めます。また、APIキーの送受信やOAuth認証のフローでもBase64が利用されることがあります。繰り返しますが、Base64は暗号化ではないため、必ずHTTPS（TLS）と組み合わせて使用する必要があります。
JWT（JSON Web Token）
JWTは、ヘッダー・ペイロード・署名の3つの部分をBase64URLエンコードし、ピリオドで連結した文字列です。Webアプリケーションの認証やセッション管理で広く使われています。JWTのペイロードはBase64デコードするだけで内容を読めるため、トークンに機密情報を含めないよう注意が必要です。
Base64は暗号化ではない
開発者の間でよくある誤解のひとつが、Base64を暗号化の手段として使うことです。Base64は単なるエンコーディングであり、鍵を使った暗号化アルゴリズム（AES、RSAなど）とは根本的に異なります。Base64エンコードされたデータは、誰でもデコードして元の内容を読むことができます。パスワードやクレジットカード番号などの機密情報をBase64でエンコードしただけでは、セキュリティは一切向上しません。機密データを保護するには、TLSによる通信暗号化や、AES-256などの暗号化アルゴリズムを使用してください。
URL-safe Base64とは
標準のBase64では「+」と「/」の記号が使われますが、これらはURLやファイル名では特別な意味を持つ文字です。URLのクエリパラメータにBase64文字列を含めると、「+」がスペースに変換されたり、「/」がパスの区切りと解釈されたりする問題が生じます。
この問題を解決するために、RFC 4648ではURL-safe Base64（Base64URL）が定義されています。標準の「+」を「-」（ハイフン）に、「/」を「_」（アンダースコア）に置き換え、パディングの「=」を省略する形式です。JWTや多くのWebフレームワークでは、このURL-safe Base64が採用されています。