ファイルを渡す
.txtまたは.b64 ファイルを選ぶか、ここにドロップします。内容を貼り付けても構いません。
Base64 エンコーダー・デコーダー
Base64 文字列を貼り付けると、同じタブ内に結果が表示されます。バイト列が正しい UTF-8 ならテキストとして、そうでなければ判別できたコンテナ名とダウンロードとして提示します。貼り付ける代わりに、文字列を収めた .txt や .b64 ファイルを開くこともできます。標準アルファベット（+ と /）と URL-safe アルファベット（- と _）の両方を受け付け、どちらだったかを表示します。空白、タブ、改行、ノーブレークスペース、紛れ込んだバイト順マークは数えたうえで読み飛ばし、データとして復号しません。data: URL の接頭辞は取り除き、宣言されているメディアタイプとともに別枠で報告します。拒否されたときは必ず安定したコードが返り、原因の文字を指し示せる検証エラー（どちらのアルファベットにも無い文字、アルファベットの混在、位置や個数の誤ったパディング、成立しない長さ、base64 の印が無い data: URL）では、貼り付けた文字列そのものの中での位置（インデックス・行・列）も併せて示されます。容量超過や空入力の拒否には指し示すべき文字が存在しないため、位置ではなく文字数・バイト数と上限が示されます。エンコード側は逆向きで、テキストやバイト列を標準または URL-safe の Base64 に変換し、パディングの有無も選べ、文字数ではなくバイト長を表示します。
対応形式: .txt, .b64処理場所: このブラウザ
またはファイルをここにドロップ
✓ この端末内で処理します上限：1.9 MB
Base64 エンコーダー・デコーダーの使い方
処理を待つ
ファイルはこのブラウザ内で読み込んで解析します。サーバーには送りません。
結果を確かめて使う
出てきた内容を確かめてから、コピーやダウンロードに進みます。
ファイルがどう扱われるか気になりますか？ プライバシーについて読む →
よくある質問
ブラウザで Base64 文字列をデコードするにはどうすればいいですか？
入力欄に Base64 文字列を貼り付けるだけで、同じタブに結果がすぐ表示されます。ボタンも登録も不要です。文字列がファイルにある場合は、貼り付けの代わりに .txt や .b64 ファイルを開いても構いません。標準（+ /）と URL-safe（- _）のどちらのアルファベットも読み取り、コピー時に紛れ込んだ改行や空白は無視し、結果の横に復号後のバイト長を表示します。
自分のテキストを Base64 にエンコードして結果を持ち出すには？
エンコード側に切り替えてテキストを貼り付ければ、既定で正規のパディング付き Base64 が生成されます。テキストは先に UTF-8 バイト列へ変換されるため、日本語や絵文字も往復して元のまま戻ります。URL やファイル名の中に入れる場合は URL-safe アルファベットを選び、受け取り側が等号を嫌う場合はパディングを外せます。コピーとダウンロードは画面プレビューではなく出力全体を扱います。
貼り付けた Base64 文字列はサーバーにアップロードされますか？
いいえ。貼り付けた文字列はタブの外に出ません。復号は読み込み済みのページ内だけで動き、処理中にネットワーク通信は一切発生しません。実際に復号される中身はセッショントークン、ログの断片、設定ファイルの秘密情報などが多く、外部サービスに貼り付けること自体が禁じられている場面も珍しくないため、この点は実務上重要です。
Base64 デコーダーはオフラインでも会員登録なしで使えますか？
はい。ページを読み込んだあとは通信を切ってもデコードとエンコードを続けられ、登録もメールアドレスも求められません。復号中に何かを取得することがないため、閉域のパソコンでも接続時とまったく同じ挙動になります。通信が要るのは最初のページ読み込みだけなので、回線が切れると分かっているときはタブを開いたままにしてください。
スマートフォンで .b64 ファイルを開くにはどうすればいいですか？
スマートフォンの Chrome や Safari でこのページを開き、ファイル選択から .b64 を選べばその場で復号できます。アプリの追加は不要です。iOS も Android も .b64 という拡張子を単独では開けず、テキストエディタで開いても意味のない文字列が並ぶだけなので、外出先ではこの方法が現実的です。テキストならその場でコピーでき、バイナリならダウンロードとして保存されます。
Base64 のデコードで「不正な文字」と表示されるのはなぜですか？
どちらの Base64 アルファベットにも含まれない文字が混ざっているためで、その文字と、貼り付けた文字列内のインデックス・行・列がそのまま示されます。原因の多くは JSON からコピーした引用符、途中で切れたログ行の三点リーダー、XML の山かっこの混入です。該当文字を黙って取り除かないのは、元データが壊れている事実を隠さないためです。
Base64 の入力が大きすぎるというエラーが出るのはなぜですか？
入力が 2,000,000 文字、または復号結果が 2,000,000 バイトの上限を超えているためで、判定はメモリを確保する前に行われます。この場合は原因の文字が無いので、位置ではなく実際の文字数やバイト数と上限が示されます。上限に近いときはファイルを分割するか、元のファイルを Base64 化せずそのまま扱ってください。上限をページ側から引き上げることはできません。
ここで扱える Base64 文字列の最大サイズはどれくらいですか？
入力は 2,000,000 文字まで、復号後のデータは 2,000,000 バイトまでで、この二つが唯一の容量制限です。画面には長いテキストのうち先頭 200,000 文字がプレビューとして表示されますが、これは表示上の区切りにすぎず、コピーとダウンロードは常に全体を出力します。復号結果は文字数ではなくバイト長で示されるため、実際のファイルサイズがそのまま分かります。
末尾の等号がない Base64 でもデコードできますか？
できます。文字数を 4 で割った余りが 2 か 3 の文字列は通常どおり復号され、パディングが無かったという注記が付くだけです。JWT や URL パラメータでは等号なしの Base64 が普通だからです。拒否されるのは誤ったパディングのほうで、等号が多すぎる、半端に付いている、等号の後ろにデータが続く、余りが 1 になる、といった場合です。
メールで届いた Base64 の添付をデコードしても安全ですか？
この場でのデコード自体は安全です。中身は常に不活性なバイト列として扱われ、実行もされず、復号された HTML も描画されず、含まれる URL が取得されることもありません。危険は次の段階に移ります。復号された実行ファイルやマクロ入り文書は、保存して開けばメールの中にあったときと同じだけ危険です。このツールはバイト列が何かを示すだけで、悪意の有無は判定しません。
標準の Base64 と URL-safe Base64 の違いは何ですか？
値 62 と 63 に、標準は + と / を使い、URL-safe は - と _ を使う点だけが違い、復号後のバイト列は同一です。このツールは両方を受け付け、どちらが使われていたかを表示します。ただし一つの文字列に両方が混在する場合は拒否します。それは正当な符号化ではなく、異なる二つのコピーが継ぎ合わされた印だからです。
Base64 が正常にデコードできれば内容は信頼できると言えますか？
言えません。Base64 がきれいに復号できたという事実は、文字列が符号として整っていたことを示すだけで、データが本物であることも改ざんされていないことも意味しません。Base64 は符号化であって暗号でも署名でもないため、誰でも中身を書き換えて再符号化でき、それも同じように復号できます。信頼できるかどうかは出所で判断してください。