Base64 デコード・エンコード:PDF・画像・ファイルに変換

Base64を貼り付けてPDF・画像・テキスト・JWTに戻すか、ファイルをドロップしてBase64に変換。処理はすべてこのタブ内です。

33種類のファイル形式をバイトから判定 · RFC 4648 · アップロードなし
エンコード済み

上に何か貼り付けるか、カードにファイルをドロップするか、例のどれかを押してください。

例

すべてこのタブの中で処理します。貼り付けたりドロップしたりした内容はアップロードされず、デコードしたHTMLやスクリプトはテキストとして表示するだけで、実行はしません。

3バイト → 4文字
例:Man
M77 · 4D1バイト目
a97 · 612バイト目
n110 · 6E3バイト目
1922546

3バイトは24ビットです。Base64はこの24ビットを6ビットずつ4つのグループに分け、各グループが64文字のうち1文字を表します。白い線はバイトの境目で、グループの区切りとは一致しません。これが仕組みのすべてです。

1文字目

16 + 2 + 1 = 19 T

標準のアルファベットのインデックス19です。

1バイトの境目補ったビット(入力外)URLセーフでは別の文字文字にポインターを合わせると、その6ビットの足し算が表示されます。

Base64デコード・エンコードツールの使い方

1つの入力欄に何でも(テキスト、Base64、data: URI全体、JWT)貼り付けるか、ファイルを選択を押すか、カードにファイルをドロップします。ツールが変換の向きを判断して上の表示に示し、逆向きの読み方にもワンクリックで切り替えられます。

ファイルをデコードすると、バイトそのものから判定した形式、サイズ、画像ならピクセルサイズ、画像やPDFのプレビュー、正しい拡張子でのダウンロードが得られます。ファイルをエンコードすると、Base64、そのまま使えるdata: URI、エンコードで増えたサイズがわかります。結果の下のアルファベット、パディング、改行のオプションで、出力を変えられます。

Base64デコードツールの画面:貼り付けたBase64文字列をPDF文書にデコードし、形式、サイズ、3バイトが4文字になる図を表示Base64デコードツールの画面:貼り付けたBase64文字列をPDF文書にデコードし、形式、サイズ、3バイトが4文字になる図を表示1つの入力欄で双方向テキスト、Base64、data: URI、JWTを貼り付けます。どう読み取ったかは上の表示でわかり、メニューで変更できます。ファイルを選択選ぶ代わりに、カードのどこにドロップしてもかまいません。タブから出ることなく、Base64とdata: URIになります。バイトの正体デコードすると、結果の先頭にファイルの形式、サイズ、シグネチャが表示され、続いてプレビューとダウンロードがあります。出力オプション標準またはURLセーフのアルファベット、パディングの有無、MIMEまたはPEM用の改行を選べます。3バイト → 4文字自分のバイトを6ビットずつのグループに切り直して表示します。文字にポインターを合わせると、ビットの足し算がわかります。
PDFをデコードしているところです。番号を選ぶと、各部分の役割がわかります。

Base64とは? なぜ必要なのか

Base64は、どこを通っても壊れない64種類の文字(A–Z、a–z、0–9、+、/)で、任意のバイトを書き表す方式です。メール、URL、JSON、XMLはテキストのために作られており、生のバイトは制御コードや引用符、NULになってそれらを壊すことがあるため、Base64が存在します。

3バイトずつ取り出し、その24ビットを1列に並べて、6ビットずつ4つのグループに切ります。6ビットで表せる値は64通りなので、各グループはちょうど1文字を表します。3バイトが入ると必ず4文字が出るため、Base64は元のデータより約3分の1大きくなります。

Man → TWFu
M77 · 4D1バイト目
a97 · 612バイト目
n110 · 6E3バイト目
1922546TWFu

3バイトは24ビットです。Base64はこれを6ビットずつ4つのグループに切り直し、各グループが64種類の表示可能な文字のうち1文字を表すので、3バイトは必ず4文字になります。33%の増加はここから生じます。

Ma → TWE=
M77 · 4D1バイト目
a97 · 612バイト目
バイトなし—3バイト目
19224—TWE=

