Base64 エンコード・デコードツール

Base64エンコードとデコードを高速処理、UTF-8テキスト変換対応

入力内容

文字数: 0

バイト数: 0

変換結果

文字数: 0

バイト数: 0

変換方法を選択

Base64とは？

Base64は、64個の印刷可能文字を使用してバイナリデータを表すエンコード方式です。この64文字には大文字A-Z、小文字a-z、数字0-9、および+と/の2つの記号が含まれます。印刷可能文字のみを使用するため、Base64エンコード後のデータは、メール、ウェブページ、JSONなどテキストのみをサポートする環境で安全に送信できます。エンコード後のデータは元のデータより約33%増加します。Base64は1987年のPEMプロトコルで初めて登場し、メールでのバイナリデータの安全な送信に使用されました。現在ではインターネット標準の一つとなり、メール添付ファイルからJWTトークン、画像埋め込みからデータ送信まで、様々な場面で広く使用されています。ほぼ全てのプログラミング言語にBase64エンコード・デコード機能が組み込まれています。

使い方

左の入力ボックスにテキストを貼り付けます
「エンコード」または「デコード」を選択します
結果は右側に自動表示されます
コピーボタンをクリックして結果をコピー

よくある落とし穴

Base64はエンコード方式であり暗号化ではありません。テキストを入手すれば誰でもデコードできるため、機密情報の保護目的には使用しないでください。
デコードに失敗した場合、パディングの欠落、コピー時の改行、URL-safe Base64文字、または前後の引用符を確認してください。

利用シーン

UnicodeテキストをBase64専用フィールド向けにエンコードする名前、絵文字、改行、CJK文字を含むテキストを貼り付けると、btoaの前にTextEncoderで処理するため、ブラウザのUnicode処理でよくある非ASCII入力の文字化けを回避できます。入力文字列はブラウザタブの外に出ず、エンコードはメモリ上のTextEncoderに対して実行され、生成されたアルファベット文字はコピーするまでローカルDOMに留まります。

デバッグ中にコピーしたペイロードの断片をデコードするログ、JSONフィールド、ヘッダー、設定ファイル、サポートチケットに見つかった値をデコードモードで処理します。不正なBase64は誤解を招く部分結果を生成する代わりに明確なエラーを返します。デコード処理もローカルで実行され、atobとTextDecoderがバイト列をページ内で文字列に再構成するため、元のデータと同じマシン上に留まります。

公開前に往復テストでサンプルを検証するエンコードまたはデコード後にスワップボタンを使えば、サンプルが元のテキストに戻ることを確認できます。APIドキュメント、Webhookのサンプル、READMEの抜粋、テストフィクスチャなど、1文字の誤りがサンプルを壊す場面に有効です。すべてクライアント側で実行されるため、ペイロードをサードパーティのデコーダーにアップロードせずに繰り返し往復テストできます。

JWTのヘッダーまたはペイロードセグメントを確認するJWTのドットで区切られたセグメントのうち1つをデコードし、ヘッダーまたはクレームのJSONをデバッグ中に読み取ることができます。署名検証は本来のライブラリに任せてください。このページは署名を検証しないため、認証チェックや本番パスでの内容の信頼には使わないでください。ここでデコードされたトークンはブラウザから出ないため、内部クレームを含む本番トークンのデバッグ時に重要です。

小さなdata: URIをインラインアセット向けに構築する小さなSVG、favicon、CSSスニペットをdata: URIにエンコードし、スタイルシート、README、メールテンプレートに直接貼り付けできます。アセットをアップロードできないインラインプレビューに便利ですが、大きな画像を埋め込む場合は33%のサイズ増加に注意してください。元のバイトは入力欄から読み込まれ、エンコード結果はローカルに留まるため、未公開のアイコンでもマークアップにアップロードせずにテストできます。

仕組み

