免费在线图像压缩器

将 JPEG、PNG 和 WebP 图像压缩至最多小 80%。即时获得结果，不会上传到任何服务器。

您的文件永不离开您的设备

将图像拖放到此处 或点击浏览

支持 JPEG、PNG、WebP · 每个最多 50 MB

设置

质量： 60%

最大宽度：

格式：

工作原理

在上方选择或拖放一张或多张图像。
调整质量滑块（值越低，文件越小，压缩率越高）。
图像在您的浏览器中进行压缩 · 不会上传任何内容。
单独或一次性下载压缩后的图像。

为什么要压缩图像？

大图像会拖慢网站速度，增加跳出率，并影响 Google 搜索排名。压缩图像可将文件大小减少 50-80%，几乎看不出质量损失。这对网页开发者、博主、电商店主以及任何在线发布内容的人都至关重要。较小的图像还能节省移动设备的带宽，并改善 Core Web Vitals 评分。

「图像压缩」到底意味着什么

图像压缩涵盖两种本质不同却共用一个名字的操作。有损压缩由 JPEG 和有损 WebP 使用，丢弃人眼不太可能察觉的图像数据（阴影中细微的灰阶过渡、高频噪声、利用人眼对色度与亮度感知差异的色度子采样）。输出比输入小，但无法逐位重建。无损压缩由 PNG、GIF、TIFF-LZW 和无损 WebP 使用，使用 DEFLATE（LZ77 + 哈夫曼）等算法把精确的像素数据编码得更紧凑。输出更小，解压时能按字节重现原始数据。哪种合适取决于图像：照片极其适合有损，因为其内容充满纹理，眼睛无法在像素层面追踪；徽标、截图和具有锐利颜色过渡的图形则要求无损，因为每一个像素都是有意为之。

JPEG 压缩器中的质量设置（本工具上的滑块，从 10 到 100%）控制的是 DCT 步骤之后应用的量化表。质量为 100 时，量化表几乎不对任何频率系数取整；质量为 50 时，它们会很激进地取整。质量更高意味着文件更大、细节更精；质量更低意味着文件更小、平面区域出现可见的块状伪影。默认的 60% 处于网页用途的甜蜜点：通常文件大小可减少 50 到 80%，在典型屏幕上看不出变化。打印或大屏工作可推到 80-90%。缩略图或邮件友好版本则 30-50% 就够。

对于 PNG，「质量」滑块在通常意义上并不适用，因为 PNG 一直是无损的。本工具对 PNG 输入实际做的事情，是跑一遍比大多数创作软件（Photoshop、Affinity、Sketch）默认使用的更强的 DEFLATE 压缩；这通常能在不改变任何像素的情况下榨出 5 到 25% 的文件体积。Format 下拉框还允许把 PNG 转换为 JPEG 或 WebP，这用无损换得了更小的文件，但 JPEG 输出会失去透明度，而 WebP（对于照片内容）会失去无损保证。Max Width 选项在压缩过程中调整图像尺寸：一张 4000 像素宽的照片缩小到 1920 像素，原始像素数节省了 75%，这一步发生在任何压缩之前，并能与质量降低叠加。

这个工具的底层原理

压缩引擎是 Donald Wong（GitHub：Donaldcwl/browser-image-compression，MIT 许可证）的 browser-image-compression。这是一个纯 JavaScript 库，压缩后约 95 KB，封装了浏览器的三种原语：用于读取字节的 File API，用于解码、调整大小和重新编码 JPEG/WebP 图像的 Canvas API（或在可用时的 OffscreenCanvas），以及用于处理 PNG 而不经过 Canvas 的 UZIP（一个小型 DEFLATE 库）。当你拖入图像时，浏览器把字节交给这个库；库会根据输入格式和请求的输出选择路径。

