Base64エンコード・デコード
テキストやファイルをBase64にエンコードし、文字列をバイト列にデコード。ブラウザ内で実行。パディング例、RFC 4648アルファベット、URL-safe版に対応。
すべての計算はブラウザ内で実行されます。入力内容がサーバーに送信されることはありません。
入力すると結果が更新されます。Ctrl/Cmd+Enterで主な結果をコピー。
結果
—
ビット表示
途中式を表示
Base64エンコード・デコードは、任意のバイト列を RFC 4648 アルファベットで ASCII 文字列に変換し、その文字列を元のバイト列に戻します。テキストモードでは UTF-8 などの文字エンコーディングを指定できます。ファイルモードではブラウザの FileReader でアップロードを読み取り、埋め込み用の data: URI を出力できます。エンコードは暗号化ではありません。文字列を受け取った人なら誰でもデコードできます。
エンコードとデコードはすべてブラウザ内で実行されます。貼り付けた内容がサーバーに送られることはありません。
テキストまたはファイルをBase64にエンコードする
エンコードは生バイト列を、A から Z、a から z、0 から 9、プラス、スラッシュ、パディング = の文字列に書き出します。テキストを貼り付けるかファイルを選び、ソースがテキストのときは文字エンコーディングを選び、出力を読み取ります。
ファイルモードは、JSON、XML、メールなどバイナリ経路のない場所を通過しなければならない小さな画像や文書に向いています。
出力は、古いメールゲートウェイや XML へのコピーと貼り付けのように、任意のバイナリを壊してしまうシステムを通過しても安全です。意図的に入力より長くなります。無効な空入力では文字列は出ません。ツールはバイト列を受け取るまで文字を出力しません。
Base64文字列をデータにデコードする
デコードはアルファベット参照を逆にし、元のビット列を再構成して、テキストまたはダウンロード可能なファイルを返します。末尾のパディング = は重要です。最後の不完全グループに何バイトあったかを示します。アルファベット外の文字は、黙って部分デコードするのではなく、明確なエラーになります。
空白は多くの場合無視されるため、PEM 証明書や MIME 本文からコピーした文字列も動作します。Base64 に見えるが URL-safe アルファベットを使う文字列は、URL-safe デコードモードが必要です。そうでなければハイフンとアンダースコアは標準アルファベットでは不正として拒否されます。
Base64エンコードの仕組みを理解する
Base64 は入力を 3 バイト(24 ビット)のブロックで処理します。その 24 ビットを 6 ビットずつ 4 グループに分割します。各 6 ビット値は 64 文字アルファベットへの 0 から 63 のインデックスです。したがって 3 入力バイトは 4 出力文字になります。
Bytes: [ byte1 ][ byte2 ][ byte3 ]
Bits: aaaaaaaa bbbbbbbb cccccccc
Groups: aaaaaa aabbbb bbbbcc cccccc
Chars: Char1 Char2 Char3 Char4
残りが 3 バイト未満のとき、エンコーダは依然として 4 文字を出力しますが、デコーダが元の長さを知れるようパディングを付けます。ビットの再グループ化がアルゴリズムの全体です。チェックサムも鍵もありません。
単語 Dog を段階的にエンコードする
単語 Dog は 3 バイトの ASCII なので、1 つの Base64 グループを満たし、パディング文字なしでエンコードされます。固定出力は RG9n です。バイトをビットに、6 ビットインデックスに再グループ化し、RFC 4648 アルファベットを参照すると、なぜこの 4 文字になるか、任意の 3 バイトブロックが同じ経路をたどる理由が分かります。
1. バイトを書く。 D = 0x44 = 01000100 o = 0x6F = 01101111 g = 0x67 = 01100111
2. 24 ビットを連結する。 01000100 01101111 01100111
3. 6 ビットグループに分割する。 010001 000110 111101 100111
4. 各グループを 10 進インデックスに変換する。 17, 6, 61, 39
5. アルファベットを参照する。 インデックス 17 = R、6 = G、61 = 9、39 = n
結果: RG9n。RG9n をデコードすると 3 元バイトと、UTF-8 または ASCII 下のテキスト Dog が返ります。
等号によるパディングを理解する
バイト数が 3 の倍数でないときパディングが現れます。余り 1 バイトはアルファベット文字 2 つと = 2 つを生成します。余り 2 バイトは文字 3 つと = 1 つを生成します。固定例 Do → RG8= と Dogs → RG9ncw== は、パディングなしの 3 バイト語 Dog の横に、両方の余りケースを示します。
| Input | Bytes | Encoded | Padding |
|---|---|---|---|
| Dog | 3 | RG9n | none |
| Do | 2 | RG8= | one = |
| Dogs | 4 | RG9ncw== | two = |
Do は 2 バイト: 01000100 01101111。6 ビットグループ化後、意味のある文字は 3 つ(RG8)分のビットしかなく、パディング = 1 つが 4 番目のスロットを埋めます。Dogs は 4 バイト: 完全な 3 バイトグループが RG9n としてエンコードされ、1 バイト余りが cw== としてエンコードされます。ビット長を調整せずに手でパディングを外すとデコードが壊れます。貼り付け時は = 文字をそのまま残してください。
Base64アルファベットを読む
RFC 4648 は 64 文字とパディング記号 = を定義します。インデックス 0 から 25 は A から Z、26 から 51 は a から z、52 から 61 は 0 から 9、インデックス 62 は +、インデックス 63 は / です。
インデックス 0 は A であり 0 ではありません。数字が先頭にあると期待する人を混乱させます。
| Index range | Characters |
|---|---|
| 0 to 25 | A to Z |
| 26 to 51 | a to z |
| 52 to 61 | 0 to 9 |
| 62 | + |
| 63 | / |
| padding | = |
計算機のアルファベットパネルはエンコーダが使うのと同じ表を表示するため、疑わしい文字を標準セットと照合できます。完全な文字列は ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/ です。
URL-safe Base64版を使う
URL-safe アルファベット(base64url)は + を - に、/ を _ に置き換えます。一部プロトコルではパディングを省略できます。JSON Web Token はこの版を使い、トークンセグメントを URL や HTTP ヘッダーに置いてもプラスとスラッシュをパーセントエンコードする必要がありません。
標準版と URL-safe 版は互換ではありません。標準アルファベットで JWT ペイロードをデコードするとハイフンで失敗します。ツールはエンコードとデコードの両方に明示的な URL-safe モードを提供します。URL のパーセントエンコードは別問題です。Base64 ではなく RFC 3986 のエスケープが目的なら URLのエンコードとデコード ページを使ってください。
サイズ増加を見込む
3 バイトごとに 4 文字になるため、エンコード後の長さは入力の約 4/3、改行前で 33 パーセント増です。パディングは最終グループに 1 または 2 文字追加できます。data URI やメール添付はこのコストをすぐに感じます: 300 KB の画像はおおよそ 400 KB のテキストになります。
encoded_length ≈ 4 × ceil(byte_length / 3)
76 文字での折り返し(MIME で一般的)はその上に改行バイトを追加します。サイズが重要ならバイナリ添付や圧縮形式を優先し、チャネルが本当に生バイトを運べないときだけ Base64 を使ってください。
文字エンコーディングを選ぶ
Base64 は抽象文字ではなくバイト列をエンコードします。同じ文字でも UTF-8、UTF-16、Shift JIS、Big5 では異なるバイト列になります。Base64 層が完璧でもデコード後の解釈で文字セットが違うと文字化けします。テキストモードの charset は、エンコード時に生成側、デコード時に受信側と一致させてください。
| Charset | Typical use |
|---|---|
| UTF-8 | Default for modern text and APIs |
| Windows-1252 | Legacy Western European text |
| UTF-16 LE / BE | Some Windows and Java payloads |
| Shift JIS | Older Japanese text |
| Big5 | Older Traditional Chinese text |
単語 Dog では ASCII と UTF-8 は同じ 3 バイトなので RG9n は同一です。非 ASCII テキストは分岐します。エンコード前に生成側に合う charset を、デコード後も同じ charset を選ばないと、上流のミスなのに Base64 の不具合に見えます。
よくある質問
Base64は暗号化ですか?
いいえ。Base64 は公開アルファベットで誰でも逆にできるエンコードです。何も隠しません。機密性が必要なら本物の暗号アルゴリズムを使い、チャネルが ASCII 安全なバイト列を必要とするときに Base64 を使ってください。
Base64出力の末尾に等号が付くのはなぜですか?
= 文字はパディングです。最終入力グループが 3 バイトではなく 1 または 2 バイトだったことを示します。Do は RG8=、Dogs は RG9ncw== にエンコードされます。プロトコルが削除したと明記していない限り、デコード時はパディングを残してください。
Dogは何にエンコードされますか?
Dog は 3 バイトで 1 Base64 グループをぴったり埋めるため、パディングなしで RG9n になります。段階的なビット再グループ化はこのページの計算例に示しています。
標準Base64とURL-safe Base64の違いは?
URL-safe Base64 は + と / の代わりに - と _ を使います。JWT や一部のファイル名埋め込みが URL-safe アルファベットを使います。間違ったアルファベットでデコードすると置換文字で失敗します。
Base64は元データよりどれくらい大きくなりますか?
約 3 分の 1 大きくなります。3 バイトが 4 文字になるので、パディングと改行前の比率は 4/3 です。3,000 バイトのペイロードは 4,000 文字の Base64 になります。
テキストだけでなくファイルもBase64エンコードできますか?
はい。ファイルモードはブラウザでアップロードを読み、生バイト列をエンコードします。逆方向は blob としてダウンロード可能にデコードします。大きなファイルはタブのメモリ使用量を増やすため、アップロードは控えめにしてください。
正しくデコードしたのにテキストがおかしく見えるのはなぜですか?
Base64 層はバイト列を復元しましたが、それを解釈する文字エンコーディングが生成側と一致していません。まず UTF-8 を試し、次にソースシステムが実際に使う charset を試してください。
このツールは貼り付けた秘密情報をアップロードしますか?
いいえ。エンコードとデコードはローカルで実行されます。API キー、トークン、証明書断片をボックスに貼ってもサーバーには送られません。この約束は Quick Calculators のすべてのエンコードページの設計原則と同じです。
Base64はURLエンコードと同じですか?
いいえ。Base64 はバイナリを輸送用 64 文字アルファベットに写像します。URL エンコード(パーセントエンコード)は RFC 3986 に従い URI 内の予約文字をエスケープします。別問題を解決し、互いの代替にはなりません。
アルファベットを定義するRFCは?
RFC 4648 がここで使う標準および URL-safe Base64 アルファベットとパディング規則を定義します。RFC 2045 など古い文書は MIME 文脈の Base64 を似た仕組みで説明します。
まとめ
Base64エンコード・デコードは、6 ビットグループでバイト列を RFC 4648 アルファベットに写し、ブラウザ内でローカルに逆変換します。Dog は RG9n、Do は RG8=、Dogs は RG9ncw== となり、1 バイトと 2 バイト余りのパディングを示します。
URL-safe アルファベットは +// を -/_ に置き換え、出力は約 3 分の 1 増え、文字セットの選択がテキストモードがエンコーダに渡すバイト列を決めます。貼り付けた内容はアップロードされません。
関連計算機
URLのエンコードとデコード · 二進数計算機 · 十六進数計算機