結論：文字で運ぶための表現で、秘密にする機能ではない
6つの作例を変換したところ、Base64はすべて元の文字へ戻せました。例えば Hello は SGVsbG8= になります。変換には鍵やパスワードを使っていません。見慣れない文字の並びになることと、内容を秘密にできることは別です。
Base64はデータを決まった文字で表すエンコード方式です。受け取った文字列に読めない部分があっても、それだけで暗号化済みとは判断できません。元データを戻すデコードとの関係を、短い作例で確かめます。
Base64変換Helloを変換し、元の文字へ戻る作例を見る登録なしで使えます開く
読み方：文字数ではなく元のバイト数から見る
通常のBase64では、3バイトを4文字で表すまとまりが基本です。A〜Z、a〜z、0〜9、+、/の64種類を使い、末尾をそろえるための記号として = が付く場合があります。
| 見る点 | 作例 | 分かること |
|---|---|---|
| 元の文字列 | Hello |
UTF-8で5バイト |
| エンコード後 | SGVsbG8= |
8文字で元データを表す |
| デコード後 | Hello |
正しい方式なら元の内容へ戻せる |
末尾の = |
Zg==、Zm8= |
3バイト単位に満たない末尾を補う記号 |
- や _ を使う形式 |
Base64url | 通常のBase64と文字の扱いが異なる |
Base64urlを通常のBase64と同じ名前だけで扱わないことも要点です。RFC 4648では別の節で定義されています。今回測ったのは + と / を使う通常のBase64です。
6つの文字列を往復させた
2026年9月30日、Base64変換ツールの現行ロジックをNode.js 24.15.0で実行しました。英字・日本語・絵文字の計6文字列（n=6）をUTF-8としてエンコードし、得た文字列をデコードしています。
| 元の文字列 | UTF-8のバイト数 | Base64 | Base64の文字数 |
|---|---|---|---|
f |
1 | Zg== |
4 |
fo |
2 | Zm8= |
4 |
foo |
3 | Zm9v |
4 |
Hello |
5 | SGVsbG8= |
8 |
日本 |
6 | 5pel5pys |
8 |
😀 |
4 | 8J+YgA== |
8 |
6件中6件で、デコード後の文字列が元と一致しました。これは暗号を解く試験ではなく、公開された変換規則で元に戻るかの試験です。
容量については、元のバイト数を3で割って切り上げ、4を掛けた文字数になりました。1バイトが4文字になる短い例もあるため、「必ず元の文字数の約1.33倍」とは言えません。比べる元は文字数ではなくバイト数で、短いデータでは末尾の補完の割合も大きくなります。
一次資料：RFCの文字の種類と機密性の説明
文字の種類、URL向けの方式、秘密を守る性質はRFC 4648に記載されています。以下は3か所の短い抜粋です。
「A 65-character subset of US-ASCII is used」
— RFC 4648 §4 Base 64 Encoding https://www.rfc-editor.org/rfc/rfc4648.html#section-4（2026-09-30 到達）
この65には末尾の = を含みます。データを表す64種類と、補完に使う記号を分けると名前との関係が分かります。
「This encoding may be referred to as "base64url".」
— RFC 4648 §5 Base 64 Encoding with URL and Filename Safe Alphabet https://www.rfc-editor.org/rfc/rfc4648.html#section-5（2026-09-30 到達）
URL向けのBase64urlは、通常の方式と同一視しないように同節で説明されています。見た目が似ていても、どちらを要求するデータなのかが前提です。
「does not provide any computational confidentiality.」
— RFC 4648 §12 Security Considerations https://www.rfc-editor.org/rfc/rfc4648.html#section-12（2026-09-30 到達）
Base64だけでは、内容の機密性は得られません。今回の作例も、変換の前後で鍵を使わずに元へ戻っています。
間違えやすい点
戻せる表現への変換と、秘密を守る仕組みを分けることが読み取りの出発点です。
| 取り違え | 実測・仕様から分けられること |
|---|---|
| 英数字になったから内容は隠れた | 作例は鍵なしで6件とも元へ戻った |
| Base64はファイルを小さくする圧縮 | 今回の6件は元のバイト数より長い表現になった |
| 日本語2文字なら元も2バイト | 作例の「日本」はUTF-8で6バイト |
= は元のパスワードの一部 |
この例ではエンコード末尾の補完記号 |
| 英数字だけなら全部Base64 | 文字の見た目だけで意味や変換元は確定しない |
デコードできることは、データの安全性を示しません。単にその方式で解釈できるかという結果です。また、元が文字ではなく画像などのバイナリなら、戻した結果が人の読める文章になるとは限りません。
測っていないこと・ここから先は推論
画像・添付ファイル・外部サービスとの送受信は測っていません。今回の対象は短いUTF-8文字列6件です。Base64url、改行入りの長いデータ、省略した補完記号、不正な入力の網羅試験もしていません。
パスワードの強さや通信路の保護は、この試験の対象外です。「元に戻った」という結果から、特定サービスの認証や暗号方式の安全性を評価してはいません。実データでは、変換方式の前後に別の圧縮や暗号化が組み合わされている可能性もあります。
次の1手
秘密を含まない Hello をBase64変換へ入れると、エンコード後の値と、その値から戻る文字を確認できます。
Base64変換HelloとSGVsbG8=の往復を確かめる登録なしで使えます開く
次に使う道具：Base64変換