对于 JPEG 和 WebP 输入，路径是：解码到画布、按需调整到所配置的最大宽度，然后调用 canvas.toBlob(mimeType, 质量/100)。浏览器内置的 JPEG 或 WebP 编码器执行真正的量化和哈夫曼编码。质量是你的滑块值除以 100，作为第二个参数传入。对于保持为 PNG 的 PNG 输入，库完全跳过 Canvas（经由 Canvas 会无意义地重新栅格化无损数据），转而直接对 PNG 文件的 IDAT 块运行 UZIP，并采取最大压缩力度。这就是为什么 PNG 到 PNG 的压缩在这里真正无损：像素数据从未被解码和重新编码，只是 DEFLATE 外壳被拧得更紧。

当 OffscreenCanvas 受支持时（现代的 Chrome、Edge、Safari、Firefox），繁重的解码-调整-编码工作运行在 Web Worker 内，使主界面线程保持响应。你可以拖入 20 张照片的批次，并在每一张被处理时继续滚动页面。在较旧的浏览器上，库回退到主线程，仍能工作，但会在大任务期间阻塞页面。整条管线在你的标签页内运行。库在首次访问时从 CDN 加载一次（压缩后约 95 KB），之后被缓存。文件内容永远不会离开浏览器。在压缩一个批次时打开开发者工具的网络标签，你会看到一次性的库获取，但此外什么都没有。

图像压缩格式简史

DCT，1972-1974。 Nasir Ahmed 在 1972 年提出离散余弦变换作为图像压缩方法；正式算法在 1974 年与 T. Natarajan 和 K. R. Rao 一同发表。这一个数学变换坐落在当今世界上每一个 JPEG、MPEG 和 H.26x 视频文件的底层。
JPEG，1992。 Joint Photographic Experts Group（成立于 1986 年）于 1992 年将 JPEG 标准化为 ITU-T T.81 / ISO/IEC 10918-1。8x8 的 DCT 块、带可选色度子采样的 YCbCr 色彩空间、为人眼视觉调校的量化表。让照片丰富的网络成为可能的格式。
PNG，1996。 在 Unisys 的 LZW 专利主张威胁开放网络之后，PNG 作为 RFC 2083 在 IETF 创建以取代 GIF。DEFLATE（LZ77 + 哈夫曼）压缩、始终无损、完整的 alpha 透明度、没有专利负担。第三版规范（W3C，2023 年）正式加入了 HDR、APNG 动画和 EXIF 元数据。
WebP，2010。 Google 发布 WebP 作为基于 VP8 视频编解码器帧内编码的静态图像格式。在可比视觉质量下，有损 WebP 比 JPEG 小 25-34%；无损 WebP 比 PNG 小约 26%。普及花了十年时间；到 2026 年，全球超过 96% 的浏览器支持它。
AVIF，2019。 Alliance for Open Media 发布 AVIF，作为 AV1 视频编解码器的静态图像变体。在可比质量下大约比 JPEG 小 50%。浏览器支持现在超过 95%，但日常创作工具（Photoshop、Word、Slack）中的编码器支持仍滞后。Squoosh 和 ImageMagick 今天可以产出 AVIF；大多数相机和手机不行。
HEIC，2017。 Apple 把基于 HEIF/H.265 的 HEIC 作为 iPhone 的默认照片格式。约为等价 JPEG 一半大小。受专利费约束，因此在开放网络上很少使用。大多数在线上传工具（包括本工具）只接受经过桌面端转换为 JPEG 后的 HEIC；这种转换正是把手机照片发送给非 Apple 用户的日常流程。

支持的格式

JPEG · 最适合照片和复杂图像。有损压缩，质量可调。
PNG · 最适合图形、徽标和带透明度的图像。
WebP · Google 推出的现代格式，在同等质量下文件比 JPEG/PNG 更小。

现实世界中的压缩工作流

