無料Base64エンコーダー＆デコーダーオンライン

Base64とは？

Base64はバイナリからテキストへのエンコーディング方式で、任意のバイトシーケンス(バイナリデータ)を、テキスト専用のチャネルを通じて破損なく送信できる単純なASCII文字のシーケンスとして表現する方法です。名前はアルファベットサイズを反映しています: 64文字は、7ビットクリーンな送信を変更なしで生き残るために特別に選ばれています。標準のアルファベットは A-Z (位置 0-25)、a-z (26-51)、0-9 (52-61)、そして + (62) と / (63) です。= 文字は、入力長が3の正確な倍数でない場合のパディングとして予約されています。3つの入力バイト (24ビット) ごとに4つの出力文字 (それぞれ6ビットを運ぶ) になります。そのため、Base64エンコードされたデータは元のものよりおおよそ33%大きくなります。

メカニズム: 3バイト (24ビット) を取り、4つの6ビットチャンクとして再グループ化し、各チャンクを64文字のアルファベットで調べます。古典的な働く例: 3つのASCIIバイト M a n (0x4D 0x61 0x6E) は24ビットパターン 01001101 01100001 01101110 を形成します; 6ビットチャンクに再グループ化されます: 010011 010110 000101 101110 = 10進数 19、22、5、46 = 文字 T W F u。したがって、"Man" はBase64で "TWFu" にエンコードされます。入力長が3で割り切れない場合、エンコーダーは1つまたは2つの = 文字でパディングします: 1バイトの入力は2文字 + == を生成し、2バイトの入力は3文字 + = を生成します。

Base64の簡単な歴史

Base64はIETFのPrivacy Enhanced Mail (PEM) の取り組みから始まりました。1987年2月のRFC 989が最初の正式な定義でした; 1989年8月のRFC 1113がそれを改訂しました; 1993年2月のRFC 1421がBase64エンコーディングを含むPEM仕様を最終確定しました。Base64は、MIME (Multipurpose Internet Mail Extensions) 仕様がそれを採用したときにメールの主流に入りました: 1996年11月のRFC 2045がBase64をバイナリメール添付ファイルの標準エンコーディングとして定義しました。これが、メールに添付したすべてのPDFや画像がBase64として線を通って移動した理由です。現在の標準仕様は2006年10月にSimon Josefssonによって発行されたRFC 4648 ("The Base16, Base32, and Base64 Data Encodings")で、これはRFC 3548 (2003年7月) を置き換え、さまざまなBase16 / Base32 / Base64ファミリーエンコーディングを単一のドキュメントに統合しました。RFC 4648はすべての現代のBase64実装がターゲットとする仕様です。

URL-safe Base64、なぜ2つの文字が交換されるのか

標準のBase64アルファベットは + と / を使用しますが、これらはどちらもURLで予約されている文字です。URLクエリ文字列の + は通常「スペース」を意味します (フォームエンコード規則); / はパス区切り文字です。標準Base64をURLに入れることは両方をパーセントエンコードすることを意味し、文字列をさらに膨張させ、見栄えが悪くなります。RFC 4648 §5 はURL-safeバリアントを定義しています: + を - (ハイフンマイナス) に、/ を _ (アンダースコア) に置き換えます。Base64URL または base64url と呼ばれることもあります。結果は、さらなるエスケープなしで直接URLに落とせる文字列で、これはまさにJWT (JSON Web Tokens)、OAuthステートパラメータ、WebAuthn認証情報ID、およびほとんどの現代のWeb APIが使用するものです。一部の実装では、長さが次のフィールドから暗黙的であるため、末尾の = パディングも削除します。JWTの3部分ドット区切り構造 (header.payload.signature) は3つのBase64URLエンコードされたセグメントです; JWTを手動でデコードしたことがあれば、標準のBase64ではなくBase64URLとしてマークする - と _ 文字を見たことがあるでしょう。

Base-Nファミリー、Base16、Base32、Base58、Base85

Base64はバイナリからテキストへの唯一のエンコーディングではありません。Base16 (hex) は16文字 (0-9 と A-F) を使用し、100%のサイズ拡張 (各バイトが2つの16進文字になる) ですが、簡単に読み取り可能で、ハッシュ出力、ファイルチェックサム、マシン識別子のためのユニバーサルデフォルトです。Base32 (RFC 4648、またCrockfordのバリアント) は 0/O や 1/I/L のような視覚的に曖昧なペアを除外するように注意を払って32文字を使用します; 60%のサイズ拡張; TOTP秘密キー、ULID、Tor onionアドレスで使用されます。Base58 はBitcoin標準です: 紛らわしい 0/O/I/l と標準Base64の特殊文字 +/= を除外した58文字です。Bitcoinアドレス、Solanaアドレス、および多くの暗号ウォレット識別子はBase58Check (Base58 + 4バイトチェックサム) を使用します。Base85 / Ascii85 はより多くの密度をパックします (4バイトを5文字としてエンコード、わずか25%の拡張) が、URL-unsafeな句読点を含むアルファベットを使用します; AdobeのPostScriptとPDF形式は埋め込みバイナリデータに内部的にBase85を使用します。一般的なトレードオフ: アルファベットの文字数が多いほど拡張が少なくなりますが、文字セットがより制約されます; 文字が少ないほど、より大きな出力を犠牲にしてより安全な転送が可能になります。