2バイトは16ビットです。Base64は2ビットの0を補って3つ目のグループを完成させ、4文字目の位置には=が1つ入ります。

M → TQ==
M77 · 4D1バイト目
バイトなし—2バイト目
バイトなし—3バイト目
1916——TQ==

1バイトは8ビットです。Base64は4ビットの0を補って2つ目のグループを完成させ、3文字目と4文字目の位置には=が2つ入ります。=はビットをまったく持ちません。

白い線は、1つのバイトが終わり次のバイトが始まる位置を示します。6ビットのグループとは位置がずれており、このずれこそが仕組みのすべてです。 出典: RFC 4648 §4

Base64をPDFに変換(デコード)するには?

文字列を貼り付けると、ツールがPDFを復元します。バージョンとサイズを表示し、ブラウザー内蔵のPDFビューアーで文書を開き、ダウンロードもできます。PDFだと指定する必要も、先にdata:の接頭辞を取り除く必要もありません。

PDFは先頭の5バイト%PDF-で判別するため、ファイル名、送信者が示した形式、入っていたフィールドが別の形式を示していても、PDFだと判定できます。バイトがPDFでなければ、もともと存在しない文書を開こうとして失敗するのではなく、それが何であるかを表示します。

ファイルはブラウザー内で復元されます。何もアップロードされないので、給与明細、契約書、請求書のようなPDFでは、この点が重要です。

APIから届くJSON"document": "JVBERi0xLjcKJeLjz9MKMS…"レスポンスの中のフィールドです。引用符はBase64の一部ではありません。
メールの添付ファイルContent-Transfer-Encoding: base64MIMEは本文を1行76文字で折り返します。改行ごと貼り付けてください。改行は読み飛ばします。
data: URIdata:application/pdf;base64,JVBERi0x…全体をそのまま貼り付けてください。接頭辞は手で取り除かなくても、ツールが読み取ります。
先頭のバイトで正体がわかる
  1. 25%
  2. 50P
  3. 44D
  4. 46F
  5. 2D-
  6. 311
  7. 2E.
  8. 377

先頭の5バイト%PDF-が、シグネチャのすべてです。6〜8バイト目がバージョンで、1.7です。拡張子は関係ないため、誰かが.txtという名前を付けたPDFでも、PDFとして戻ってきます。

Base64のPDFをコピーしてくる3つの場所と、デコードしたあとにPDFだとわかるバイト。 出典: ISO 32000-1:2008 §7.5.2, RFC 8118 §8

画像をBase64にエンコードするには? 使うべき場面は

画像をドロップすると、そのBase64と、HTMLやCSSにそのまま貼り付けられるdata: URIが得られます。難しいのは、そうすべきかどうかです。Base64は常に約3分の1大きくなり、インライン画像は単独ではキャッシュできません。

逆にBase64を画像に変換すると、形式、サイズ、そして画面上の見た目ではなくファイル自体のヘッダーから読み取った実際のピクセルサイズがわかり、正しい拡張子でダウンロードできます。

  • ディスク上のファイル12.9 KB 100%
  • Base64にした場合17.3 KB +33.4%
  • MIME用に76文字で改行17.5 KB +35.1%
  • ファイルをgzip圧縮11.7 KB -9.5%
  • Base64をgzip圧縮12.5 KB -3.2%
独立したファイル
  • ダウンロードは1回だけ
  • ブラウザーとCDNがキャッシュ
  • ページの中ではなく、ページと並んで取得
同じ画像をインライン化
  • 圧縮前で3分の1大きい
  • 埋め込んだファイルの一部としてしかキャッシュされない
  • スタイルシートやHTMLの一部として解析される

圧縮でその大半は取り戻せます:gzip圧縮すると、Base64はgzip圧縮したファイルより7%大きいだけです。取り戻せないのは、画像単独のキャッシュです。HTMLページにインライン化すると、その画像を含むページを開くたびに毎回ダウンロードされます。

目安:インライン化するのは数百バイト程度(アイコン、スペーサー、メール内のロゴ)にとどめ、それより大きいものはリンクにします。この12.9 KBのPNG画像は、すでにその線を越えています。

