Base64 エンコーダー・デコーダー
テキストやファイルを Base64 に、またはその逆に。
- すべて無料登録なし、回数制限なし、有料プランなし。
- アップロードなしファイルは自分の端末で処理され、サーバーには届きません。
- 結果に条件なし透かしなし、勝手な縮小なし、サイズ上限なし。
- 変更はすべて公開修正も新しい工具も、すべて更新履歴ページに書いています。
Base64 とは何か、いつ使うのか
Base64 は、任意のバイナリデータを 64 種類の印字可能な ASCII 文字（A–Z、a–z、0–9、+ と /、パディングとして =）で表現する方式です。入力 3 バイトが出力 4 文字になるため、エンコード後のデータは元より約 33% 大きくなります。この方式が存在するのは、多くの通信経路がテキスト専用に設計されていたからです。メールの添付ファイル（MIME）、JSON や XML のペイロード、HTTP Basic 認証ヘッダー、JWT トークン、そして画像を HTML や CSS に直接埋め込む data URL などがその例です。Base64 はエンコードであって暗号化ではありません。誰でもデコードできるので、秘密情報を隠す目的には決して使わないでください。
URL-safe 版（RFC 4648 §5）は + を -、/ を _ に置き換え、通常は = のパディングも省略します。これにより、エスケープなしで URL、ファイル名、Cookie に入れられます。JWT はこの形式を使っています。このページのデコーダーは両方の形式を受け付け、パディングの欠落も許容するため、JWT のセグメントをそのまま貼り付けられます。
使い方
テキストを入力または貼り付けると、入力と同時にエンコードされます。テキストは UTF-8 として扱われるため、日本語、絵文字、その他あらゆる Unicode 文字が正しく往復します。btoa() を直接使う素朴な実装でよく起きるバグはここでは発生しません。URL-safe にチェックを入れると、パディングなしの -/_ アルファベットになります。「ファイル…」をクリックして任意のファイルを選択できます。画像、PDF、フォント、アーカイブはローカルで読み込まれてエンコードされ、画像の場合は <img src> や CSS の背景にそのまま貼り付けられる完全な data URL が出力されます。
デコードするには「デコード」に切り替えて Base64 を貼り付けます（完全な data URL でも構いません）。結果が有効な UTF-8 テキストであれば出力欄に表示されます。バイナリの場合は一般的な形式（PNG、JPEG、GIF、WebP、PDF、ZIP）を検出し、画像はインラインでプレビュー表示され、デコードしたファイルをダウンロードできます。「入れ替え」は出力を入力に戻すので、ワンクリックで往復変換を確認できます。
プライバシーと制限
ファイルがお使いのパソコンの外に出ることはありません。ブラウザの File API で読み込み、メモリ上でエンコードして表示するだけで、何もアップロードされません。すべてクライアント側で動作するため、実質的な上限はデバイスのメモリです。数十 MB のファイルでも問題なく動作しますが、出力欄のスクロールは重くなります。非常に大きなファイルの場合は、コピーではなく結果をダウンロードしてください。
背景：テキストだけの世界
Base64 は初期の電子メールの制約から生まれました。SMTP は 7 ビット ASCII テキスト向けに設計されていたため、バイナリファイルを添付するにはまず印字可能な文字に変換する必要がありました。1980 年代には uuencode がその役割を担い、MIME 標準（RFC 2045、1996 年）が今日も使われている Base64 のアルファベットを定義しました。その後 RFC 4648（2006 年）が各バリエーション、すなわち標準 Base64、URL とファイル名に安全な形式、Base32/Base16 をまとめました。3 バイトが 4 文字になる比率のため、エンコード後のデータは元のサイズのちょうど 4/3 にパディングを加えた大きさになります。このコストはダイヤルアップ時代に重要でしたし、CSS に画像をインライン化する際には今でも重要です。
利用される場面
メールの添付ファイルは今でも内部的に Base64 です。data URL は小さな画像やフォントを HTML や CSS に直接埋め込んでリクエストを 1 回節約します。Base64 は元のサイズに 33% 上乗せするため、先に画像を圧縮しておきましょう。HTTP Basic 認証は username:password を Base64 で送信します（暗号化ではないので、必ず HTTPS を使ってください）。JWT トークンはドットで連結された 3 つの URL-safe Base64 セグメントで、ヘッダーとペイロードをデコードすると JSON になります。Kubernetes の Secret、クラウドの IAM ポリシー、Base64 値を含むパーセントエンコードされた URL、Subresource Integrity 属性の SHA-256 ダイジェスト、SAML アサーション、PEM 証明書（BEGIN 行と END 行の間のブロック）、JSON API 内のバイナリフィールドなど、テキストしか扱えないシステムはすべてこれを使っています。= で終わる、あるいは英数字と + と / だけからなる長い文字列に出会ったら、それはほぼ確実に Base64 です。ここに貼り付けるのが中身を知る最速の方法です。
よくある質問
Base64 は安全ですか？
いいえ。可逆なエンコードであり、暗号化ではありません。誰でも即座にデコードできます。転送や埋め込みには使えますが、データを隠す目的には決して使わないでください。
デコードしたテキストが文字化けするのはなぜですか？
元のデータが UTF-8 テキストではなかったか、バイナリだった可能性が高いです。このツールは UTF-8 としてデコードし、バイト列が有効なテキストでない場合はファイルのダウンロードに切り替えます。
data URL とは何ですか？
data:image/png;base64,... という形式の URL で、ファイルの内容をインラインで埋め込みます。ブラウザが直接表示できるため、HTML/CSS 内の小さなアイコンやメールで役立ちます。
エンコード結果の末尾に = が付くのはなぜですか？
パディングによって長さを 4 の倍数にしています。標準 Base64 では必須ですが、URL-safe 版では省略可能です。このページのデコーダーはパディングの有無にかかわらず受け付けます。
JWT をデコードできますか？
ヘッダーとペイロードは可能です。ドットの間のセグメントを貼り付けてください。署名セグメントはバイナリのため、テキストとして読むことはできません。