Base64の一般的な用途

• メール添付ファイル (MIME)。 1996年以来のRFC 2045。メールに添付したすべてのPDF、画像、ドキュメントは、SMTPがもともと生のバイナリを処理できない7ビットクリーンなテキストプロトコルであったため、Base64としてネットワークを移動しました。
• HTML/CSSのdata: URI。 data:image/png;base64,iVBORw0KGgo... は、HTTP要求を排除して、HTMLまたはCSSスタイルシートに小さな画像を直接埋め込みます。約10 KB未満のアイコンに役立ちます; Base64の33%拡張が節約されたHTTP要求オーバーヘッドを超えるため、大きな画像には逆効果です。
• JSONペイロードのバイナリ。 JSONは仕様によりテキスト専用で、JSON値に生のバイトを入れる方法はありません。画像、PDF、または他のバイナリを送信する必要があるAPIは、それらをJSONフィールドのBase64文字列として埋め込みます。Stripeのwebhookペイロード、TwilioのMMS API、および多くのAI vision エンドポイントはこのパターンを使用します。
• JWT (JSON Web Tokens)。 JWTの3つのドット区切りパート (header.payload.signature) はすべてBase64URLエンコードされています。JWT仕様 (RFC 7519、2015年5月) はJOSE (RFC 7515-7518、これも2015年5月) に基づいており、これらすべてがBase64URLを全体にわたって義務付けています。
• OAuthとOpenID Connect。 state パラメータ、PKCE コードベリファイア、IDトークン、および多くの実装のアクセストークンはBase64URLを使用します。
• HTTP Basic Authentication。 Authorization: Basic dXNlcjpwYXNz ヘッダーは Base64(username:password) を運びます。注意: これは転送のためのエンコーディングであり、暗号化ではありません。プレーンHTTP経由のBasic Authは、ネットワークを見ている人に資格情報を平文で公開します。常にHTTPSとペアにしてください。
• Subresource Integrity (SRI)。 <script> と <link> タグの integrity="sha384-..." 属性は、期待されるファイル内容のBase64エンコードハッシュを運びます; ブラウザは実行前にダウンロードされたファイルが一致することを確認します。
• CSS内のSVG背景。 background-image: url("data:image/svg+xml;base64,...") はスタイルシートに直接SVGを埋め込みます。Base64形式は、URL-encoded形式 (SVGを読みやすくしますが、異なるエスケープルールを使用します) よりも好まれることがあります。

エンコーディングは暗号化ではない、一般的なセキュリティの間違い

Base64はセキュリティをまったく提供しません。エンコーディングは誰でもミリ秒で完全に逆転可能で、アルファベットは公開されており、アルゴリズムは些細で、任意のブラウザまたは1行のCLIコマンドでデコードできます。それにもかかわらず、「Base64エンコードされた機密データ」はMITRE CWE-261 (Weak Encoding for Password) で最も引用される例の1つで、セキュリティ監査に常に表示されます: クライアントコードでBase64によって「難読化」されたAPIキー; データベースバックアップファイルでBase64で「エンコード」されたパスワード; 公開Gitリポジトリにコミットする前にBase64で「暗号化」された秘密。これらのいずれも保護されていません。実際の機密性が必要な場合は、本物の暗号化を使用してください: 対称にはAES-256-GCM、非対称にはRSA-OAEPまたはECDH+ChaCha20-Poly1305。Base64は転送 (バイナリをテキストに適した形式に変換する) には適していますが、保護には決して適していません。

ブラウザ実装: btoa / atob とUnicodeの落とし穴

JavaScriptはBase64用に2つの組み込みグローバル関数を公開しています: btoa() (binary-to-ASCII、エンコード) と atob() (ASCII-to-binary、デコード)。両方とも初期のNetscape時代からのレガシーAPIで、有名な制限があります: Latin-1バイト文字列でのみ機能します。btoa('é') を呼び出すと、JavaScript文字列 'é' に単一バイトに収まらないU+00FFを超えるコードポイントが含まれているため、InvalidCharacterError がスローされます。現代の修正は、最初に TextEncoder を介してUTF-8バイトにエンコードし、結果の Uint8Array を btoa() の消費のためにLatin-1文字列に変換することです。パターン: btoa(String.fromCharCode(...new TextEncoder().encode(str)))。逆をデコードする: new TextDecoder().decode(Uint8Array.from(atob(str), c => c.charCodeAt(0)))。新しいブラウザは組み込みメソッドとして Uint8Array.toBase64() と Uint8Array.fromBase64() を公開していますが、2026年時点で採用はまだ展開中で、btoa/atob 経由のポリフィルがクロスブラウザのデフォルトのままです。具体的にはファイルの場合、FileReader.readAsDataURL() が最も簡単な経路です: ファイルを入力にドロップすると、リーダーはすべてが正しくエンコードされた data:mime/type;base64,... 文字列を返します; Base64部分だけを取得するには data: プレフィックスを削除します。

