Base64エンコーダー/デコーダー

Base64エンコーダー/デコーダーについて

Base64は任意のバイト列を、英大文字・小文字、数字、+、/ の64文字だけで書き表す方式です。メールの添付ファイル、HTTPのBasic認証ヘッダー、JWT、画像のdata URIなど、テキストしか通らない経路でバイナリを運ぶ場面で使われます。

このツールは入力テキストをまずUTF-8のバイト列に変換し、そのバイト列をBase64にします。デコード時は標準アルファベット(+ /)とURLセーフ版(- _)のどちらも受け付け、末尾の=パディングや途中の空白・改行の有無も問いません。

3バイトが4文字になる仕組み

RFC 4648では、入力を3バイト(24ビット)ずつ区切り、6ビット×4つに分けて、それぞれ(0〜63)をアルファベット1文字に置き換えます。「Man」はバイト 4D 61 6E、ビットにすると 010011 010110 000101 101110 で、19・22・5・46 → TWFu です。

最後のまとまりが3バイトに満たないときは=で埋めます。1バイト余れば2文字+==、2バイト余れば3文字+=。「M」はTQ==、「Ma」はTWE=になります。

長さは ceil(n/3)×4 文字。30,000バイトならちょうど40,000文字(+33%)、100バイトなら136文字(+36%)です。MIMEメールは76文字ごとに改行を入れるので、実際の添付は約35%増えます。

Base64は暗号化ではない

鍵がないので、対応表さえあれば誰でも元に戻せます。「dXNlcjpwYXNz」は読みにくいだけで、中身は user:pass そのものです。

Basic認証(RFC 7617)は「ユーザー名:パスワード」をBase64にしてAuthorizationヘッダーに載せます。HTTPSでなければヘッダーを見た人にパスワードが読まれます。JWTも同じで、ヘッダーとペイロードはBase64urlで書かれているだけです。署名は改ざんを防ぎますが中身は隠さないため、トークンの真ん中の部分をこのツールに貼るとユーザーIDや有効期限が見えます。

btoa()が日本語でエラーになる理由

ブラウザのbtoa()は文字列の各文字を1バイト(0〜255)とみなします。「日」(U+65E5)は1バイトに収まらないので btoa("日本") は InvalidCharacterError になります。エラーにならない é のような文字も、UTF-8(2バイト)ではなくLatin-1(1バイト)として符号化されるため、相手がUTF-8で読むと化けます。

正しい順序は テキスト → UTF-8バイト → Base64 です。このツールはTextEncoderでUTF-8にしてから変換します。逆に、Shift_JISで符号化されたデータのBase64を入れると、UTF-8として読むので�が混じります。古いメールの本文をデコードして文字化けする場合はこれが原因です。

標準Base64とBase64url

+と/はURLやファイル名で特別な意味を持つため、RFC 4648の5章はこれを-と_に替えた「URL and Filename safe」アルファベットを定めています。JWTはさらにパディングの=も省きます。

このツールのURLセーフオプションも +→-、/→_ に置換し、末尾の=を削除します。「<<???>>」は標準で PDw/Pz8+Pg==、URLセーフで PDw_Pz8-Pg です。標準Base64をクエリ文字列にそのまま入れると+が空白に変わって壊れることがよくあります。

例

使い方

1. エンコードならテキストを、デコードならBase64文字列を貼り付けます。
2. URLやJWTに使う値ならURLセーフをオンにします(エンコード時のみ有効)。
3. 切り替えボタンで結果を入力側に戻し、往復で一致するか確かめられます。

よくある質問