Base64エンコード・デコード

Base64は3バイトを4文字に書き換える方式です

Base64エンコードは、データを3バイト(24ビット)ずつにまとめ、6ビットずつ4つに分けたうえで、0~63の番号をA~Z、a~z、0~9、+、/ の64文字のどれかで書き表す方式です。そのため、3バイトは必ず4文字になり、結果は元のデータより約33%長くなります。日本語はまずUTF-8のバイトに変換されるので、「こんにちは 👋」は20バイトで、Base64では末尾に=が1つ付いた28文字の 44GT44KT44Gr44Gh44GvIPCfkYs= になります。Base64は暗号化ではないため、誰でもそのまま元に戻せます。

上のツールでは、元の文字の欄もBase64の欄も編集できます。元の文字を直すとエンコードされ、Base64の欄に値を貼り付けるとデコードされます。Authorization: Basic ヘッダー、メール件名の =?ISO-2022-JP?B?…?=、data: URL、PEM証明書、PowerShellの -EncodedCommand のように包まれた値も、そのまま貼り付ければ包みを外して読みます。UTF-8として読めないバイトは、Shift_JISやUTF-16などの別の文字コード、またはPNG・PDFなどのファイルとして判別します。判定経路には変換が通った段階が、グループレールと拡大表示には3バイトが4文字に変わる位置が表示されます。

Base64を自分で解く・作る場面

• HTTP Basic認証のヘッダーを確認するとき: RFC 7617では、ユーザーID、コロン(:)、パスワードをつなげてBase64にしたものを Authorization: Basic の後ろに付けて送ります。たとえば admin:1234 は YWRtaW46MTIzNA== です。つまり、このヘッダーを見た人は誰でもパスワードを読めるため、Basic認証はHTTPSの上でだけ使うべきです。
• メールの件名が =?ISO-2022-JP?B?…?= のように見えるとき: メールのヘッダーにはASCII文字しか使えないので、日本語の件名はRFC 2047のencoded-wordで書かれます。たとえば「【ロベリン】商品を発送しました」は =?ISO-2022-JP?B?GyRCIVolbSVZJWolcyFbPiZJSiRySC9BdyQ3JF4kNyQ/GyhC?= になります。1つ目と2つ目の?の間のISO-2022-JPは文字コード、Bは「Base64」の印です。日本のメールでは今もISO-2022-JPが多く、中身はエスケープシーケンス(1B 24 42)で始まる7ビットのバイトなので、UTF-8で読んでも正しく表示されません。ヘッダーの値ごと貼り付けると、書かれた文字コードで読み取ります。
• 設定値やKubernetes Secretを読むとき: Kubernetes Secretのdataフィールドの値はBase64でエンコードした文字列でなければならず、エンコードしたくない場合はstringDataフィールドを使います。取り出した値の中身の確認や、設定に入れるBase64の作成に使います。
• JSONに画像やPDFなどのファイルを入れるとき: 文字しか受け付けない形式にファイルのバイトを入れるとき、Base64がよく使われます。Base64の欄に貼り付けた値が文字ではない場合、このツールは形式とサイズを表示し、ファイルとして保存できるようにします。
• JWTの中身を見るとき: JWTをドット(.)で分けた各部分は、URL-safeの文字を使い末尾の=を省いたBase64url(RFC 7515)です。ヘッダーとペイロードはここでも解けますが、署名は検証しません。
• PowerShellの -EncodedCommand の値を作る・確認するとき: PowerShellのドキュメントによると、この値はUTF-16LEの文字列をBase64にしたものでなければなりません。同じ Get-Date でも、UTF-8なら R2V0LURhdGU=、UTF-16LEなら RwBlAHQALQBEAGEAdABlAA== と、まったく違う値になります。
• 証明書・鍵のファイル(PEM)を扱うとき: -----BEGIN CERTIFICATE----- の間の本文はBase64で、RFC 7468に従い1行を64文字で折り返します。本文を解くと、DER形式のバイトが出てきます。

使い方

1. エンコード: 元の文字の欄に文字を入れるか、「ファイルを入れる」でファイルを選びます。元の文字の欄にファイルをドロップしたり貼り付けたりしてもかまいません。Base64の欄にすぐ結果が出ます。
2. デコード: Base64の欄に値を貼り付けます。前後に引用符やヘッダー名が付いていても大丈夫です。元の文字の欄に文字が出ます。文字ではない場合は、形式とサイズを示したファイルカードが出ます。
3. 形を選ぶ: 操作パネルで、標準(+ /)かURL-safe(- _)、=あり・なし、1行・76文字・64文字の折り返しを選びます。貼り付けた値の形は操作パネルにそのまま反映されるため、解いた文字を直しても同じ形で作り直されます。
4. 文字コード: 初期値は自動判定です。解いた文字がおかしいときは、UTF-8、Shift_JIS、UTF-16LEなどの文字コードを自分で選びます。1行に値が1つずつ複数入っている場合は、「1行ずつ別々に」をオンにします。
5. 確認: 判定経路で、外した包み、無視した空白、補ったパディングを確認します。レールのグループを押すと、拡大表示にそのグループのビットが出ます。他のツールと結果が違う場合は、「同じ文字でも違うBase64」の一覧で原因を探し、行を押すとその値をコピーできます。