正直なスコープ: このツールができることとできないこと

このツールはテキストまたはファイル (最大5 MB) をBase64にエンコードし、Base64文字列をテキストまたはダウンロード可能なファイルに戻してデコードします。デフォルトで標準の RFC 4648 アルファベット (+ と / を持つ) を使用します; URL-safe Base64URL (- と _ を持つ) は将来機能のトグルです。UTF-8テキストは TextEncoder 経由で正しく処理され、btoa-Latin-1の落とし穴は修正されています。5 MBファイルサイズ上限は、Base64がデータを33%拡張し、エンコードされた文字列がブラウザメモリに完全に存在するため存在します; 5 MBのバイナリファイルは元のバッファに加えて約6.7 MBのBase64テキストを生成し、これはすべての現代のデバイスで動作します。より大きなファイルには、標準的な代替手段はmacOS/Linuxのコマンドライン base64 (base64 -i input.bin -o output.txt)、Pythonの base64 モジュール、またはNode.jsの Buffer.from(data).toString('base64') です。このツールは以下を処理しません: ストリーミングBase64 (メモリより大きなファイル用のファイル単位チャンクエンコーディング); このバージョンのURL-safeバリアント (計画中); MIME quoted-printable エンコーディング (テキストメールコンテンツ用の異なるRFC 2045スキーム) も処理しません。

プライバシー: なぜブラウザのみが重要なのか

Base64は暗号化ではありませんが、エンコードされているデータはしばしば機密です: configファイルに埋め込んでいるAPIキー、転送用にエンコードしている証明書、ドキュメントにdata URIとして埋め込んでいる内部スクリーンショット、またはクライアント用にエンコードしているPDFレシート。サーバーサイドエンコーダーはあなたの入力を見ます。このツールはJavaScriptを介してブラウザで完全に実行されます。Encodeをクリックする間にDevToolsのネットワークタブで検証するか、ロード後にページをオフラインに(機内モードに)してもツールはまだ機能します。APIクレデンシャル、PIIスクリーンショット、内部ドキュメント、または見知らぬ人のハードドライブにコピーされたくないデータをエンコードするのに安全です。

よくある質問

Base64は安全ですか？

いいえ。Base64はエンコードであり、暗号化ではありません。誰でもBase64文字列をデコードできます。機密データを保護するためにBase64を使用しないでください, セキュリティには適切な暗号化（AES、RSA）を使用してください。

なぜBase64はファイルを大きくするのですか？

Base64エンコードはデータサイズを約33％増加させます。バイナリデータの3バイトが4つのBase64文字になります。このオーバーヘッドは、バイナリデータをテキストとして送信できることとのトレードオフです。

ファイルをエンコードできますか？

はい！エンコーダーに任意のファイルをドラッグ＆ドロップするか、クリックして参照します。ファイルはBase64データURIに変換され、HTML、CSS、またはJavaScriptに直接貼り付けることができます。

Base64とBase64URLの違いは何ですか?

2文字です。標準Base64 (RFC 4648 §4) は + と / をアルファベットの62番目と63番目の文字として使用します。URL-safe Base64URL (RFC 4648 §5) は代わりに - と _ を使用するため、エンコードされた文字列はパーセントエンコードなしで直接URLに落とすことができます。JWT、OAuth、WebAuthn、およびほとんどの現代のWeb APIはBase64URLを使用します。このツールは現在標準のBase64を出力します; URL-safeは将来機能リストにあります。標準からURL-safeに手動で変換するには: + を - に、/ を _ に置き換え、オプションで末尾の = パディングを削除します。

なぜ私のUnicodeテキストが一部のBase64ツールで失敗するのですか?

JavaScriptのレガシー btoa() 関数がLatin-1バイト文字列でのみ機能するためです。btoa('é') を呼び出すと InvalidCharacterError がスローされます。多くの古いブラウザベースのエンコーダーはUTF-8変換ステップなしで btoa を直接使用するため、非ASCII入力は破損します。現代のコード (およびこのツール) は最初に TextEncoder 経由で文字列をエンコードし、btoa が安全にエンコードできるUTF-8バイトシーケンスを生成します。新しい組み込みメソッド Uint8Array.toBase64() はUTF-8をネイティブで処理しますが、まだすべてのブラウザでベースラインではありません。

私のデータはアップロードされますか?

いいえ。エンコーディングとデコーディングはJavaScriptを介してブラウザ内で完全に実行されます。テキストとファイルはネットワークを越えることはありません。Encodeをクリックする間にDevToolsのネットワークタブで検証するか、ロード後にページをオフラインに(機内モードに)してもツールはまだ機能します。APIクレデンシャル、PIIを含むスクリーンショット、内部configファイル、または見知らぬ人のハードドライブにコピーされたくないデータに安全です。

関連ツール