詳細オプション
改行セパレータ
異なるオペレーティングシステムは異なる改行文字を使用します。例えば、Unix と Windows は同じ改行記号を共有しません。デコード後、出力内の改行は選択したオプションにより置き換えられます。この設定は「各行を個別にデコードする」機能の動作を決定します。
各行を個別にデコードする
このオプションを有効にすると、入力の各行が個別の Base64 文字列として扱われ、独立してデコードされます。これは、改行で区切られた複数の異なる Base64 エントリをデコードする必要がある場合に特に有用です。
改行を削除する
メールなどの MIME 形式の Base64 データには、通常、76文字ごとに改行が含まれます。デコード前にこれらの改行を削除するために、このオプションを有効にしてください。これにより、MIME 形式の Base64 データが正しくデコードされます。
URLセーフエンコーディングを処理する
入力が URLセーフな Base64 変種（RFC 4648 / Base64URL）を使用している場合は、このオプションを有効にしてください。この変種では「-」が「+」、「_」が「/」に置き換えられ、パディングが省略される場合があります。このオプションは、デコード前に入力を標準の Base64 に変換します。
ライブモード
ライブモードが有効な場合、入力はブラウザ内蔵の JavaScript 関数により即座にデコードされ、サーバーへデータが送信されません。なお、このモードは現時点では UTF-8 テキスト出力のみをサポートしています。
注意：画像、文書などのバイナリファイルの場合、データ破損を防ぐため、結果をコピーするのではなく保存してください。
Base64 デコードとは何ですか？
Base64 デコードは、Base64 のバイナリからテキストへの符号化スキームを逆方向に実行し、ASCII 文字列をそれを生み出したのと同じバイト列に正確に戻します。Base64 は 64 文字の固定アルファベットを使用します — 大文字 A–Z、小文字 a–z、数字 0–9、そして 2 つの記号 + と / に加えて、末尾のパディング文字としての = です。形式は RFC 4648 §4 によって定義され、同 RFC は + と / の代わりに - と _ を使う URL セーフな変種 Base64URL も記述しています。符号化は 3 バイトの入力（24 ビット）ごとに 4 つの Base64 文字（4 × 6 ビット）に対応付けるため、符号化された出力は常に原本より約 33 ％長くなります。デコードはその比率を逆転させます。JWT のペイロード、MIME 符号化された電子メール添付、インラインの data: URI のすべてが、同じ正確な逆操作によって元のバイト列へ戻ります。
Base64 デコードはどのように機能しますか？
Base64 デコードは符号化パイプラインを機械的に逆転させます。デコーダーは一度に 4 つの Base64 文字を読み取り、64 文字のアルファベットの中で各文字を検索してその 6 ビット値を取り戻し、4 つの 6 ビット値を 1 つの 24 ビットバッファーに連結し、そのバッファーを 3 つの 8 ビットバイトに分割します。末尾の = パディングは、最後のグループが 2 バイト（= が 1 つ）または 1 バイト（= が 2 つ）だけにデコードされることを示します。標準的な例は Base64 文字列 TWFu で、3 文字の ASCII の単語 Man にデコードされます。アルゴリズムに従うと、T はアルファベット索引 19 → 010011、W は索引 22 → 010110、F は索引 5 → 000101、u は索引 46 → 101110。連結するとこれらのビットは 010011 010110 000101 101110 となり、バイト列 01001101 01100001 01101110 に再グルーピングされます — これは M、a、n の ASCII コードです。
- 入力文字列を 64 文字のアルファベットおよびパディング規則と照合し、輸送中に紛れ込んだ余分な空白やアルファベット外の文字を拒否します。
- ルックアップテーブル（または
A–Z a–z 0–9 + /内の位置）を使い、各 Base64 文字を 6 ビット値に変換します。 - 6 ビット値を 4 つずつ連結して 24 ビットバッファーにします。
- 各 24 ビットバッファーを 3 つの 8 ビットバイトに再分割し、これが元のバイナリまたは ASCII データとなります。
- 末尾の
=パディングを尊重し、必要に応じて最終グループから 1 〜 2 バイトを破棄します。
Base64 デコーダーを使う理由は何ですか？
- データの復元:後続の処理の前に、テキストセーフな Base64 ペイロードから元のバイナリバイトを取り戻します。たとえば、PDF の領収書を Base64 として保存していたデータベース列をデコードし、そのバイトをディスクに書き戻して再度開けるようにします。
- メール添付:バイナリ部分を Base64 の行として包む MIME エンコードされたメッセージ本文から、ファイルや画像を抽出します。典型的なケースは、添付ファイルがダウンロードできないときに、保存済みの
.emlファイル内のContent-Transfer-Encoding: base64ブロックから PNG を取り出すことです。 - ウェブリソース:埋め込まれた
data:URI を元のバイトに戻し、ページが実際に何を配信したのかを点検できるようにします。たとえば、CSS ルールにあるdata:image/svg+xml;base64,…の URL を貼り付け、SVG マークアップを復元して監査します。 - API 連携:バイナリフィールドを生のバイトとして運べないときに、REST や GraphQL サービスが返す Base64 ペイロードを処理します。一般的なケースは、リクエストをエンドツーエンドで検証するために、JWT の署名、OAuth リフレッシュトークン、あるいは S3 の
Content-MD5ヘッダーをデコードすることです。
Base64 デコードの一般的な用途は何ですか？
Base64 デコードは、以下のような様々なシナリオで不可欠です：
- メール処理:本格的なメールクライアントを起動せずに、MIME エンコードされたメッセージから添付ファイルを取り出します。エンジニアは、サポートキューの不正なメッセージをトリアージするとき、あるいは元のクライアントがすでにインストールされていない状態で保管された
.mboxエクスポートからファイルを復元するときにこの作業を行います。 - ウェブ開発:インラインの Base64
data:URI を元のバイトに戻し、その資産を監査したり、ハッシュ付きファイルで置き換えたりできるようにします。アイコンをdata:image/svg+xml;base64,…として埋め込んでいるスタイルシートをリファクタリングするときに、これは日常的な作業です。 - API デバッグ:JSON や XML レスポンス内の Base64 フィールドをデコードし、根本の値をログ上で人間が読めるようにします。典型例には、JWT の
payload、MD5 を包む S3 のETag、サードパーティのプロバイダーから返ってきた Webhook 署名ヘッダーなどがあります。
Base64 デコードの例はどのようなものですか？
Base64 文字列 TWFu をデコードすると、単語 Man になります。デコード処理は、各 Base64 文字をその 6 ビット値に変換し、これらのビットを組み合わせて元の ASCII 文字を再構築します。
この Base64 デコーダーは無料でプライベートですか？
はい — この Base64 デコーダーは完全に無料で、アカウントや登録を必要とせず、ブラウザの内部だけで動作します。Base64 文字列を貼り付けたり、ファイルをドロップしたりすると、デコードは標準的な JavaScript API（テキストには atob、バイナリ内容には FileReader と型付き配列への変換）を介してローカルで実行されます。入力は決して端末を離れず、いかなるサーバーログにもコピーは書き込まれず、デコードした内容にテレメトリーが付加されることはなく、レート制限・文字数上限・保存された履歴も存在しません。ページが一度読み込まれれば、最初の訪問で実行されたコードがブラウザにキャッシュされるため、オフラインでも利用できます。フォームフィールドを読み取る可能性のあるサードパーティの分析スクリプトも避けています。これにより、本ツールは JWT ベアラートークン、data: URI に埋め込まれた資格情報、設定上の秘密、Base64 に包まれた証明書や秘密鍵素材といった機密ペイロード — どこにもアップロードしてはならないもの — にとって安全になります。
当社のオンライン Base64 デコーダーツールは、Base64 データを迅速かつ安全にデコードする方法を提供します。ウェブページに埋め込まれた画像を抽出する場合や、API の応答を処理する場合など、Base64 デコードは現代のウェブ開発に不可欠なツールです。