3バイトが4文字になる規則

「あ」のUTF-8のバイト E3 81 82 を例にします。3バイトをつなぐと24ビットになり、これを6ビットずつ区切ると、0~63の番号が4つ出ます。その番号を下の文字表で探して書くと、44GC になります。

データの末尾が3バイトで割り切れない場合は、足りないビットを0で埋めて文字を作り、空いた位置は=で表します。バイトが1つ余ると文字2つと==、2つ余ると文字3つと=が付きます。RFC 4648は、エンコーダーが埋めるビットを0にするよう定めており、0ではない値はデコーダーが拒否してもよいとしています。

Base64の長さの計算

パディングを付けるとBase64の長さは 4 × ⌈n ÷ 3⌉(n = バイト数)で、パディングを省くと ⌈4n ÷ 3⌉ です。長さを決めるのは文字数ではなくバイト数です。日本語のひらがなや漢字はUTF-8で1文字3バイトなので、同じ文字数なら英数字の3倍ほどBase64が長くなります。メールのように76文字ごとにCRLFの改行を入れると、1行ごとに2文字増えます。

標準・URL-safe・MIME・PEMの違い

名前は違っても、3バイトを4文字に変える計算は同じです。違うのは、62・63番の文字、末尾の=、折り返しの3点だけです。

デコードの規則も少しずつ違います。RFC 4648はアルファベット外の文字が混じっていたら拒否するよう定めていますが、メール用のRFC 2045は改行や表にない文字を無視するよう定めています。ブラウザの atob() は空白だけを取り除き、- や _ があるとエラーにします(WHATWG forgiving-base64)。このツールは、改行と空白を無視し、URL中の%2B・%2F・%3DとJSON文字列の\n表記を元の文字に戻し、標準とURL-safeの文字をどちらも受け付けます。それ以外の文字は位置を示して停止します。

同じ文字でも文字コードごとに違うBase64

Base64はバイトを文字で書き表す方法にすぎないので、文字をどんなバイトに変えたか(文字コード)によって結果が変わります。英字のHelloはUTF-8でもShift_JISでもバイトが同じなのでBase64も同じですが、日本語は文字コードごとにまったく違う値になります。UTF-8で書かれたバイトをShift_JISで読むと、たとえば「こんにちは」が「縺薙ｓ縺ｫ縺｡縺ｯ」のようになります。これが文字化けの典型的な姿です。

自動判定は、まず先頭のバイトでPNG・JPEGなどのファイルかどうかを確かめます。次に、① メール件名・data: URL・PowerShellのように文字コードが書かれている、または決まっている値、② 先頭のBOM(EF BB BF、FF FE、FE FF)、③ ASCII文字ごとに00が挟まるUTF-16の形、④ UTF-8の順に、制御文字なしで読めるかを見ます。それでも読めなければ、EUC-KR・Shift_JIS・Windows-1252と00のないUTF-16ですべて読んでみて、その文字コードらしい文字(かな・漢字、ハングル、アクセント付きのラテン文字)で最もよく埋まる結果を選びます。同点なら、ページの言語の文字コード(日本語ページではShift_JIS)を優先します。バイトだけでは文字コードを確定できないため、結果が不自然なときは操作パネルで直接選んでください。

貼り付けた値の包みと、ツールが外すもの

コピーした値には、Base64の前後にヘッダー名や形式の印が付いていることがよくあります。下の形は、包みを外して中のBase64だけを読み、元の文字を直すと同じ包みで作り直します(署名が必要なJWTは除きます)。判定経路の「包みを維持」のチップにある×ボタンで、包みを外すこともできます。

解けないとき、エラー別の原因

Base64の欄の値を読めないときは、ステータス行に何文字目で止まったかと、その周辺の文字が表示されます。元の文字の欄は薄く残り、最後に読めた結果を見せます。

他のツールと結果が違うとき

同じ文字を入れたのにBase64が違うなら、ほぼ必ずバイトが違うか、形の設定が違います。ツールの下にある「同じ文字でも違うBase64」の一覧が、今の元の文字で次のケースを計算し直し、最初の違いから表示します。

コードで行うとき

ブラウザの btoa() は、1バイトに収まらない文字があるとInvalidCharacterErrorを出します。日本語はまずUTF-8のバイトに変換してからエンコードする必要があります。新しい Uint8Array.prototype.toBase64() は、Chrome 140、Firefox 133、Safari 18.2以降で使えます。

// JavaScript: 日本語はUTF-8のバイトに変換してからエンコード(短い文字列)
const bytes = new TextEncoder().encode('こんにちは');
const b64 = btoa(String.fromCharCode(...bytes));          // 44GT44KT44Gr44Gh44Gv
const back = new TextDecoder().decode(Uint8Array.from(atob(b64), c => c.charCodeAt(0)));
bytes.toBase64({ alphabet: 'base64url', omitPadding: true }); // 新しいAPI