ツールの例でデコードされる画像で測定しました。同じバイトを5通りの形で運び、gzipは最高レベルで圧縮しています。 出典: RFC 2045 §6.8

Base64とURLセーフなBase64の違いは?

URLセーフなBase64(RFC 4648 §5)は、2つの文字を入れ替えただけの同じエンコード方式です。+が-に、/が_になります。パディングも省略されることがよくあります。

結果をURL、ファイル名、Cookieに入れる場合は、どこでもこちらを使います。JSON Web Token(JWT)は全体でこの方式を使うため、トークンの各部分が=で終わることはありません。このツールは両方のアルファベットを読み取り、1つの文字列に両方が含まれているときは知らせます。

標準(RFC 4648 §4)+/8=
URLセーフ(RFC 4648 §5)-_8=
JWTのbase64url(RFC 7515 §2)-_8
  • + → -インデックス62。クエリ文字列では、フォームのデコーダーが+をスペースとして読むため、データが正しく戻りません。
  • / → _インデックス63。パスでは/が新しいセグメントの始まりになるため、値が2つに分かれてしまいます。
  • =を省略URLの中では、=は通常%3Dとパーセントエンコードされます(RFC 4648 §5)。JWTではまったく付けません(RFC 7515 §2)。長さだけで、バイトがどこで終わるかがわかるからです。

2つのアルファベットの最初の62文字は同じです。そのため、両方のアルファベットを読めるツールならどちらもデコードでき、このページは1つの文字列に両方が含まれているときにそれを知らせます。

2つのアルファベットで異なるのは2文字だけです。それ以外はすべて同じです。 出典: RFC 4648 §5, RFC 7515 §2

Base64は暗号化? いいえ、違います

Base64は何も隠しません。鍵も秘密もなく、元に戻すのに手間はまったくかかりません。このようなデコーダーなら、入力と同時に戻せます。

これが最も問題になるのはHTTP Basic認証です。ヘッダーはユーザー名とパスワードを1つのBase64文字列として運び、目にした人は誰でも読めます。そのためRFC 7617は、TLSのような暗号化された接続上でのみ安全だとしています。読めない状態を保つ必要があるなら、暗号化が必要です。Base64は、テキスト用に作られた経路にバイトを安全に通すためのものにすぎません。

RFC 7617 §2の手順で作ったAuthorizationヘッダー

Authorization: Basic dXNlcjpwYXNzd29yZA==

1ステップで元どおり:鍵もパスワードもいらない

user:password

RFC 7617はヘッダーを手順を追って組み立てますが、その最後の手順が「保護」のすべてです。そこでクライアントは「このオクテット列をBase64でエンコードしてbasic-credentialsを得る」とされています。その意味は§1に書かれています。TLSなどの仕組みで接続が保護されていない限り、「ユーザーIDとパスワードは平文としてネットワーク上で渡される」のです。Base64には鍵がないので、破るものもありません。文字列を手にした人は、パスワードを手にしたのと同じです。

上の認証情報は架空のものです。元に戻すのに必要なのは1つの手順だけで、鍵はいりません。これが「暗号化ではなくエンコード」という意味です。 出典: RFC 7617 §2, §1

デコードしたテキストが文字化けするのはなぜ?

Base64が運ぶのはバイトで、バイトは何かが文字コードを選んで初めて文字になるからです。UTF-8のテキストをISO-8859-1として読むとéはéになり、ISO-8859-1をUTF-8として読むと置換文字になります。

data: URIは文字コード(charset)を宣言でき、このページはすべてをUTF-8で読むのではなく、その文字コードでテキストを読みます。宣言された文字コードのデコーダーがブラウザーにない場合は、間違った文字を黙って表示せず、そのことを知らせます。

UTF-8で書いた「Café」436166C3A9
ISO-8859-1で書いた「Café」436166E9

UTF-8ではéは2バイト、ISO-8859-1では1バイトです。Base64が運ぶのは文字ではなくバイトなので、どちらのつもりだったかを、デコーダーが文字列そのものから知ることはできません。

