Base64 エンコード・デコード
テキストのBase64変換をブラウザ上で即座に実行。サイズ増加率の自動計算付き。データURIやAPI連携の確認に。
他のオンラインツール
📖 つまずきやすいポイント
テキストやファイルを Base64 に変換し、逆変換もします。URL-safe 形式と、旧 MIME 形式の 76 文字ごとの改行にも対応しています。処理はブラウザ内で完結します。Base64 は「バイト列を ASCII の 64 文字だけで表す」ための符号化であって、暗号でも圧縮でもありません — 誰でも 1 秒で元に戻せますし、データ量は必ず約 33% 増えます。この 2 点を取り違えたところから、実務の事故はほぼすべて始まります。
| ケース | 何が起きるか | どうする |
|---|---|---|
| 日本語を通すと化ける・例外が出る | Base64 が扱うのはバイト列であって、文字ではありません。文字をバイトに直す段階 — つまり文字コードの決定 — は Base64 の外側で行われ、ここが送り手と受け手でずれると化けます。ブラウザの btoa() は Latin-1 の範囲しか受け付けないので、日本語を渡すと InvalidCharacterError で例外になります。一方 PHP の base64_encode() は渡されたバイト列をそのまま符号化するため、元が Shift-JIS ならその Shift-JIS が入ります — エラーにならない分、こちらのほうが厄介です。 |
Base64 にする前に UTF-8 のバイト列へ変換してください。JavaScript なら new TextEncoder().encode(str) で Uint8Array にしてから符号化し、復号側は new TextDecoder().decode(bytes) で戻します。この往復が対称になっていれば、どの言語間でも文字化けしません。データを外部とやり取りする場合は、「Base64 の中身は UTF-8 である」ことを API ドキュメントに明記してください — Base64 文字列そのものからは文字コードを判別できないので、受け側は書かれていなければ推測するしかありません。 |
| URL やクエリに入れると壊れる | 標準の Base64 が使う + / = は、いずれも URL の中で別の意味を持ちます。とくに危険なのが + で、クエリ文字列では空白として解釈されるため、復号すると値が壊れます。厄介なのは症状が確率的に見えること — 符号化結果に + が含まれるかどうかは入力次第なので、テストでは通っていたのに本番の特定のデータだけ失敗するという形で出ます。/ はパスの区切りと衝突し、= はパラメータの代入と衝突します。 |
URL に載せるなら URL-safe 形式を使ってください — + を - に、/ を _ に置き換え、末尾の = を省いたものです (RFC 4648 の base64url)。JWT はこの形式で規格化されているので、JWT を自前で組み立てるときは選択の余地がありません。迷ったら、Base64 にしたものをさらに URL エンコードするのではなく、最初から URL-safe を選んでください — 二重にエンコードすると、どちらか片方だけ復号して「なぜか %2B が残っている」という状態になりがちです。パディングの = は省いても復号できます (長さから復元できるため)。 |
| data URI で埋め込んだら逆に遅くなった | リクエストが減るのは事実ですが、データは 33% 増え、しかもブラウザのキャッシュが効きません。画像を CSS の中に埋め込むと、その CSS 自体が肥大し、CSS は描画をブロックするので初回表示が遅くなります。10KB の画像を 20 個埋め込めば、本来 20 個の並列リクエストで済んだものが、266KB の巨大な描画ブロック資源に化けます。さらに、画像を 1 つ差し替えるだけで CSS 全体のキャッシュが無効になります。HTTP/2 以降はリクエスト数のコストが大きく下がったので、「リクエストを減らす」という前提自体が古くなっています。 | data URI は数 KB までの小さなアイコンに限ってください。それ以上は普通に <img> で読み込み、キャッシュとレスポンシブ画像 (srcset) の恩恵を受けたほうが速いです。SVG を埋め込むなら Base64 にしないでください — SVG はテキストなので、encodeURIComponent で URL エンコードするほうがBase64 より小さく、gzip も効きます。判断の基準は単純で、「その画像を差し替える頻度」と「その CSS を配る回数」を比べることです — ロゴのように滅多に変わらず全ページで使うものだけが埋め込みに向きます。 |
Base64 は難読化ですらありません。設定ファイルに password: cGFzc3dvcmQ= と書いても、それは「一目では読めない」だけで、秘密にはなっていません。Kubernetes の Secret がまさにこの形式で、あれは暗号化ではなく符号化です — kubectl get secret -o yaml の出力を見た人は誰でも復号できます (だから外部のシークレット管理や暗号化を別途組み合わせます)。GitHub の秘密スキャンや各種の漏洩検知は Base64 を展開して中身を見ますので、リポジトリに入れれば普通に検出されます。逆に言えば、「Base64 にしてあるから大丈夫」と判断した箇所は、ほぼ確実に脆弱性です。もう 1 点、行の折り返しの扱いに注意してください — 電子メールや PEM 形式では 64〜76 文字ごとに改行が入り、この改行を除かずに復号するとエラーになる実装があります。逆に、改行を入れるべき場面で 1 行にすると受け付けない古いシステムもあります。
📖 使い方
-
1
入力を貼り付けエンコードなら元の文字列、デコードなら Base64 文字列を入力欄にペーストします。
-
2
エンコード方向を切替「エンコード ⇄ デコード」ボタンで切り替えます。結果は即座に表示され、サイズ増加率も計算されます。
-
3
URL-safe 形式を選択URL や JWT で使う場合は URL-safe (= を省略して +/ を -_ に置換) を選択してください。
❓ よくある質問
なぜ Base64 はサイズが 33% 増えるのですか?
バイナリファイルも扱えますか?
入力データはサーバーに送信されますか?
改行コードの扱いは?
🐛 このツールで問題が発生しましたか？
完全無料・登録不要。再現手順だけでも結構です。届いたご報告は運営者に直接届き、修正の参考にします。
ご報告ありがとうございます！
運営者に届きました。改善の参考にさせていただきます。