> JPG | encode | data-uri <
// 将 JPG / JPEG 照片编码为 Base64 字符串与数据 URI — 保留 EXIF、DCT 系数与画质
将 JPG / JPEG 拖放到此处或点击选择
点击浏览 JPG / JPEG 文件
逐位一致
您的 JPEG 绝不会被重压缩。DCT 系数、量化表与 EXIF 元数据均原样往返保留。
本地处理
照片通过 FileReader + btoa() 在浏览器中编码。无上传、无服务器、不会对您的图像字节进行任何分析。
即贴即用
复制一个符合标准的 data:image/jpeg;base64,… URI，直接用于 HTML、CSS、邮件或 JSON API 负载。
// 常见问题 — JPG 转 BASE64
Q: 什么是 JPG 转 Base64 编码？
A: 它使用 Base64 字母表（RFC 4648）将 .jpg / .jpeg 文件的二进制字节重写为 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>，选择 数据 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 的前两个字节都是图像开始标记 FF D8，紧跟着是诸如 FF E0（JFIF）或 FF E1（EXIF）的应用标记。将前 3 个字节 FF D8 FF 进行 Base64 编码时，总会得到 /9j/。因此以 /9j/4AAQ（JFIF）或 /9j/2wC（许多智能手机相机）开头的字符串可以可靠地判定为 JPEG — 这在调试时非常有用。
Q: JPG 经 Base64 编码后会大多少？
A: Base64 大约增加 33% 的开销：size_base64 = 4 × ⌈size_bytes / 3⌉。一张 250 KB 的照片编码后约为 340 KB 的文本。由于 JPEG 已经压缩过，gzip/Brotli 对 Base64 字符串只能再压回约 10%。做内联图片时建议将原图控制在约 5 KB 以下（编码后约 6.8 KB），否则会撑大 HTML/CSS 并影响首绘性能。
Q: 如何在 HTML 中以 Base64 形式嵌入 JPG？
A: 将完整的数据 URI 粘贴到 src 属性中： <img src="data:image/jpeg;base64,/9j/4AAQSkZ…" alt="cover">
不会产生 HTTP 请求 — 浏览器解码 Base64 并立即显示照片。这也是为什么在首屏 hero 区、邮件签名和单文件 HTML 报告中经常内联 JPEG 缩略图。
Q: 如何在 JavaScript、Node、Python、PHP、Go 中将 JPG 编码为 Base64？
A:
JavaScript（浏览器）： new FileReader() + .readAsDataURL(jpgFile) → result 即数据 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 本身不会替您去掉它。
Q: 什么时候应该使用 JPG → Base64，而不是把 JPG 作为独立文件？
A: 以下场景适合使用 Base64 JPEG 数据 URI：
• 图片较小（< 5 KB）且对首绘关键
• 需要在 JSON API 正文、GraphQL 变更或 WebSocket 帧中传送照片
• 构建自包含的 HTML 邮件、报告或 PDF 导出，无法依赖外部 CDN URL
• 把照片序列化到数据库 TEXT 字段（无法使用 BLOB）中
当图片体积较大、需在多页面复用或需要独立的长期缓存头时，使用普通 .jpg URL 更合适。
Q: JPG 与 JPEG — 它们是不同的格式吗？
A: 不是。.jpg 与 .jpeg 只是同一种格式（Joint Photographic Experts Group）的不同扩展名。早期 Windows 8.3 文件名限制要求 3 个字母的扩展名，所以 .jpg 流行起来。现代系统两者都接受。MIME 类型始终是 image/jpeg，Base64 数据 URI 前缀始终是 data:image/jpeg;base64, — 本工具对这两种扩展名一视同仁。
Q: Base64 编码算是一种图像压缩吗？
A: 不是 — 恰恰相反。JPEG 本身已经通过 DCT + 霍夫曼编码进行了压缩（相对原始像素数据可缩小 10–20 倍）。然后 Base64 会让文件再次变大约 33%，以换取 ASCII 安全性。您仍应使用 Base64，因为有些通道（HTML 属性、JSON 字符串、邮件、URL）无法承载原始二进制。但不要指望借此减小体积；事实上，总建议在 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。图标、Logo、截图、图表以及任何带透明度或锐利边缘的内容适合 PNG → Base64。两者混用：hero 照片用 Base64 JPG，外加锐利覆盖图标用 Base64 PNG，这是很常见的模式。