用十六进制编辑器打开任意 .jpg 文件。前两个字节：
FF D8
这是**图像开始（Start of Image）**标记。每个 JPEG 文件都以它开头。地球上每个 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 成立，将最优秀的思路合并为一份单一草案。经过六年打磨，该标准于 1992 年以 ISO/IEC 10918-1 发布。
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。以 JPEG 质量 90、4:2:0 子采样保存后，降到约 3.5 MB。这是 10:1 的缩减，只有在放大时才能看到可见的质量损失。
它到底多有损？
损伤并非均匀分布。
| 质量 | 典型大小（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）：色度子采样将颜色抹过锐利边界。
真正的杀手是代际损失（generation loss）。打开一张 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 与源文件几乎无法区分。
- 生态惯性：内容管理系统、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 是一个 33 岁的妥协。它用颜色分辨率、高频纹理和数值精度换取了 1990 年代让数码摄影得以实现的文件大小。伪影已被充分理解。代际损失真实存在。绿色漂移也会发生。
然而 JPEG 依然存续，原因与 QWERTY 键盘相同：迁移成本高于忍受现状的痛苦。
实际的推进路径是分层的：
- 保留高质量母版。将原始文件以 PNG、TIFF 或质量 95+ JPEG 归档。永远不要从质量 75 的网页导出文件重新编辑。
- 动态提供现代格式。使用能根据浏览器
Accept头协商 AVIF、WebP 或 JPEG XL 的 CDN 或图像服务。只存一份母版；让边缘节点按需转换。 - 不要批量重编码 JPEG。每一代都在销毁数据。如果你需要更小的文件，从母版重新编码，而不是从另一个 JPEG 重编码。
JPEG 不会突然死亡。它会像 GIF 一样逐渐淡出：仍然到处支持，仍然在每个查看器中打开，但越来越多地被用更少字节和更少伪影完成同样工作的格式超越。不同之处在于，这一次，替代格式真的在赢。