博客和网站图片。 一张直接来自手机的 2 MB JPEG 与一张 250 KB 的压缩后 JPEG：在典型屏幕上对人眼来说完全相同，但更小的文件加载大约快 8 倍。Core Web Vitals（LCP）分数直接改善。大多数含有多张照片的页面看到的 Lighthouse 性能最大提升，来自图片压缩，而不是 JavaScript 或 CSS 优化。
社交媒体上传。 Instagram、Twitter、Facebook、LinkedIn 都会在上传时用各自的算法重新压缩图像。先压缩可以让你掌控被牺牲的东西；上传原始照片则把这些选择交给平台，常常带有可见的劣化。
邮件附件。 大多数服务商对每封邮件附件设上限 25 MB（Gmail、Outlook、Apple Mail）。把一组照片从约 50 MB 压到约 10 MB，可以在一封邮件里发送全部内容，而不用拆成多封或转为云分享链接。
电商产品图。 拥有数百或上千张照片的商品目录会带来高昂的 CDN 带宽账单和缓慢的页面加载。压缩整个图片库可以同时降低两者。Shopify、Etsy 和 Amazon 卖家普遍在上传前压缩，以降低托管成本并改善搜索排名。
重截图的作品集。 UI 设计作品集大量使用 PNG，因为截图中有锐利的颜色过渡，JPEG 的伪影会很显眼。PNG-到-PNG 通过更紧凑的 DEFLATE 通常能节省 10-20%，且像素零变化，这对需要保持快速又不能牺牲渲染质量的设计师作品集很有用。
归档缩小。 一张 12 兆像素的手机照片，对仅会在屏幕上观看的家庭共享相册来说过头了。缩到 4 兆像素并以 80% 质量保存：结果在所有会看到它的设备上都看起来一致，而归档大小变成了原来的五分之一。原始文件仍安全地保存在源磁盘上；压缩版本进入分享或备份。

常见陷阱及其含义

多次重新压缩 JPEG 会让它劣化。 每次保存 JPEG 都会重新跑一次 DCT 量化步骤，丢失你永远无法找回的细节。第一次的损失很微妙，到第三或第四次就明显了。始终从你手中质量最高的源（相机的原始文件、设计工具的导出）开始压缩，而不是从上周保存的已经被压缩过的 JPEG 开始。如果需要调整，请保留一份 PNG 或 TIFF 的母版副本。
PNG 转 JPEG 会丢失透明度。 JPEG 在格式规范里根本没有 alpha 通道。将 PNG 转换为 JPEG 时，任何透明像素都会变成纯白（或编码器替换的颜色）。对于徽标、图标、带有透明背景的截图，或任何带有 alpha 通道的图形，请留在 PNG 或改用 WebP，二者都能保留透明度。
JPEG 转 PNG 会让文件变更大。 PNG 的 DEFLATE 压缩擅长处理平滑渐变和大块纯色区域，对 JPEG 压缩留下的高频噪声模式则非常糟糕。将 JPEG 转换为 PNG 通常会让文件大小翻倍或翻三倍，而画质毫无改善。如果你需要从一张 JPEG 得到无损，那已经太迟了：原始信息已经消失。这种转换只有在你确实需要 PNG 的透明度或某个不接受 JPEG 的工具时才有意义。
EXIF 元数据默认会被剥离。 browser-image-compression 库在重新压缩时默认丢弃 EXIF 元数据（相机信息、GPS 坐标、拍摄日期、ICC 色彩配置文件）。对于网络用途来说通常是好事（GPS 坐标泄漏是真实的隐私问题）。对要保留元数据归档照片的摄影师来说，本工具就不合适；请使用具备 EXIF 处理能力的桌面压缩器，如 ImageOptim 或带显式「保留元数据」选项的 jpegtran。
色彩配置文件可能保留不下来。 嵌入的 ICC 色彩配置文件（sRGB、Adobe RGB、ProPhoto）告诉显示器如何解读像素值。基于 Canvas 的重新编码可能会丢弃嵌入的配置文件并把输出标记为 sRGB。对于普通屏幕用途这没问题，因为几乎所有东西本来就是 sRGB。但对于印刷前期工作、有色彩管理的照片准备或宽色域交付件，请使用色彩感知工具（Photoshop 的「导出为」、Affinity、RawTherapee），它们会显式保留配置文件数据。
非常大的图像可能让移动浏览器标签崩溃。 把图像解码到 Canvas 所需的内存与其尺寸成正比：一张 24 兆像素的照片（6000x4000 像素）仅 RGBA 像素缓冲区就需要约 96 MB，外加编码器的工作内存。4 GB RAM 的移动设备可能在编码完成前就被操作系统终止该标签。请缩小输入或使用桌面浏览器处理非常大的照片。

