Base64 デコーダー
任意の Base64 文字列を読みやすいテキストに復元します。改行・不足している = パディング・URL セーフ形式もそのまま認識する寛容なデコーダーです。
0 文字 · 0 バイト · 0 行
結果
0 文字 · 0 バイト · 0 行
Base64 デコードについて
デコードは 4 文字の Base64 の各グループを元の 3 バイトに戻します。このデコーダーは意図的に寛容で、改行・余分な空白・不足した = パディング・URL セーフ形式（- と _）を前処理なしでそのまま受け付けます。
よくある用途は、JWT ペイロードの確認、API トークンの検査、Data URL やメール添付の中身の確認です。デコード結果は UTF-8 テキストとして表示されるため、画像などのバイナリをデコードすると文字化けして見えますが、これは正常です。すべてローカルで処理されるので、トークンを貼り付けても安全です。
このツールで対応できること
Unicode を正しく処理
エンコード前にテキストを UTF-8 バイト列へ変換するため、日本語・café・🔒 もエラーにならず正しく往復します。
寛容なデコーダー
改行、余分な空白、欠けた = パディング、URL セーフな文字セットもそのまま受け付けます。事前の整形は不要です。
データはタブの外に出ない
エンコードは端末上の JavaScript で実行されます。トークンや認証情報、ペイロードがどこかへ送信されることはありません。
よくある質問
文字列が Base64 かどうか見分けるには？
A–Z a–z 0–9 + /（URL セーフ版では - と _）のみで構成され、長さが 4 の倍数で、末尾に 1〜2 個の = パディングが付くことがあります。
デコード結果が文字化けするのはなぜ？
主な原因は 2 つ。元のデータがテキストではなくバイナリ（画像やアーカイブ）だったか、テキストが UTF-8 以外のレガシーエンコーディングだったかです。デコード自体は正しく行われています。
= パディングがなくてもデコードできますか？
はい。パディング不足、埋め込まれた改行、URL セーフ形式はすべて自動的に処理されます。
他のツールで失敗する JWT セグメントがここでは成功するのはなぜ？
JWT はパディングなしの URL セーフ形式を使います。多くのデコーダーはこれを拒否しますが、このツールはネイティブに受け付けます。