MT
My Toolbox

Base64エンコーダー＆デコーダー — テキストとデータをオンライン変換

テキストをBase64にエンコード、またはBase64を読めるテキストにデコード。UTF-8対応、オフライン動作、データは一切送信されません。JWTトークン、Data URI、API認証ヘッダー、メールエンコーディングに便利。

入力テキスト
Base64出力

Base64が実際にやっていること

Base64はバイナリデータを64個の「安全な」ASCII文字（A-Z、a-z、0-9、+、/）とパディング用の=で表現します。RFC 4648で定義され、1990年代初頭のMIMEメール標準から使われています。

なぜ存在するのか？多くのシステム（メール、JSON、URL、XML）はテキストしか扱えないからです。PNG画像をJSONレスポンスやメール本文に入れたい場合、生のバイトをそのまま入れることはできない——まずテキストにエンコードする必要があります。Base64はそのための標準的な方法です。

トレードオフ：Base64はデータサイズを正確に33%増加させます（パディング含む）。入力3バイトが出力4文字になる。1MBの画像はBase64で約1.33MBに。だから大きなファイルをWeb配信でBase64エンコードすべきではない——通常のファイルアップロードやCDN URLを使う。しかし小さなアセット（5KB以下のアイコン、フォントサブセット）やテキスト専用チャネルを通す必要があるデータには、33%のオーバーヘッドは価値がある。

使い方

  1. 上部でエンコードまたはデコードモードを選択。
  2. テキスト（エンコード用）またはBase64文字列（デコード用）を入力に貼り付け。
  3. ボタンを押す——結果は即座に表示。
  4. 出力をコピー。Data URIの場合は自分で先頭に "data:image/png;base64," を追加。

実際に必要になる場面

JWTトークンのペイロード確認

JWTはドットで区切られた3つのBase64urlエンコード部分を持つ。中間部分（ペイロード）をここに貼り付けてデコードすれば、ユーザーID、有効期限、ロールなどのクレームが見える——JWTライブラリをインストールせずに。

インライン画像のData URI作成

CSSやHTMLに小さなアイコンを直接埋め込んで余分なHTTPリクエストを省きたい？画像ファイルをBase64にエンコードして、background-image: url(data:image/png;base64,文字列) として使う。5KB以下に抑えないとパフォーマンスに悪影響。

HTTP Basic認証ヘッダー

Basic Authは "ユーザー名:パスワード" をBase64エンコードしてAuthorizationヘッダーに入れる必要がある。"admin:secretpass" をここに貼り付けてエンコードし、APIテストツールやcurlコマンドで使う。

エンコードされたAPIペイロードのデバッグ

一部のAPIはBase64エンコードされたフィールドを返す（AWS Lambdaレスポンス、Kubernetes secrets、SAMLアサーション）。エンコード文字列をここに貼り付けて中身を確認——デコードスクリプトを書く必要なし。

知っておくべきこと

1.

Base64は暗号化ではない

これが最大の誤解。Base64は誰でも簡単に元に戻せる——セキュリティはゼロ。パスワード、APIキー、機密データを「隠す」ために使わないこと。設定ファイルでパスワードがBase64で保存されていたら、それはセキュリティバグであってセキュリティ対策ではない。

2.

URL-safeと標準Base64の違いに注意

標準Base64は+と/を使うがURLでは壊れる。URL-safe Base64（RFC 4648 §5）は-と_に置き換える。JWTはURL-safeを使用。ほとんどのAPIは標準を使用。デコード結果が文字化けなら、間違ったバリアントを使っている可能性。

3.

大きなファイルをWeb用にBase64エンコードしない

100KBの画像をBase64でCSSに入れる = 133KBのテキストで、個別にキャッシュできず、遅延読み込みできず、スタイルシートを膨らませる。Base64は小さなアセットのみ（< 5KB）。それ以外はCDNから配信する通常のファイルにすべき。

4.

UTF-8エンコーディングが重要

Base64はバイトをエンコードする、文字ではない。"Hello"はASCIIで5バイト。"こんにちは"はUTF-8で15バイト。テキストをエンコードする場合、両端で文字エンコーディングを合わせる（UTF-8が安全なデフォルト）。エンコーディング不一致 = 文字化け出力。

実例

JWTペイロードのデコード

JWTトークンの中間セクション——デコードしてユーザークレームを確認。

Input

eyJ1c2VySWQiOjQyLCJyb2xlIjoiYWRtaW4iLCJleHAiOjE3MTY5OTIwMDB9

Output

{"userId":42,"role":"admin","exp":1716992000}

Basic Auth用の認証情報エンコード

HTTP Basic認証はbase64("ユーザー名:パスワード")が必要。

Input

admin:my-secret-password

Output

YWRtaW46bXktc2VjcmV0LXBhc3N3b3Jk

機能

  • エンコードとデコードを1つのツールで——モード切り替えのみ
  • 完全なUTF-8サポート（日本語、中国語、絵文字——すべて動作）
  • 複数行入力も問題なし
  • 完全にブラウザ内で動作——サーバーへの往復なし
  • ブラウザのメモリ以外にサイズ制限なし
  • 無料、登録不要、トラッキングなし

よくある質問

なぜBase64はファイルを33%大きくする？

Base64は入力3バイトを4つのASCII文字にマッピングする。4/3 = 33.3%増加。入力長が3で割り切れない場合、末尾に1-2個のパディング文字（=）が追加される。これはエンコーディング固有のもので回避方法はない。

このツールでJWTトークンをデコードできる？

部分的に可能。JWTはBase64urlエンコーディング（+と/の代わりに-と_）を使用。ペイロード（中間部分）は読めるJSONにデコードされる。署名（最後の部分）はバイナリの文字化けにデコードされる（暗号ハッシュだから）。このツールは標準とURL-safe両方のBase64を処理可能。

Base64は暗号化と同じ？

いいえ。絶対に違う。Base64はエンコーディング——誰でもゼロの労力で元に戻せる。セキュリティはゼロ。APIが「Base64でデータを暗号化している」と言われたら、逃げること。本当の暗号化にはAES-256などを使う。

Kubernetes secretsがBase64を使うのはなぜ？

KubernetesはYAML/JSONマニフェストでsecretをBase64で保存する。バイナリデータをYAMLに直接入れられないから。しかしこれはセキュリティではない——kubectlアクセスがある人なら誰でも即座にデコードできる。本当の保護にはsealed-secretsや外部シークレットマネージャー（Vault、AWS Secrets Manager）を使う。

Base64とURLエンコーディングの違いは？

異なる問題、異なる解決策。URLエンコーディング（パーセントエンコーディング）は個々の特殊文字を%XXに置き換えてURL安全にする。Base64は任意のバイナリデータをテキスト文字列に変換する。特殊文字を含むクエリパラメータにはURLエンコーディング。テキスト形式にバイナリデータを埋め込むにはBase64。

ヒントと関連ワークフロー