# Python
import base64
base64.b64encode('こんにちは'.encode('utf-8'))   # b'44GT44KT44Gr44Gh44Gv'
base64.b64decode('SGVsbG8')                      # =なしで終わるとbinascii.Error: Incorrect padding
base64.b64decode('Zm9v-_', validate=True)        # アルファベット外の文字を捨てずにエラー

# コマンドライン
printf '%s' 'こんにちは' | base64    # echoは末尾に改行を付ける
base64 -w 0 report.pdf              # GNU: 折り返しなし(macOSのbase64は初期値が1行、-b 76で折り返し)

よくある間違い

• Base64を暗号化だと思う: 鍵がなくても誰でも元に戻せます。パスワードやトークンをBase64にしても、隠したことにはなりません。
• echoで作った値をそのまま使う: echo は末尾に改行を付けるので、結果の末尾が K や o= のように変わります。printf '%s' か echo -n を使います。
• 大文字と小文字を変える: Base64は大文字と小文字を別の文字として読みます。表記をそろえようとして変えると、別のデータになるか、解けなくなります。
• URLのクエリに標準Base64をそのまま入れる: フォームデータの解釈では + が空白に変わり、/ と = もURLの中で意味を持ちます。URL-safeを使うか、パーセントエンコードをします。
• 二重にエンコードする: 解いた結果がまたBase64のように見えるときは、ステータス行の横に「もう一度デコード」が出ます。
• 画像のBase64でdata: の頭を忘れる: HTMLやCSSに入れるときは data:image/png;base64, の頭が必要です。画像なら、画像 ↔ Base64変換ツールがHTML・CSSの形まで作ってくれます。

制限事項

• ファイルは5MBまで入れられます(Base64で約700万文字)。欄の文字が40万文字を超えると前後だけが表示され、コピーと保存には全体が入ります。
• 自動判定は、バイトの形から推測した結果です。短い値は複数の文字コードで読めてしまうため、間違えることがあります。
• 作れる文字コードは、UTF-8、UTF-16LE・BE、EUC-KR(CP949)、Shift_JIS、Windows-1252です。メール件名に書かれたISO-2022-JPのような文字コードは読み取り専用で、解いた文字を直すとUTF-8で作り直されます。
• JWTの署名は検証せず、メール件名のQエンコード(=?…?Q?…?=)は解きません。
• ブラウザの文字欄は改行をLFに変えるため、元の文字の欄の改行はLFでエンコードされます。CRLFが必要なときは、「同じ文字でも違うBase64」のCRLFの行をコピーします。
• グループレールは先頭の480グループ(1,440バイト)まで描画します。残りも変換とコピーには含まれます。
• 変換はこのブラウザの中だけで行い、入れた値をサーバーに送ったり、URLやストレージに残したりしません。

出典

基準: Base64の形式はRFC 4648、メール・PEM・認証ヘッダー・JWTの使われ方は各RFC、ブラウザの動作はWHATWGの標準とMDN、コマンドラインと言語ごとの動作は各ドキュメントを、2026年10月21日に確認しました。表の値は、このツールとPython 3.14のbase64モジュールで同じ結果になることを確認しています。

• 01RFC 4648 — The Base16, Base32, and Base64 Data Encodings3.1 改行、3.3 アルファベット外の文字の拒否、3.5 余りビットは0、4節 文字表、5節 URL-safe(- _)、10節 テスト値
• 02RFC 2045 — MIME Part One6.8 1行76文字以下、改行と表にない文字はデコーダーが無視
• 03RFC 2047 — MIME Part Three: Message Header Extensionsencoded-wordの形式 =?charset?B?…?=、1語75文字以下、B = BASE64
• 04RFC 7468 — Textual Encodings of PKIX StructuresPEMの本文は最終行を除いて1行64文字
• 05RFC 7617 — The 'Basic' HTTP Authentication SchemeユーザーID + ':' + パスワードをBase64に、charsetの値はUTF-8のみ
• 06RFC 7515 — JSON Web Signature (JWS)2節 Base64url: URL-safeの文字、末尾の=を省略、改行なし
• 07RFC 2397 — The "data" URL schemedata:[形式][;base64],データ
• 08WHATWG Infra — forgiving-base64 decodeatob()の規則: 空白を除去、末尾の=は1~2個まで許容、+ / 以外の文字は失敗
• 09WHATWG — Encoding StandardTextDecoderによるUTF-8・UTF-16・EUC-KR・Shift_JIS・Windows-1252の解釈
• 10MDN — Window.btoa()1バイトに収まらない文字はInvalidCharacterError
• 11MDN — Uint8Array.prototype.toBase64()alphabet(base64・base64url)とomitPaddingオプション、対応バージョンはMDNのブラウザ互換性データ
• 12Python 3 — base64 moduleb64decode(validate=False)はアルファベット外の文字を捨てる、urlsafe_b64encode
• 13GNU coreutils — base64(1)-w(--wrap)の初期値は76文字、0なら折り返しなし
• 14Microsoft Learn — about_Pwsh-EncodedCommandの値はUTF-16LE文字列のBase64
• 15Kubernetes — Secretsdataフィールドの値はBase64、エンコードしない場合はstringData

よくある質問

一緒に使うツール