> JPG | encode | data-uri <
// JPG / JPEG 写真を Base64 文字列および data URI にエンコード — EXIF、DCT 係数、品質を保持
JPG / JPEG をここにドロップ、またはクリックして選択
クリックして JPG / JPEG ファイルを選択
ビット単位で同一
JPEG は一切再圧縮されません。DCT 係数、量子化テーブル、EXIF メタデータは往復しても変化しません。
ローカル処理
写真は FileReader + btoa() を使ってブラウザ内でエンコードされます。アップロードなし、サーバーなし、画像バイトに対する解析なし。
すぐに貼り付け可能
規格準拠の data:image/jpeg;base64,… URI をそのまま HTML、CSS、メール、JSON API ペイロードに貼り付けられます。
// FAQ — JPG TO BASE64
Q: JPG の Base64 エンコードとは？
A: .jpg / .jpeg ファイルのバイナリバイトを、Base64 アルファベット (RFC 4648) を使って ASCII セーフな文字列に書き換える処理です。得られたテキストは、個別ファイルを用意することなく HTML、CSS、メール、JSON ボディ、その他テキスト専用チャネルに埋め込めます。重要な点として、元の JPEG は再エンコードされません — DCT 係数、量子化テーブル、ハフマンテーブル、EXIF / IPTC / XMP メタデータマーカーのすべてが保持されます。
Q: JPG を Base64 にエンコードするには？
A: .jpg または .jpeg ファイルをアップロードゾーンにドラッグ（またはクリックして選択）します。ツールは FileReader.readAsDataURL() でファイルを開き、そのまま貼り付けられる data:image/jpeg;base64,/9j/4AAQSkZ… URI を生成します。<img> に直接埋め込むなら Data URI、API が data:image/jpeg;base64, プレフィックスなしの生ペイロードを期待する場合は Base64 ペイロードのみ を選択してください。
Q: JPG を Base64 にエンコードすると画質は劣化する？
A: いいえ。Base64 は可逆のバイナリ ↔ テキスト変換であり、再エンコードではありません。JPEG 本来の圧縮（保存時の品質レベル、サブサンプリングモード、ハフマンテーブル）はバイト単位で保持されます。Base64 をファイルに戻すと、その SHA-256 ハッシュは元ファイルと一致します。JPEG に品質劣化があるとすれば、それはエディタから初めて保存された時点で起きたもので、Base64 がそれ以上劣化させることはありません。
Q: なぜすべての JPG Base64 文字列は <code>/9j/</code> で始まる？
A: すべての JPEG の最初の 2 バイトは Start-Of-Image マーカー FF D8 であり、続いて FF E0 (JFIF) や FF E1 (EXIF) のようなアプリケーションマーカーが来ます。最初の 3 バイト FF D8 FF を Base64 エンコードすると必ず /9j/ になります。したがって、/9j/4AAQ（JFIF）や /9j/2wC（多くのスマートフォンカメラ）で始まる文字列は確実に JPEG で、デバッグ時の有効な妥当性チェックになります。
Q: Base64 エンコードすると JPG はどれだけ大きくなる？
A: Base64 は約 33% のオーバーヘッドを加えます: size_base64 = 4 × ⌈size_bytes / 3⌉。250 KB の写真は Base64 テキストで約 340 KB になります。JPEG は既に圧縮済みのため、Base64 文字列に gzip/Brotli をかけても回収できるのは約 10% だけです。インライン画像として使う場合は、元を約 5 KB 未満（エンコード後 ≈ 6.8 KB）に保たないと、HTML/CSS を肥大化させて初回描画パフォーマンスを損ないます。
Q: HTML で JPG を Base64 として埋め込むには？
A: 完全な data URI を src 属性に貼り付けます: <img src="data:image/jpeg;base64,/9j/4AAQSkZ…" alt="cover">
HTTP リクエストは発生せず、ブラウザは Base64 をデコードして写真を即座に表示します。そのため、ファーストビューのヒーロー画像、メール署名、単一ファイル HTML レポートでインライン JPEG サムネイルがよく使われます。
Q: JavaScript、Node、Python、PHP、Go で JPG を Base64 にエンコードするには？
A:
JavaScript（ブラウザ）: new FileReader() + .readAsDataURL(jpgFile) → result が data URI
Node.js: fs.readFileSync('photo.jpg').toString('base64')
Python: base64.b64encode(open('photo.jpg','rb').read()).decode()
PHP: base64_encode(file_get_contents('photo.jpg'))
Go: base64.StdEncoding.EncodeToString(jpgBytes)
Ruby: Base64.strict_encode64(File.read('photo.jpg'))
Bash: base64 -w0 photo.jpg（GNU）または base64 -i photo.jpg -o out.txt（macOS）
Q: JPG を Base64 エンコードすると EXIF データは保持される？
A: はい、デフォルトで保持されます。EXIF セグメント（カメラ機種、日時、GPS 座標、レンズ、露出、ホワイトバランス、方向）は APP1 マーカーとして JPEG 内に格納されています。Base64 はビット単位の変換なのでマーカーはそのまま残り、画像をデコードして戻せば EXIF はまったく変わりません。プライバシーが重要な場合（GPS 座標、シリアル番号）、エンコード前に exiftool -all= やブラウザ canvas の再エクスポートで EXIF を削除してください — Base64 自体は EXIF を削除しません。
Q: JPG を別ファイルではなく JPG → Base64 として使うべき場面は？
A: 次のような場合に Base64 JPEG data URI を使います:
• 画像が小さく（5 KB 未満）、ファーストペイントに重要
• 写真を JSON API ボディ、GraphQL ミューテーション、WebSocket フレームで送信する
• 外部 CDN URL に依存できない、自己完結型の HTML メール、レポート、PDF エクスポートを構築する
• 写真をデータベースの TEXT カラムにシリアライズする（BLOB が使えない場合）
画像が大きい、多くのページで再利用される、あるいは独自の長期キャッシュヘッダーが必要な場合は、通常の .jpg URL を使いましょう。
Q: JPG と JPEG — 違うフォーマット？
A: いいえ。.jpg と .jpeg は同じフォーマット（Joint Photographic Experts Group）の異なる拡張子に過ぎません。初期の Windows 8.3 ファイル名制約により 3 文字拡張子が必要で、そのため .jpg が普及しました。現代のシステムはどちらも受け付けます。MIME タイプは常に image/jpeg、Base64 data URI プレフィックスは常に data:image/jpeg;base64, — 本ツールは両方の拡張子を同一に扱います。
Q: Base64 エンコードは画像圧縮の一種？
A: いいえ — むしろ逆です。JPEG 自体は DCT + ハフマン符号化で既に圧縮されており（生のピクセルデータから 10〜20 倍縮小）、Base64 はそこから ASCII 安全性と引き換えに約 33% 大きく します。HTML 属性、JSON 文字列、メール、URL など、一部のチャネルは生バイナリを運べないため、Base64 を使う価値は依然としてあります。ただし、サイズ削減効果はまったく期待できません。実際には Base64 テキストの上から gzip/Brotli をかけることも検討してください。
Q: JPEG を URL セーフな Base64 ペイロードにエンコードして URL で使える？
A: はい — Base64url エンコーダー (RFC 4648 §5) に切り替えてください。+/ の代わりに -_ アルファベットを使い、末尾の = パディングを省略するため、クエリ文字列や JWT に安全に含められます。ただし、標準 Base64 の JPEG ペイロードは通常数百 KB あり、多くの URL 長制限（ブラウザ / サーバーにより 2〜8 KB）を超えるため、写真全体を URL エンコードするよりファイルへのリンクを貼るほうがほぼ常に良い選択です。
Q: ブラウザがメモリ不足になるまでにエンコードできる JPG のサイズは？
A: エンコードは FileReader でストリーミング的に行い、その結果に対して btoa() を呼び出します。現代のデスクトップブラウザは 100〜200 MB の入力を問題なく処理します。モバイルブラウザはメモリ圧迫の前に概ね 40 MB まで安定して処理できます。中判カメラからの RAW → JPEG 書き出しのような本当に巨大な画像の場合、サーバーサイドエンコーダーやチャンクベース処理を検討してください — 本ツールは写真が 100 MB を超えると警告を表示します。
Q: JPG → Base64 と PNG → Base64 — どちらを使うべき？
A: 写真、カメラロール、ソーシャルメディア画像、80〜90% 品質の JPEG 圧縮が許容される滑らかなグラデーションを持つ画像には JPG → Base64 を使用してください。典型的な 1080p 写真は JPEG で約 200 KB ですが、PNG では約 2 MB になります。アイコン、ロゴ、スクリーンショット、図表、透過やシャープなエッジを持つものには PNG → Base64 を使います。両者を組み合わせる例: ヒーロー写真に Base64 JPG、その上にシャープなオーバーレイアイコンとして Base64 PNG、というのは一般的なパターンです。