把任意 .jpg 文件丢进十六进制编辑器，最开头的两个字节一定是：
FF D8
这叫**图像开始（Start of Image）**标记，每个 JPEG 文件都从这里开始，每个解码器也都先找它。后面的字节会告诉解码器：这是哪种 JPEG 变体、使用什么色彩空间、像素数据从哪儿开始。这个格式比万维网还老，但 2025 年 Web Almanac 的数据显示，它仍承载着现代网络上约 57% 的图像流量。
催生 JPEG 的存储危机
1986 年，一张 640 × 480 的原始灰度图像要占 307 KB 磁盘空间；同分辨率彩色图像则要 921 KB。当时一块 20 MB 硬盘售价数百美元，1.44 MB 软盘是主流交换介质，一张未压缩的照片就能塞满大半张盘。
问题摆在那里：需要一种针对连续色调图像（照片，而非线条图）的标准压缩格式。多个团队几乎同时在做这件事。**联合图像专家小组（Joint Photographic Experts Group）**于 1986 年由 ISO/IEC 和 ITU-T 成立，把各家的思路整合成一份草案。六年打磨后，标准以 ISO/IEC 10918-1 的名义在 1992 年发布。
JPEG 从一开始就不是要做唯一图像格式。它只负责一件事：把照片缩到能存、能传。它通过按特定顺序丢弃信息来完成这件事。
JPEG 为何压缩得这么好
JPEG 压缩不是单一算法，而是一条流水线。每一级都在剔除人类视觉系统最不易察觉的数据。
1. 色彩空间转换（RGB → YCbCr）
屏幕最终显示 RGB，但 JPEG 存储的是 YCbCr。Y 通道承载亮度（luminance），Cb 和 Cr 承载色度（蓝色差和红色差）。这之所以重要，是因为人眼有约 250 万个锥状细胞负责亮度，而负责颜色的只有 10 万个。我们对亮度细节的感知远强于颜色细节。
2. 色度子采样（Chroma subsampling）
大多数 JPEG 使用 4:2:0 子采样：每 4 个亮度样本对应 1 个 Cb 样本和 1 个 Cr 样本。也就是说，色度通道的存储分辨率只有亮度通道的 四分之一。对于一张 4000 × 3000 的图像，Y 平面保持全分辨率，Cb 和 Cr 平面各缩到 2000 × 1500。在真正的压缩开始之前，原始数据就已经被砍掉约 50%，而大多数观看者根本不会察觉。
3. 离散余弦变换（DCT）
图像被切分为 8 × 8 像素块。每个块经过 DCT，将空间数据（像素值）转换为频率数据（数值在块内的变化速度），结果是一个 8 × 8 的系数矩阵。左上角的值是 DC 系数，即该块的平均亮度；其余 63 个是 AC 系数，代表越来越高频的细节。
高频系数对应头发、草叶、噪点这类精细纹理；低频系数则对应天空、墙面、肤色这类大面积形状。
4. 量化（Quantization）
有损压缩发生在这里。JPEG 对每个 DCT 块应用一张量化表。这张表是另一个 8 × 8 的除数矩阵，每个 DCT 系数被对应的量化值除，并四舍五入到最近的整数。
标准量化表对高频系数打击最重：
16 11 10 16 24 40 51 61
12 12 14 19 26 58 60 55
14 13 16 24 40 57 69 56
14 17 22 29 51 87 80 62
18 22 37 56 68 109 103 77
24 35 55 64 81 104 113 92
49 64 78 87 103 121 120 101
72 92 95 98 112 100 103 99
一个高频系数，比如 7，被 121 除并四舍五入为 0。它消失了，不可逆。解码器再也看不到它。这就是有损压缩：数据被销毁，而非仅仅重新编码。
在质量 90 时，量化值被更小的缩放因子除；在质量 50 时，缩放因子更大，更多系数归零，文件更小，图像也更柔和。
5. 熵编码（Entropy coding）
量化后，剩余的系数经过 zig-zag 扫描、游程编码，再用 Huffman 编码压缩。这一阶段是无损的，只是把已经被破坏的数据打包得更紧凑。
一张 1200 万像素的未压缩 RGB 图像占 36 MB；用质量 90、4:2:0 子采样存成 JPEG 后，大约只剩 3.5 MB。体积降到原来的十分之一，只有放大看才会发现质量损失。
JPEG 的损伤有多大
损伤并非均匀分布。
| 质量 | 典型大小（1200 万像素） | 视觉影响 |
|---|---|---|
| 95+ | ~8 MB | 几乎不可见；适合归档 |
| 90 | ~3.5 MB | 轻微柔化；相机默认标准 |
| 75 | ~1.8 MB | 精细细节可见模糊；网页默认 |
| 50 | ~1.0 MB | 100% 放大时块效应明显 |
| 30 | ~600 KB | 色带、蚊状噪点，无法用于印刷 |
随着质量下降，会出现三种明显的伪影：
- 块效应（Blocking）：可见的 8 × 8 网格边缘，尤其在平滑渐变（如天空）中。
- 振铃（Ringing）：高对比度边缘周围出现振荡光晕（如文字与背景交界处）。
- 颜色溢出（Color bleeding）：色度子采样将颜色抹过锐利边界。
比单次压缩更麻烦的是代际损失。打开一张 JPEG，编辑它，再存为 JPEG。每次保存都会重新跑完整条流水线：RGB → YCbCr → 子采样 → DCT → 量化。四舍五入误差不断累积。10 代之后，图像看起来像水彩画；50 代之后，面目全非。
绿色偏移与其他重压缩怪象
反复重存 JPEG，你可能会注意到色温在漂移。有些图像泛出淡淡的绿色，有些则偏向洋红。原因藏在色度通道里。
JPEG 以降低的分辨率存储 Cb 和 Cr，并对它们进行激进的量化。每次保存都会在这两个通道引入舍入误差。转回 RGB 时使用的是这个矩阵：
R = Y + 1.402 × (Cr - 128)
G = Y - 0.344136 × (Cb - 128) - 0.714136 × (Cr - 128)
B = Y + 1.772 × (Cb - 128)
注意，绿色由 Cb 和 Cr 共同计算。当反复量化使 Cb 向上偏移、Cr 向下偏移哪怕一个量化步长时，G 通道就会漂移。Cb 的正偏压会把绿色往下推，Cr 的负偏压会把绿色往上推。这种交互并不对称，因为系数 -0.344136 和 -0.714136 的幅值不同。某些图像区域会因此慢慢积出绿色，尤其是原始色度值已经接近量化边界的地方。
这不是必然发生的效果。它取决于编码器的量化表、子采样模式以及图像内容。但它是真实的、可复现的，也是专业工作流避免重存 JPEG 的原因之一。
为什么全世界还在用 JPEG
JPEG 流行起来，并不是因为它完美，而是因为它足够好，而且哪儿都能打开。
基础 JPEG 专利（由 Forgent Networks 持有）于 2006 年到期，格式本身免版税。每台相机、手机、打印机和浏览器都在芯片或高度优化的 C 代码里内置了 JPEG 解码器，渲染成本几乎为零。对社交媒体、新闻网站和邮件附件来说，手机屏幕上质量 75 的 JPEG 与源文件几乎看不出区别。再加上 CMS、CDN、图像库和遗留档案都认 JPEG，替换它不仅需要更好的格式，还需要足够的理由去迁移 PB 级的现有资产。
那些想取代它的格式
陆续出现过不少想取代 JPEG 的格式，但没有一种真正完成替代。
| 格式 | 有损 | 无损 | 透明 | 动画 | 最大位深 | 核心优势 |
|---|---|---|---|---|---|---|
| JPEG | 是 | 否 | 否 | 否 | 8-bit | 通用支持 |
| PNG | 否 | 是 | 是 | 否 | 16-bit | 完美无损，支持透明 |
| WebP | 是 | 是 | 是 | 是 | 8-bit | 比 JPEG 小 25–35%，浏览器原生支持 |
| HEIC | 是 | 是 | 是 | 是 | 16-bit | 比 JPEG 小约 50%，Apple 默认格式 |
| AVIF | 是 | 是 | 是 | 是 | 12-bit | 当今最佳压缩率，免版税 |
| JPEG XL | 是 | 是 | 是 | 是 | 32-bit | 无损 JPEG 重压缩，渐进式解码 |
PNG 解决的是无损问题，但对照片产生的文件比 JPEG 大 5–10 倍。它统治了截图、UI 素材和图形领域。
WebP 由 Google 在 2010 年推出，体积上击败 JPEG，还增加了透明和动画支持。它现已内置在所有主流浏览器中。2025 年 Web Almanac 显示，WebP 在 LCP 图像中占比 11%，高于 2024 年的 7%。它是当下稳妥的升级路径。
HEIC 随 Apple 在 2017 年开始使用，在 ISOBMFF 容器里采用 HEVC 压缩。它比 JPEG 小约 40–50%，且单文件可存多图。它统治了 Apple 生态，在其他地方则停滞不前，原因在于 HEVC 专利池。
AVIF 由 AOM 在 2019 年发布，源自 AV1 视频。它在所有广泛支持的格式中实现了最佳压缩比，同等质量下比 WebP 小约 30%。缺点是解码速度。在移动设备上，AVIF 图像的渲染时间可能比 JPEG 长 2–3 倍，消耗电量并延迟最大内容绘制（LCP）。
JPEG XL（ISO/IEC 18181，2021）的技术指标比上述格式都好看。它比 JPEG 小 50–60%，解码速度也快。它支持渐进式解码，仅下载约 1% 的文件后即可显示可用图像。最重要的是，它可以对现有 JPEG 进行无损重压缩，节省约 20% 的体积，并能逐位恢复原始文件。没有其他格式能做到这一点。
现状
JPEG XL 的浏览器之路走得并不顺。Google 于 2021 年在 Chrome 中加入了实验性支持，随后在 2022 年 10 月 31 日将其移除，即"万圣节决定"。官方理由是：相对于现有格式的增量收益不足。反对声来得很快，该 Chromium issue 成为项目历史上获得 star 数第二高的议题。Google 被指责是在保护 AVIF，后者与 Google 参与联合创立的 Alliance for Open Media 深度绑定。
2025 年底，Chromium 改变了方向。一个新的 Rust 解码器（jxl-rs）进入了 Chrome Canary。Chrome 145 于 2026 年 2 月发布，在标志（flag）后支持了 JPEG XL。Safari 自 2023 年起已支持它。Firefox Nightly 正在集成同一个 Rust 解码器。JPEG XL 尚未默认启用，但它已回到代码库中。
与此同时，AVIF 在 2026 年是最务实的选择。浏览器支持广泛，编码器在改进。Cloudinary 和 Cloudflare 都通过 Accept 头协商自动提供 AVIF。根据 CoreDash 数据，提供 AVIF 或 WebP 的页面 median LCP 良好率达到 81%，而仅提供 JPEG 的页面为 64%。
三十年后，JPEG 仍在
JPEG 已经 33 岁了。它靠牺牲颜色分辨率、高频纹理和数值精度，换来了 1990 年代数码摄影得以存活的文件大小。它的伪影、代际损失、绿色漂移，都已经被研究得很清楚。
然而 JPEG 仍在，原因很现实：把它全部换掉所花的成本，比继续忍受它更高。
更现实的策略是分层次处理。保留高质量母版，把原始文件以 PNG、TIFF 或质量 95+ JPEG 归档，永远不要从质量 75 的网页导出文件重新编辑。对外分发时，让 CDN 或图像服务根据浏览器 Accept 头协商 AVIF、WebP 或 JPEG XL，只存一份母版，边缘节点按需转换。不要批量重编码 JPEG，每一代都在销毁数据；需要更小的文件就从母版重新编码，而不是从另一个 JPEG 重编码。
JPEG 不会突然消失。它更可能像 GIF 那样慢慢淡出：依旧到处能打开，依旧被每个查看器支持，但越来越多完成同样工作的格式，会用更少的字节和更少的伪影把它挤到边缘。
