Base64は暗号化ではありません|正しい使いどころ
2026.10.03 更新 · 4分で読めます
Base64はバイナリをASCII文字に置き換える表現形式で、鍵がないため誰でも元に戻せます。使いどころ、URLセーフ形式、パディング、サイズが4/3になる理由をRFC 4648をもとに説明します。
Base64 エンコード・デコードをすぐに使うBase64は暗号化ではなく表現形式です。誰でも元に戻せます。鍵がなく、変換の規則も公開されているので、Base64 エンコード・デコードで方向を「デコード」にして44K844Kt44Otを入力すれば、すぐにゼキロが出てきます。パスワードやトークンをBase64にしても、隠したことにはなりません。Base64の目的は、テキストしか通せない経路でバイナリデータを壊さずに運ぶことです。
Base64の仕組み
RFC 4648によると、Base64は入力を3バイト(24ビット)ずつ区切り、6ビットのかたまり4つに分けて、それぞれを1文字で表します。使う文字はA–Z、a–z、0–9、+、/の64文字と、長さをそろえるための=です。
| 入力 | バイト数 | Base64 |
|---|---|---|
ZEKILO |
6 | WkVLSUxP |
ZEKIL |
5 | WkVLSUw= |
ゼキロ |
9(UTF-8) | 44K844Kt44Ot |
제킬로 |
9(UTF-8) | 7KCc7YKs66Gc |
Base64が扱うのは文字ではなくバイトです。テキストは、まずUTF-8などの文字コードでバイト列にしてから変換するため、文字コードが違えば結果も変わります。ブラウザのbtoaは、U+00FFより大きい文字が含まれているとInvalidCharacterErrorを投げます。日本語は、TextEncoderでUTF-8のバイト列にしてからエンコードしてください。
エンコード・暗号化・ハッシュの違い
| 種類 | 元に戻せるか | 鍵 | 目的 |
|---|---|---|---|
| エンコード(Base64) | 誰でも戻せる | なし | 形式を変える |
| 暗号化(AESなど) | 鍵があれば戻せる | あり | 内容を隠す |
| ハッシュ(SHA-256など) | 戻せない(一方向) | なし | 内容が同じかを確かめる |
RFC 4648 12節は、Base系のエンコードはパスワードのように見てすぐわかる情報を目立たなくするだけで、機密性は提供しないと述べています。
代表的な例がHTTPのBasic認証です。RFC 7617に載っているヘッダーの例Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==の後半をデコードするとAladdin:open sesame、つまりユーザー名とパスワードがそのまま出てきます。同じ文書は、TLSなどの外部の安全な仕組みと組み合わせない限り、この方式を安全な認証方法とはみなさないとしています。JWTのヘッダーとペイロードもBase64URLで書かれているだけなので、誰でも読めます。詳しくはJWTのデコードと署名検証の違いをご覧ください。
使いどころ
- メールの添付ファイル(MIME):1行が76文字を超えないように改行します(RFC 2045)。
- Data URL:
data:text/plain;base64,WkVLSUxPのように、小さなファイルをHTMLやCSSに直接埋め込みます(RFC 2397)。 - JSON・XMLのフィールド:画像や署名値などのバイナリを、テキストのフィールドに入れます。
- PEM形式の証明書・鍵:64文字ごとに改行します(RFC 7468)。
- JWTやURLのパラメーター:次のURLセーフ形式を使います。
RFC 4648は、参照する側の仕様が定めていない限り改行を入れてはならないとしています。改行が必要かどうかは、受け取る側の形式に合わせてください。
URLセーフ形式とパディング
標準の文字のうち+と/は、URLやファイル名では別の意味を持ちます。そこでRFC 4648 5節は、この2文字を-と_に置き換えた形式を定めています。バイト列FB FF BFは、標準では+/+/、URLセーフ形式では-_-_になります。
パディングの=は、出力の長さを4の倍数にそろえます。最後に1バイト余ると2文字と==、2バイト余ると3文字と=になります。RFC 4648は、参照する側の仕様が定めていない限りパディングを付けるよう求めており、JWTが使うBase64URL(RFC 7515)はパディングを省きます。パディングがなくても長さから復元できるので、WkVLSUwはZEKILにデコードできます。長さを4で割った余りが1になるものは、正しいBase64ではありません。
デコードに失敗したときは、まず文字を確認してください。WkVLSUxP!は、9文字目の!がBase64の文字ではないためエラーになります。
サイズは4/3になる
3バイトが4文字になるので、パディングを付けた出力の長さは4 × ⌈n ÷ 3⌉です。約33%増えます。
| 元のデータ | Base64の長さ |
|---|---|
| 6バイト | 8文字 |
| 9バイト | 12文字 |
| 1 MiB(1,048,576バイト) | 1,398,104文字 |
| 3 MiB(3,145,728バイト) | 4,194,304文字(4 MiB) |
改行を入れると、その分だけさらに増えます。大きなファイルをBase64にしてJSONに入れると、転送量もメモリ使用量も増えます。大きなファイルは、バイナリのまま送る方法を先に検討してください。
まとめ
- Base64は形式を変えるエンコードです。鍵がないので、内容を隠すことはできません。
- パスワード、APIキー、個人情報は、Base64にしてもそのまま読めます。隠す必要があるなら暗号化とTLSを使ってください。
- URLやJWTでは
-と_を使うURLセーフ形式を使い、パディングの扱いは受け取る側の仕様に合わせます。 - サイズは約4/3倍になります。
- 値を確認するときはBase64 エンコード・デコードを使ってください。入力はブラウザ内だけで処理されます。
この記事に関連するツール
出典と基準
- RFC 4648 — The Base16, Base32, and Base64 Data Encodings
- RFC 2045 — MIME Part One (Base64 Content-Transfer-Encoding)
- RFC 7468 — Textual Encodings of PKIX, PKCS, and CMS Structures
- RFC 2397 — The "data" URL scheme
- RFC 7617 — The 'Basic' HTTP Authentication Scheme
- HTML Standard — Base64 utility methods (btoa, atob)