如何将 JPG 调整为低于 100 KB？

一张 538.6 KB 照片的质量阶梯，为什么滑块在 131 KB 停滞，以及为什么裁剪像素是实际影响字节预算的杠杆。

August 9, 2026 · Updated August 21, 2026

上传表单显示最大 100 KB。你的照片是 538.6 KB。反应是抓住质量滑块向左拖动，但对于一张大照片，这个反应不会让你达到目标。我们取了一个文件并进行了整个阶梯测试：3840x2160 的 texture.jpg，磁盘上为 538.6 KB。即使在质量 30 时，它也只能达到 131 KB，而那时图片已经明显变得模糊。

实际上控制 JPEG 大小的数字是像素数量。基线 JPEG 以 8x8 块编码图像，因此将两个维度都减半会留下四分之一的块来存储。如果你只有滑块，你将在这个大小的文件上停滞在大约 131 KB。下面的每个数字都来自我们自己的压缩器和调整器，在浏览器标签中运行。没有上传步骤需要等待。

为什么质量滑块无法让我达到 100 KB？

这是阶梯，每次使用相同的源文件，在手动模式下运行 图像压缩器。智能模式选择每个编码器的默认设置，JPEG 和 WebP 为 80，AVIF 为 63，PNG 为无损。

滑块 60 降低了 216.8 KB。最后一段，从 60 降到 30，放弃了很多可见细节，换来了 81.4 KB。3840x2160 的照片有 8.3 百万像素需要描述，而在这个大小下，描述它们所需的字节数有一个下限。这个下限是真实存在的。

为什么质量 30 其实不是 30？

这一点让人困惑，我们来解释。当源是 JPEG 时，我们的压缩器从文件的前 64 KB 中读取量化表，并估算保存时的质量。然后你的滑块会缩放这个估算值。以质量 60 保存的照片，滑块在 80 时，编码为 48。重新缩放阻止第二次传递声称像素无法提供的质量，因为以 90 重新编码质量 60 的文件只是花费字节描述已经固化的损坏。底层编码器是 MozJPEG。还有一件值得知道的事：压缩会剥离每一块元数据，包括 EXIF、GPS、ICC 配置文件和嵌入缩略图。方向信息得以保留。

为什么滑块旁边的估算值与结果不匹配？

因为这是一个曲线，而不是编码。面板在任何操作之前打印该数字，仅基于两个因素：你的文件大小和滑块位置。它是原始字节乘以滑块除以 100，再提高到 1.8 的幂。它从未看到你图像的像素，也不知道上面的重新缩放，因此在质量 60 的例子中，它打印了一个 80 的数字，而编码器即将使用 48。

在同一个 538.6 KB 测试文件上，差距很大，并且在范围内改变方向。在滑块 90 时，面板预测 445.5 KB，而实际为 347.8 KB，偏高 28%。在滑块 30 时，它预测 61.7 KB，而实际为 131 KB，偏低 53%。如果你瞄准 100 KB 限制，请再读一遍第二个：估算值显示你超出了 38 KB，而编码器即将错过 31 KB。结果卡上的 KB 是唯一值得采取行动的数字。在调色板 PNG 模式下根本没有估算，面板在其位置打印警告。

我如何才能将 JPG 调整到低于 100 KB？

首先裁剪像素，然后压缩。打开 调整器，使用百分比预设，分别为 25%、50% 和 75%。50% 将 3840x2160 降至 1920x1080，像素减少四分之一。25% 将其降至 960x540，减少为 1/16。还有 15 个社交预设，具有固定尺寸，从 1080x1080 的 Instagram 正方形到 2560x1440 的 YouTube 横幅，以及一个精确像素模式，具有覆盖、包含和拉伸适配模式。这个精确像素模式就是如何 在不压扁脸的情况下输入 600 x 600 护照正方形。如果你从 4K 照片瞄准 100 KB，请从 25% 开始，然后逐步调整。

关于调整器，有两件事值得先知道。PNG 输出保持无损，其他格式默认以质量 90 重新编码，因此通过两个工具的 JPEG 被编码了两次。动画源输出为一帧静态图像。当压缩器的输出大于你输入的文件时，它会将原始文件原封不动地返回。

WebP 或 AVIF 会更快吗？

仔细阅读那张表。在相同的滑块位置 80，JPEG 产生了最小的文件，而 AVIF 产生了最大的，这看起来是反常的，直到你记住上面的重新缩放。JPEG 的 80 是针对源自身估算质量进行缩放的，因此它实际上并不是 80，而 WebP 和 AVIF 则字面理解这个数字。将它们降至 AVIF 的智能默认值 63，现代编码器就领先了：WebP 为 200.6 KB，AVIF 为 186.9 KB。在 3840x2160 的情况下，两者仍然距离 100 KB 还有很长的路要走，这正是重点。AVIF 在这台机器上的编码时间约为 10 到 11 秒，而 JPEG 和 WebP 则瞬间返回，并且 浏览器支持 还比较年轻。我们的 JPG 转 WebP 路径锁定为 4:2:0 色度，因此硬红边缘会稍微柔和一些。

如果我的文件是带透明度的 PNG 呢？

完全不同的杠杆。我们将 alpha.png，900x606 和 942.4 KB 的真实 alpha 通道，通过两种 PNG 模式进行处理。“无压缩”选项是 oxipng，在 3 级下完全无损，返回 383.9 KB，减少了 59%，每个像素都保持完整。“更小文件大小”选项运行 libimagequant，将图像减少为调色板，返回 98.3 KB。这是减少了 90%，并且在不触及尺寸的情况下清除了 100 KB 的预算。调色板会带来平滑的渐变，因此在交付之前检查一下天空或柔和的阴影。透明度在两种模式下都得以保留。请求 JPEG 输出时，alpha 通道会消失，合成到白色上。

我可以通过裁剪来达到 100 KB 吗？

部分可以。裁剪会去除像素，因此会去除字节。我们的 裁剪工具 每次处理一个文件，最大 10 MB，并提供八个纵横比预设以及一个自定义的宽高比。没有输入目标宽度的字段，因此你无法瞄准确切的输出大小，并且每个有损格式的裁剪都会以硬编码的质量 92 重新编码。GIF 返回为单帧 PNG。为了达到字节预算，调整器的百分比预设提供了更直接的控制。

这些操作会上传我的照片吗？

不会。此应用没有 API 路由和服务器操作，它唯一的网络请求是对其自身资产和 WASM 编解码器的同源获取。你的文件在同一标签中被解码到画布上，然后再次通过 WASM 编码。此类别中的大多数其他工具则工作相反：你的图像会传输到他们的服务器，并在他们的存储中停留，直到保留计时器触发。这就是我们的 隐私页面 所阐明的区别。这也是为什么这里的批量限制为 10 个文件和 50 MB，因为你自己的 CPU 正在完成工作。正因为这个限制， 一个包含 300 个文件的文件夹不是浏览器工作。