正しく読んだ場合Café
UTF-8のバイトをISO-8859-1として読むCafé
ISO-8859-1のバイトをUTF-8として読むCaf�
文字化けには2つの形があります。UTF-8を1バイトのコードページとして読むと、読めても意味をなさない文字(Café)になり、バイトがそもそも正しいUTF-8でないと、置換文字(Caf�)になります。 出典: RFC 4648 §4, RFC 2397 §4

Python・JavaScript・Java・C#・Go・PowerShell・シェルでBase64を扱う

どの言語にもBase64は組み込まれています。落とし穴はどこでも同じで、文字列ではなくバイトをエンコードすること、そしてテキストの文字コードを明示することです。

最も注意が必要なのはJavaScriptのbtoa()です。U+00FFまでの文字しか受け付けないため、Latin-1を超える文字は、先にTextEncoderでUTF-8のバイトにする必要があります。下の例はどれも「Man」をエンコードしてデコードするもので、実際に実行して出力を確認しています。

import base64

b64 = base64.b64encode("Man".encode("utf-8")).decode("ascii")
print(b64)                                    # TWFu
print(base64.b64decode(b64).decode("utf-8"))  # Man

2026年10月26日にPython 3.14.4で実行し、コメントのとおりに出力されました。

どのコードも「Man」で実行し、コメントに書いたとおりの結果を出力します。シェルのbase64 -dは、古いmacOSでは-Dです。 出典: gnu.org, developer.mozilla.org

Base64の変換表:0〜63のアルファベット

6ビットのグループはそれぞれ0〜63の数で、この表で文字を引きます。Base64は大文字と小文字を区別します。Aは0、aは26なので、文字の大文字・小文字を変えると文字列が壊れます。

見た目で覚えておくと便利です。Aの連続はゼロのバイトの連続で、JVBERで始まるBase64文字列はPDF、iVBORならPNG、/9j/ならJPEGです。

  1. A0
  2. B1
  3. C2
  4. D3
  5. E4
  6. F5
  7. G6
  8. H7
  9. I8
  10. J9
  11. K10
  12. L11
  13. M12
  14. N13
  15. O14
  16. P15
  17. Q16
  18. R17
  19. S18
  20. T19
  21. U20
  22. V21
  23. W22
  24. X23
  25. Y24
  26. Z25
  27. a26
  28. b27
  29. c28
  30. d29
  31. e30
  32. f31
  33. g32
  34. h33
  35. i34
  36. j35
  37. k36
  38. l37
  39. m38
  40. n39
  41. o40
  42. p41
  43. q42
  44. r43
  45. s44
  46. t45
  47. u46
  48. v47
  49. w48
  50. x49
  51. y50
  52. z51
  53. 052
  54. 153
  55. 254
  56. 355
  57. 456
  58. 557
  59. 658
  60. 759
  61. 860
  62. 961
  63. +URLセーフでは-62
  64. /URLセーフでは_63

0–25がA–Z、26–51がa–z、52–61が0–9です。2つのアルファベットで異なるのは表の最後の2文字だけで、上に印を付けています。=は表にまったく含まれません。値ではなく、最後の3バイトのグループが足りなかったことを示す印です。

RFC 4648 §4の順に並べた64文字。各文字の下の数字は、その文字が表す6ビットの値です。 出典: RFC 4648 §4

Base64:よくある質問

Base64デコードとは?

4文字ずつのグループを、それが表す3バイトに戻すことです。そのバイトはテキストのこともあれば、PDF、PNG画像、ZIPアーカイブのようなファイル全体のこともあります。このツールは先頭のバイトでどちらかを判別し、記号の羅列ではなくテキストやファイルそのものを表示して、ダウンロードもできます。

Base64のファイルをデコードするには?

Base64文字列を入力欄に貼り付けます。ツールがデコードし、先頭のバイトをツールが知っているファイルシグネチャ(全部で33種類のファイル形式)と照合して形式を示し、画像やPDFならプレビューして、正しい拡張子でダウンロードできるようにします。ファイルの種類を指定する必要はなく、判定のために何かがアップロードされることもありません。