Base64はRFC 4648（S. Josefsson、2006年10月）で規定された複数のバイナリ-テキストエンコーディングの1つで、Base16（16進数）やBase32も含まれます。'Base64'という名称とアルファベットは元々Privacy-Enhanced Mail（RFC 989、1987年）で定義され、PEMはバイナリのS/MIMEやX.509素材を印刷可能ASCIIのエンベロープでラップし、7ビットクリーンなトランスポートを通過できるようにしました。同じアルファベットは後にMIME（RFC 2045）、JWT署名（RFC 7519）、HTML data: URI（RFC 2397）、SSH公開鍵ブロブ（RFC 4253 §6.6）、Git LFSポインタファイル（SHA-256ハッシュをBase64で格納）の事実上の標準となりました。Git自体のパックファイルはBase64ではなく、デルタエンコーディングとzlib圧縮を使用し、GitオブジェクトIDは40文字の16進SHA-1文字列でありBase64ではありません。コストは入力3バイトごとに4文字の出力となり、エンコードされた出力は正確に4/3倍（33.3%のオーバーヘッド）になります。10MBのバイナリブロブに対してエンコード後の形式は約13.3MBです。メカニズムは入力を3バイト（24ビット）のグループに分割し、各グループを4つの6ビット値に分解し、各6ビット値が64文字のアルファベットから1文字を選択します。正規のアルファベットはA-Z（インデックス0-25）、a-z（26-51）、0-9（52-61）、'+'（62）、'/'（63）で、パッド文字は'='です。RFC 4648の古典的な例では、'Man'（0x4d 0x61 0x6e）は24ビット値0x4d616eにパッキングされ、6ビットチャンクに分割すると0x0d 0x16 0x0e 0x0aとなり、'TWFu'にマッピングされます。入力長が3の倍数でない場合、末尾のグループは右側にゼロパディングされます：残り1バイト→有意な6ビットチャンク2つ + '=='（パッド文字2つ）、残り2バイト→有意チャンク3つ + '='（パッド1つ）。パッド文字は情報を一切持ちませんが、エンコーディングの長さを入力長の決定論的関数にし、デコーダーが切り詰められた入力を拒否できるようにします。ブラウザでのBase64には2つの有名な落とし穴があります。第1に、btoaとatob（DOMStringバリアント）はLatin-1コードユニットで動作し、バイトではありません。U+00E9（é）やU+4E2D（中）を含む文字列を渡すとInvalidCharacterErrorがスローされます。本ページではbtoaの前に`TextEncoder().encode(str)`（常にUTF-8）をパイプし、atobの後に`TextDecoder().decode(bytes)`を使用することでこの問題を回避しています。UTF-8のマルチバイト文字は拡張されます：'你'は3バイト（0xe4 0xbd 0xa0）でBase64文字4文字（'你好'では8文字）になります。第2に、Base64URL（RFC 4648 §5）は'+'と'/'を'-'と'_'に置換しパディングを除去します。これは'+'と'/'がURLで特別な意味を持ち、'='がクエリ文字列を終端するためです。JWT（RFC 7519）とJWS（RFC 7515）がまさにこの理由でBase64URLを要求します。 Base64はエンコーディングであり暗号化ではありません。エンコードされた形式は機密性が一切なく、アルファベットが非常に短いため誰でも結果を簡単に読み取れます。Base64をセキュリティメカニズムと誤解することはCVEパターンです：CVE-2004-2761は攻撃者に衝突するMD5署名で証明書を偽造させたX.509 MD5選択プレフィックス衝突を文書化し、CVE-2005-4900その他では$1$ md5cryptパスワードハッシュがBase64デコードバイトと新規の資格情報を混同する認証層によって再エンコードまたは再ハッシュされるという旧来の慣行が関与していました。繰り返し発生するパターンは同じです：システムがエンコーディングに実際には存在しない秘匿性の層を付与したかのように扱い、その結果が悪用可能になるということです。本当に秘匿するデータにはAES-GCM（RFC 5288）またはChaCha20-Poly1305（RFC 8439）を使用してください。圧縮後にBase64エンコードする場合（`gzip -b64`が行う処理）、エンコード後の形式はgzip後のサイズの約1.37倍であり、圧縮ストリームのバイト変更はデコードを破壊するため、Base64は完全性の層としては不適切です。エンコード前のバイトに対するHMAC-SHA256が正しいアプローチです。

