Base64デコードとは?
Base64デコードはBase64エンコードの逆プロセスです:Base64でエンコードされたASCII文字列を元のバイナリデータやテキストに変換します。4つのBase64文字ごとに元のデータの3バイトにデコードされます。デコーダーはBase64アルファベットで各文字を検索し、元の6ビットグループを再構築して8ビットバイトに再組み立てします。
Base64でエンコードされたデータは、大文字・小文字のアルファベット、数字、そして+/(標準)または-_(URLセーフ)を使用しており、末尾に1つまたは2つのパディング文字=が付くことで識別できます。JWTトークン、メール添付ファイル、data URI、APIレスポンス、設定ファイルなど、バイナリまたは構造化データをテキストのみのコンテキストに埋め込む必要がある場所によく見られます。
このツールを使う理由
このデコーダーは標準とURL-safeのBase64を処理し、不足しているパディングを自動修正し、サーバーにデータを送信せずにブラウザ内で完全にデコードします。
⚡パディングの自動修正
多くのソースは末尾の=文字なしでBase64を生成します。このツールはデコード前に不足しているパディングを自動的に計算して追加し、InvalidCharacterError例外を防ぎます。
🛡️両方のバリアントをサポート
標準Base64(+/)とURL-safe Base64(-_)を自動的に検出して処理するので、手動変換なしにあらゆるソースからトークンを貼り付けることができます。
🔒完全クライアントサイド
デコードはネイティブのatob APIを使用してブラウザでローカルに行われます。シークレットや機密コンテンツを含む可能性があるデータがデバイスを離れることはありません。
🌐Unicode出力
マルチバイト文字、絵文字、CJKスクリプトを含む完全なUnicodeにUTF-8エンコードされたテキストを正しくデコードします。
このオンライン Base64 デコーダーの使い方
アカウント不要、アップロード不要、インストール不要。Base64 文字列を入力欄に貼り付けるだけで、デコード結果が即座に表示されます。すべてブラウザ内で動作し、データがデバイスの外に出ることはありません。
- 1
Base64 文字列を貼り付ける
JWT、APIレスポンス、メール添付ファイルのヘッダー、設定ファイルなど、任意の Base64 エンコード文字列をコピーして入力欄に貼り付けてください。標準形式と URL-safe 形式は自動的に検出されます。
- 2
自動検出と修復
デコーダーは入力が標準 Base64(+/)か URL-safe Base64(-_)かを識別し、不足している = パディングを自動的に補完します。デコード前に文字列を手動で正規化する必要はありません。
- 3
出力を確認する
デコードされたテキストが出力欄に表示されます。元のデータが UTF-8 テキストであれば読み取り可能な文字として表示されます。バイナリデータはそのまま表示されます。デコードできない不正な文字が含まれる場合はエラーメッセージが表示されます。
- 4
結果をコピーまたは使用する
「コピー」をクリックしてデコード結果を取得するか、ワークフロー内でそのまま利用してください。結果を再エンコードしたい場合は、ワンクリックで Base64 Encoder ツールに切り替えられます。
デコードの仕組み
各Base64文字は6ビット値(0–63)にマッピングされます。4つの連続する文字は24ビットを提供し、元のデータの3バイトにデコードされます。以下の例は「TWFu」が「Man」にデコードされる様子を示しています:
例 "Man" → TWFu → "Man"
| 文字 | インデックス | 6ビット |
|---|
| T | 19 | 010011 |
| W | 22 | 010110 |
| F | 5 | 000101 |
| u | 46 | 101110 |
4つの6ビットグループ(010011 010110 000101 101110)が24ビットに連結され、3つの8ビットバイトに分割されます:01001101(M=77)、01100001(a=97)、01101110(n=110)。
パディングの理解
Base64エンコードは入力バイトを3つのセットにグループ化します。入力長が3で割り切れない場合、最後のグループを完成させるためにパディング文字(=)が追加されます。デコード時、これらの=文字は取り除かれ、デコーダーはエンコード中に追加された余分なゼロビットを破棄することを認識します。
| 元のデータ | エンコード済み | パディングルール |
|---|
| A | QQ== | 1 byte → 2 padding chars |
| AB | QUI= | 2 bytes → 1 padding char |
| ABC | QUJD | 3 bytes → no padding needed |
一般的なユースケース
JWTペイロードの検査
JWTトークンは3つのURL-safe Base64エンコードされたセグメントで構成されています。2番目のセグメント(ペイロード)をデコードすると、署名キーなしにクレーム(ユーザーID、ロール、有効期限、その他のメタデータ)が明らかになります。
APIレスポンスの読み取り
REST APIはJSONレスポンスでバイナリデータ(ファイルコンテンツ、サムネイル、暗号化マテリアル)をBase64エンコードして頻繁に返します。元のデータを読み取るためにフィールドをデコードします。
メールコンテンツのデコード
MIMEメールの本文と添付ファイルはBase64エンコードされています。デコードすると元のテキストコンテンツが明らかになるか、バイナリ添付ファイルを再構築できます。
Kubernetesシークレットの抽出
KubernetesはYAMLマニフェストでシークレット値をBase64として保存します。デコードするとクラスターに保存されている実際のパスワード、トークン、キーが明らかになります — デバッグと監査に役立ちます。
設定のデバッグ
環境変数とCI/CDパイプラインシークレットは、YAMLやJSON設定ファイルに安全に保存するためにBase64エンコードされることが多いです。デバッグ中に実際の値を確認するためにデコードします。
Data URIのデコード
Data URIはBase64エンコードされたアセットをHTML/CSSに直接埋め込みます。Base64部分をデコードして元の画像、フォント、またはその他の埋め込みリソースを抽出します。
よくある落とし穴
実際のBase64デコードエラーの最も頻繁な原因を以下に示します:
✕不足しているパディング
Base64文字列の長さは4の倍数でなければなりません。多くのAPIとJWTライブラリはコンパクトさのために末尾の=を削除します。パディングを追加し直す:不足している=の数は(4 - 長さ % 4) % 4です。
✕URL-safe文字が変換されていない
URL-safe Base64は+と/の代わりに-と_を使用します。URL-safe Base64を直接atob()やbase64.b64decode()に渡すと失敗します。標準ライブラリでデコードする前に常に- → +と_ → /に置換してください。
✕空白と改行
PEM証明書、MIMEデータ、コピー&ペーストされたBase64には76文字ごとに改行が含まれることがよくあります。InvalidCharacterErrorを避けるためにデコード前にすべての空白を削除してください。
✕バイナリ出力 vs テキスト出力
Base64はテキストだけでなく、あらゆるバイナリデータをエンコードできます。元のデータがバイナリファイル(画像、PDF)だった場合、UTF-8テキストとしてデコードするとゴミが生成されます。テキスト以外のペイロードには適切なバイナリ出力方法を使用してください。
コード例
一般的な言語と環境でBase64文字列をデコードする方法:
JavaScript (browser)
// Standard Base64
const decoded = decodeURIComponent(escape(atob(encoded)))
// URL-safe Base64 (restore padding first)
function decodeUrlSafe(str) {
const padded = str.replace(/-/g, '+').replace(/_/g, '/')
const pad = padded.length % 4
return decodeURIComponent(escape(atob(padded + '='.repeat(pad ? 4 - pad : 0))))
}Node.js
// Standard
const decoded = Buffer.from(encoded, 'base64').toString('utf8')
// URL-safe
const decoded = Buffer.from(encoded, 'base64url').toString('utf8')Python
import base64
# Standard
decoded = base64.b64decode(encoded).decode('utf-8')
# URL-safe (add padding if missing)
padding = '=' * (-len(encoded) % 4)
decoded = base64.urlsafe_b64decode(encoded + padding).decode('utf-8')CLI (bash)
# Standard
echo "SGVsbG8sIFdvcmxkIQ==" | base64 -d
# URL-safe (restore + and / first)
echo "SGVsbG8sIFdvcmxkIQ" | tr '-_' '+/' | base64 -d
Base64 Decoder と代替手段の比較
Base64 をデコードできるツールは複数ありますが、プライバシー、速度、利便性の点で異なります。
このツール
ブラウザベースで即時動作、プライベート。データはいかなるサーバーにも送信されません。標準・URL-safe Base64 の両方に対応し、パディングの不足を自動修正し、オフラインでも動作します。
CLI (base64 -d)
スクリプトや大きなファイルに適して高速。ターミナルが必要。URL-safe 入力(-_ → +/)には手動での正規化が必要です。
汎用ツール
Curl、Postman、ブラウザの DevTools、オンラインコンバーターはいずれも Base64 をデコードできます。利便性はさまざまで、リモートサーバーにデータを送信するものもあります。
よくある質問
デコードするとなぜ文字化けしますか?
最も一般的な原因は、バイナリデータ(画像、圧縮ファイル)をUTF-8テキストとしてデコードすることです — バイナリバイトは有効なUnicodeシーケンスを形成しないことが多いです。別の原因は+/を期待する標準デコーダーでURL-safe Base64(-_)をデコードすることです。ソースがどのバリアントを使用しているか確認してください。
InvalidCharacterErrorとは何ですか?
atob()のこのブラウザエラーは、入力にURL-safeな文字(-または_)、空白、改行、非ASCII文字などBase64アルファベット外の文字が含まれている場合に発生します。atob()を呼び出す前に空白を削除してURL-safeな文字を変換してください。
自分のBase64がURL-safeか標準かを知る方法は?
-または_の文字を探します:存在する場合はURL-safe Base64です。標準Base64は+と/を使用します。URL-safe Base64は通常、パディング文字=も省略します。JWTトークンは常にURL-safe Base64を使用します。
Base64デコードはサイレントに失敗することがありますか?
はい。一部のデコーダーはエラーを投げずに無効な文字を静かに無視し、不正確な出力を生成します。デコーダーが成功したと仮定するのではなく、デコードされたデータが期待される形式(JSON、画像ヘッダーなど)と一致することを常に検証してください。
Base64デコードのサイズ制限はありますか?
このブラウザベースのツールは、UIが遅くなる前に数メガバイトまでのBase64文字列を処理できます。非常に大きなファイルには、CLIツールやサーバーサイドデコーダーを使用してください。
Base64が1つまたは2つの=記号で終わるのはなぜですか?
=はパディング文字です。Base64は3バイトを4文字にエンコードします。元のデータの長さが3の倍数でない場合、合計出力長が4の倍数になるように1つまたは2つの=文字が追加されます。=が1つは最後のグループに2つの入力バイトがあることを意味し、==は1つの入力バイトを意味します。
バイナリファイル、画像、PDFはデコードできますか?
はい、ただし出力は生のバイナリデータとなり、テキストとして正しく表示されない場合があります。バイナリコンテンツには、data URI を '<'img'>' タグや '<'a'>' タグで直接使用するか、スクリプトを使ってデコードされたバイトをファイルに保存する方法が適しています。
デコードのサイズ制限はありますか?
このツールはすべてブラウザ内で動作し、サーバー側の制限はありません。実際の制限はブラウザのメモリに依存します。非常に大きな Base64 文字列(数 MB 以上)は、base64 -d(Linux/macOS)や certutil -decode(Windows)などの CLI ツールで処理することをお勧めします。