隐私：图像留在你的设备上

每一个云端图像压缩器（TinyPNG、Compressor.io、Optimizilla、Smallpdf 的图像工具、Pixlr 的压缩端点，以及众多「在线压缩图像」服务）都会把你的文件上传到运营商的服务器，运行其压缩算法，再把更小的图像作为下载返回。隐私上的影响并不轻：照片往往包含可识别的内容：人脸、背景里可见的地址、内部 UI 或机密文件的截图、儿童照片、私人空间内拍摄的照片。多数运营商发布的隐私政策都承诺一两小时内删除上传内容并加密传输，较大者（TinyPNG、Smallpdf）持有 ISO/IEC 27001 认证。他们有强烈的商业动机去履行这些政策。但「一小时内删除」不等于「从未看过」。在那一小时里，图像内容驻留在运营商的基础设施中，任何具有相应权限的进程或人都可访问，且按所适用的保留策略出现在日志和备份里。

这个压缩器从不上传任何内容。browser-image-compression 库完全在你的标签页里运行；图像字节由 File API 读取、在 JavaScript 中处理（如果 OffscreenCanvas 可用，则在 Web Worker 中处理），压缩后的输出以可下载的 Blob 形式返回到同一个标签页。你可以在压缩一个批次之前打开浏览器开发者工具的网络标签来验证没有上传：不会有任何包含你图像内容的请求发出。唯一的网络流量是首次访问时一次性从 CDN 获取库（约 95 KB），随后库被缓存。在页面加载后开飞行模式，压缩器仍能在本地文件上工作。对于包含任何敏感内容的照片（人脸、地点、内部截图），浏览器侧的代价显然值得。

什么时候另一个工具才是合适的选择

在脚本化流水线里批量处理超过 500 张图像。 请使用 Node.js 里的 sharp（事实上的服务器侧图像库）、命令行的 ImageMagick 或 GraphicsMagick，或 Python 的 Pillow。这些工具能处理数千个文件而不受浏览器内存限制，并能从 CI 任务、部署钩子或 cron 任务里运行。
需要严格的无损保证且可以按位验证。 对于 PNG 到 PNG，本工具确实是无损的，因为 UZIP 不会触碰像素数据。但对于要求加密验证的工作流（医学影像、法律证据），请使用桌面工具如 ImageMagick，附加显式的 `-define png:compression-level=9`，并对解码后的像素数据做 SHA-256 校验。
印刷级别的色彩配置文件保留。 印刷前期工作（保留 ICC 配置文件、屏幕打样、CMYK 输出）请使用 Adobe Photoshop、Affinity Photo 或 RawTherapee。基于浏览器的压缩无法保证色彩管理工作流，因为 Canvas 在 sRGB 下运行，可能会丢弃嵌入的配置文件数据。
需要 AVIF 输出以获得下一代压缩。 截至 2026 年，browser-image-compression 不输出 AVIF。要在浏览器里做 AVIF 编码，请使用 Squoosh（也是 Google，同样在客户端）；要在命令行里做 AVIF，请使用 libavif 的 avifenc。AVIF 在可比质量下产出的文件大约比 JPEG 小 50%，但编码器计算开销很大（比 JPEG 编码慢 10 倍）。

常见问题

压缩会降低图像质量吗？

在默认 60% 质量下，大多数图像看起来与原始图像几乎相同，但体积却小了 50-80%。调整滑块以找到适合您需求的平衡点。

是否有文件大小限制？

每张图像最大可达 50 MB。由于处理在您的浏览器中进行，非常大的文件可能需要一些时间，具体取决于您的设备。

我的图像会上传到服务器吗？

不会。所有压缩均在您的浏览器本地完成。您的图像不会离开您的设备，完全私密且安全。

我应该使用哪个质量设置？

对于网页用途，60-70% 是理想的。对于打印或作品集，请尝试 80-90%。对于最大压缩（缩略图、电子邮件），30-50% 效果很好。