RFC 4648（2006年10月）は正規のアルファベット（A-Z、a-z、0-9、+、/）とパッド文字'='でBase64、Base32、Base16を定義しています。MIMEバリアント（RFC 2045）は76文字ごとに改行を挿入し、URL安全バリアント（Base64URL、RFC 4648 §5）は+と/を-と_に置換してパディングを除去します。JWT（RFC 7519）、JWS（RFC 7515）、JWK（RFC 7517）で使用されます。
メカニズム：入力3バイト（24ビット）→出力4文字（各6ビット）。オーバーヘッドは33.3%で、1MBのバイナリ入力は1.33MBのBase64になります。入力に'='や周囲のプロトコルによってエスケープされるその他の文字が含まれる場合、ASCIIの比率はさらに悪化することがあります。
パディングルール：入力長 mod 3 = 0→パディングなし、mod 3 = 1→'=='（パッド文字2つ、1バイトエンコード）、mod 3 = 2→'='（パッド文字1つ、2バイトエンコード）。'='は情報を一切持たず、デコーダーに何バイトが削除されたかを知らせるだけです。
UTF-8 + btoaの落とし穴：btoaは入力をLatin-1コードユニットとして扱うため、`btoa('é')`はInvalidCharacterErrorをスローします。本ページではbtoaの前にTextEncoder（UTF-8）でエンコーディングし、atobの後にTextDecoderでデコードすることで回避しています。このステップなしではU+0000..U+00FF以外はエラーではなく'0バイトエンコード'になります。
Base64URLはJWT、JWS、JWK（RFC 7519/7515/7517）で必須です。'+'と'/'（URLで特別な意味を持つ文字）の代わりに'-'と'_'を使用し、'='のパディング（クエリ文字列を終端する）を削除します。JWTヘッダーセグメントをBase64URLデコーダーではなくBase64デコーダーに渡すと不正な結果になります。本ページでは自動検出を行わないため、ペイロードに応じて正しいバリアントを選択してください。
パフォーマンス：モダンなノートPCのV8ではエンコードは約400〜700 MB/s（テーブルルックアップとビットシフトのタイトなループ）。デコードも同程度の速度です。大きなブロブ（10MB超）ではボトルネックは計算ではなくアロケーションで、出力バッファは33%大きく、TextEncoder/TextDecoderはコピーを行います。
Base64はエンコーディングであり暗号化ではありません。文字列を入手した誰でも読めます。CVE-2004-2761（X.509 MD5選択プレフィックス衝突、証明書署名）や多くのMISC-CTFのwriteupがこの誤解を最初の足がかりとして利用しています。秘匿するデータにはAES-GCM（RFC 5288）またはChaCha20-Poly1305（RFC 8439）を使用してください。data URIではエンコード後のサイズに注意してください：10MBの画像は13.3MBのURLになり、ほとんどのブラウザのURL長制限やメールのサイズ制限を超えます。
移行に関する注意：Base16（16進数）は低レベルプロトコルやハッシュ出力で好まれます。各バイトが正確に2文字にマッピングされ長さが予測可能（パディングの計算が不要）なためです。Base32は人間の転記に好まれます（紛らわしい類似文字がないため）。Base64はテキストプロトコルでのバイナリトランスポートの汎用デフォルトですが、HTTP/2やWebTransportではフレーミングが許す限り生のバイトに徐々に置き換えられています。

使用例

ASCII テキストのエンコード

入力: Hello
出力: SGVsbG8=    (5 バイト -> 8 文字、パディング 1 文字)

入力: Hello, World!
出力: SGVsbG8sIFdvcmxkIQ==    (13 バイト -> 18 文字、パディング 1 文字)

入力: Man
出力: TWFu    (3 バイト -> 4 文字、パディングなし)

'Man' は RFC 4648 の標準ベクタで、バイト 0x4D 0x61 0x6E が
24 ビット値 0x4D616E にまとまり、6 ビット単位 0x0D 0x16 0x0E 0x0A
に分割され、標準アルファベットで T W F u にマップされます。

UTF-8 テキスト (中国語) のエンコード

入力: ni hao   (3 ASCII バイト)
出力: 5L2g5aW9    (8 文字)

入力: ni hao shi jie   (CJK 4 文字、UTF-8 で 12 バイト)
出力: 5L2g5aW95LiW55WM    (16 文字)