Base64は何に使われますか?

テキスト用に作られた場所にバイトを通すために使われます。メールの添付ファイル(MIME)、HTMLやCSSのdata: URI、JSONやXMLのバイナリフィールド、JSON Web Token、HTTP Basic認証、PEMファイルの証明書や鍵などです。どれも生のバイトを変えたり落としたりしかねない経路を通るため、データはただの英数字として運ばれます。

Base64は暗号化ですか?

いいえ。Base64はエンコード方式で、暗号ではありません。鍵も秘密もなく、このページが入力と同時に行っているように、誰でもすぐに元に戻せます。Base64で書かれたものは丸見えだと考えてください。データを秘密にするなら先に暗号化し、テキストとして運ぶ必要があれば、暗号化したバイトをBase64にします。

Base64をオンラインでデコードしても安全ですか?

このページなら安全で、自分で確かめることもできます。デコードはすべてブラウザーのタブ内のJavaScriptで行い、貼り付けやドロップした内容はアップロードしません。デコードしたHTML、SVG、スクリプトはテキストとして表示して実行せず、画像やPDFはブラウザー自身のビューアーで表示します。使用中に開発者ツールのネットワークタブを開けば、データを含むリクエストがないことを確認できます。

Base64が元のデータより33%大きくなるのはなぜ?

3バイトが必ず4文字になり、4÷3は1.33だからです。末尾には最大2つの=のパディングが付き、メール用に76文字ごとに改行するとすべての行に改行が加わるので、長い文字列は運ぶバイトより35%ほど大きくなることがよくあります。gzipなどの圧縮で、その大半は取り戻せます。

URLセーフなBase64とは?

RFC 4648 §5の定義どおり、+を-に、/を_に置き換えたBase64で、結果をエスケープせずにURL、ファイル名、Cookieに入れられます。JSON Web Tokenのように、パディングも省略するのが一般的です。このツールは、1つの文字列に混在していても両方のアルファベットを読み取り、どちらでも書き出せます。

Base64のデコードが失敗するのはなぜ?

ほとんどの場合、Base64のアルファベットにない文字が1つ混ざっているからです。チャットアプリが文字列を切った場所の省略記号、ワープロのスマートクォート、PDF由来のノーブレークスペースなどです。このツールはその文字の名前と位置を示し、手前までにデコードできた量を伝えます。残りがまだデコードできる場合は、「削除してデコード」で取り除くこともできます。

Base64を画像に変換できますか?

はい。data:image/png;base64,のような接頭辞があってもなくても、文字列を貼り付ければ画像が表示され、形式、サイズ、ファイル自体のヘッダーから読み取った実際のピクセルサイズがわかります。あとは正しい拡張子でダウンロードするだけです。PNG、JPEG、GIF、WebP、BMP、ICO、AVIFはプレビューでき、SVGはスクリプトを含められるため、まずテキストとして表示します。

Base64の末尾の=は何を意味しますか?

最後の3バイトのグループが足りなかったという意味です。余りが2バイトなら3文字と=1つに、1バイトなら2文字と==になります。パディング自体はデータをまったく持たず、バイトがどこで終わるかをデコーダーに伝えるだけです。このツールを含む多くのデコーダーは、パディングが省略されたBase64も読み取れます。

サイズの上限はありますか?

選択またはドロップするファイルは10 MBまでです。それより大きいファイルは名前とサイズを示して拒否し、途中まで読むことはありません。貼り付けたテキストの上限は14,349,002文字です。10 MBのファイルを改行付きでBase64にしても収まる長さなので、このツールでエンコードしたものは必ずデコードし直せます。大きな入力はバックグラウンドで読むため、入力中も動作は滑らかです。

ここでJWTをデコードできますか?

はい。トークンを貼り付けると、ヘッダーとペイロードが整形されたJSONで表示され、iatとexpのクレームの横には日時が、署名はバイトとして表示されます。このページは3つのbase64urlの部分をデコードするだけで、署名を検証せず、トークンを有効と判断することもありません。トークンを信頼するかどうかの判断には使わないでください。

足りないものはありますか?機能や新しいツールを提案する