CJK 文字 1 つは UTF-8 で 3 バイトに展開されるため (E4 BD A0 など)、
Base64 出力はおよそ 4/3 倍、さらに 4/3 倍となり、エンコード後の
文字数は元のおよそ 2.67 倍になります。ツールは btoa の
'InvalidCharacterError' を回避するため、まず
TextEncoder().encode(str) を通します。

JWT セグメントのデコードと往復変換

エンコード: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
デコード:   {"alg":"HS256","typ":"JWT"}

往復変換:
  encode('{"alg":"HS256","typ":"JWT"}') -> eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
  decode('eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9') -> {"alg":"HS256","typ":"JWT"}

JWT セグメントは Base64URL を使うため、ツールは標準の '+' / '/' に加え
'-' / '_' も受け付ける必要があります。JWT ヘッダを厳格な Base64
デコーダに通すと文字化けするので、ペイロードに合わせて適切な
バリアントを選んでください。

Base64 と Base64URL の違い

入力: Hello><h2>

標準:        SGVsbG8+PGgyPg==    (+ / = パディング、JSON / メール内で安全)
URL セーフ:  SGVsbG8-PGIyPg       (- _ パディングなし、URL のパス/クエリで安全)

相違点:
  '+' (62)  ->  '-'   と  '/' (63)  ->  '_'
  URL セーフ形式では '=' パディングを完全に削除
JWT、JWS、JWK、URL クエリ文字列で運ばれるトークンには Base64URL を
使ってください。'+' / '/' は URL で特別な意味を持ち、'=' はクエリを
終端させてしまうためです。

よくある質問

Base64は暗号化ですか？

いいえ。Base64はエンコードであって暗号化ではありません。任意のバイトを64個の印字可能なASCII文字（A〜Z、a〜z、0〜9、+、/）に変換し、バイナリデータを破壊するシステムを通過できるようにするだけです。エンコードされた文字列を持つ人は誰でもすぐに復号でき、秘密は一切関与しません。

なぜエンコード結果の末尾に1つまたは2つの「=」が付くのですか？

Base64は3バイトの入力につき4文字の出力を生成します。入力長が3の倍数でない場合、エンコーダーは結果の長さが4の倍数になるよう「=」でパディングします。残り入力が1バイト → 「==」、2バイト → 「=」、揃っている場合 → なし、です。一部の実装ではパディングを省略しますが、これは合法ながらすべての環境で互換とは限りません。

URLセーフBase64とは何ですか？

標準のBase64には、URLやファイル名で特別な意味を持つ「/」と「+」が含まれます。URLセーフBase64（RFC 4648 §5）はこれらを「_」と「-」に置き換え、しばしば「=」パディングを省きます。JWTトークン、URLパラメータ、ファイル名にはこれを使い、それ以外では標準Base64を使ってください。

なぜBase64文字列は元データより約33%長くなるのですか？

入力の6ビットごとに8ビットの出力文字1つになるため、エンコード後のサイズ = ceil(input_length / 3) * 4 となります。これは入力の約4/3（33%のオーバーヘッド）です。任意のバイトを印字可能なASCIIで表すコストです。

ここにはどんな入力形式を貼り付けられますか？

エンコード時は、プレーンテキスト（内部ではUTF-8でエンコード）を貼り付けるか、ファイルをアップロードします。デコード時は、空白の有無にかかわらずBase64文字列を貼り付け可能で、デコーダーは改行を自動的に除去します。デコードに失敗する場合は、不正な文字や欠けたパディング「=」がないか確認してください。

Base64でバイナリファイルの内容を運べますか？

はい。これが主な用途です。HTML/CSSのインライン画像（data: URL）、メール添付ファイル（MIME）、HTTPヘッダーの認証情報（Basic認証）はすべて、テキスト専用のチャネルにバイナリ内容を載せるためにBase64を使います。ただし、結果のペイロードは元ファイルより33%大きくなる点に注意してください。

機密データを隠すためにBase64を使うべきですか？

決して使うべきではありません。Base64は鍵なしで完全に元に戻せるため、難読化として扱うのはよくある誤りで、実際にパスワードやトークンが漏洩した事例が多数あります。機密性が必要な場合は、適切な暗号化やシークレット管理サービスを使用してください。