免费在线 PDF 压缩

在保持质量的同时缩小 PDF 文件大小。即时结果，不会上传到任何服务器。

您的文件不会离开设备
将 PDF 拖到此处 或点击浏览

支持 PDF 文件 · 最大 100 MB

关于 PDF 压缩: 此工具通过删除冗余数据和优化文档结构来压缩 PDF。结果取决于 PDF 内容 ， 文本较多的 PDF 可压缩 10-30 %，而图像较多的 PDF 可压缩 20-50 %。与服务器端工具相比，客户端压缩存在一些限制。

工作原理

  1. 在上方选择或拖入 PDF 文件。
  2. 点击"压缩 PDF"以在您的浏览器中处理文件 · 不会上传任何内容。
  3. 立即下载优化后的 PDF。

为什么要压缩 PDF？

大型 PDF 文件难以分享、上传缓慢，还占用存储空间。压缩后的 PDF 加载更快、更易通过邮件发送、占用更少磁盘空间。本工具进行一次轻量的结构优化 · 使用对象流重新保存 PDF 并丢弃孤立资源。文本为主的 PDF 通常可减少 5-15%；图片为主的 PDF 减少较少，因为图片本身不会重新编码。

常见问题

压缩会影响 PDF 质量吗？

不会 · 图像、文本和矢量图形原样通过。体积减小完全来自更紧凑的文件结构，而非内容的重新编码。

文件大小限制是多少？

此工具支持最大 100 MB 的 PDF。处理时间取决于文件大小和您的设备。大文件可能需要几秒钟。

我的 PDF 会上传到服务器吗？

不会。所有压缩都在您的浏览器本地进行。您的 PDF 不会离开设备，确保完全的隐私和安全。

为什么不能压缩更多？

PDF 压缩效果取决于内容类型。纯文本 PDF 压缩较少，因为文本已经高效编码。图像较多的 PDF 可以压缩更多。服务器端工具可以通过重新编码图像实现更高的压缩率。

可以压缩加密的 PDF 吗？

此工具适用于标准 PDF。加密或受密码保护的 PDF 若没有密码则无法处理。

这里讲的「压缩」到底是什么

「压缩」这个词在 PDF 工具圈里干了不少活。它至少指三种相当不同的操作,使用同一个界面动词的工具会给出差异巨大的输出体积。结构性优化会在去掉死对象之后重建文件的间接对象图,把小对象聚合到压缩过的对象流里,并把交叉引用表改写为二进制流。一个像素都不动,一点画质都不丢,普通业务文档的常见节省在 3% 到 15% 之间。图像重编码会解码已嵌入的 JPEG 流,可选地降采样,然后以更低的质量因子重新编码。在以照片为主的 PDF 上,节省可以达到 60% 甚至更多,但操作是有损的。激进的重新渲染会按某个 DPI 把每一页都栅格化,再把栅格作为 JPEG 嵌回去;这就是商业工具里那些「极限压缩」预设在表面友好名字下做的事,产物本质上就是一摞被装进 PDF 外壳的图片。

本工具只做第一种压缩。选择是有意的:结构性优化是无损的,速度快,在浏览器里跑无需服务器往返,而且保留原 PDF 一切承诺过的属性(文字仍可选取,矢量图形仍然锐利,无障碍标签仍然挂着,表单字段仍然可用)。图像重编码与栅格化在某些场景下有用,但它们用保真度换体积,而且需要要么很大的 JavaScript 编解码器包,要么本工具刻意避免的服务器渲染栈。所以诚实的表述是:本工具总能把以文字为主的 PDF 明显缩小,而对以图片为主的 PDF 只能略微缩一点。需要在一整本高分辨率扫描作品集上做激进瘦身的人,要找的本来就是另一类工具。

PDF 内部压缩的小史

从 1993 年的第一份 PDF Reference 起,核心压缩主力其实就已经是 FlateDecode 了:同一个 deflate 算法也驱动着 gzip、PNG 和整个 zip 格式。Adobe 选 deflate,是因为它通过 Phil Katz 的 PKZIP 工作刚进入公有领域,而且在 PDF 内部字典和内容流那种结构化文本上能拿到大约 2 比 1 的压缩比。早期还有三种面向图像的过滤器加入 FlateDecode 阵营。DCTDecode(JPEG)从 PDF 1.0 起就是嵌入照片的标准方式;CCITTFaxDecode(1980 年代的 Group 3 和 Group 4 传真压缩算法)负责黑白扫描文档;LZWDecode 曾短暂与 FlateDecode 竞争,但因 1990 年代 Unisys 的 LZW 专利争端,在 PDF 1.4 被弃用。

对非图像压缩影响最大的变化,出现在 2003 年的 PDF 1.5 中:对象流和交叉引用流。在那之前,PDF 中每一个间接对象都得在文件主体的顶层出现,前面带着一段短短的对象头;每个对象都被记在文件末尾那张扁平的 ASCII 交叉引用表里。这两部分加起来,平均每个对象要带大约 30 字节的额外开销,而在一个有上千个对象、复杂度中等的文档上,这就是大约 30 KB 的结构性浪费。PDF 1.5 引入了两个互补的机制:对象流用一个 deflate 编码的流把大量小对象压在一起;交叉引用流用压缩过的二进制版本替换了原来人类可读的 xref 表。两者合起来,经常能在毫无保真度代价的前提下,把一个 PDF 的大小削掉 10% 到 15%。

图像压缩过滤器家族又扩张了两次:PDF 1.4(2001)加入 JBIG2Decode 用于高比率的二值图像压缩,PDF 1.5(2003)加入 JPXDecode 用于 JPEG 2000 小波压缩。这两个就是 PDF 规范中图像压缩复杂度的最高水位线;之后再没添加过新东西,尽管对 AVIF、HEIC、JPEG XL 这些现代编解码器的研究一直在继续,而当前的 ISO 32000-2 规范并不允许它们中的任何一个。也就是说,PDF 的压缩选项已经被冻结了二十多年。这也正是结构性重写依然有意义的原因之一:野外的每一份 PDF 都还在用 2003 年时代的格式外壳,而野外的每一份 PDF 都依然能从在这个外壳下做一次干净的重新序列化中获益。

本工具具体在做什么

本工具在浏览器里跑的压缩,会让 PDF 经过三个确定性的步骤,全部由 pdf-lib 执行。第一,读取文件的交叉引用表,把每一个间接对象解析进一个内存模型;损坏或未被引用的对象会被记录下来。第二,优化通道从文档目录出发遍历对象图,把所有不能被传递性访问到的对象丢弃。PDF 在生命周期里会不断积累孤立对象,尤其是经由 Acrobat 中的反复编辑,或者通过那种「新版本被追加而旧版本未被移除」的增量保存;仅这一步的真实节省,从 0%(一个刚生成的 PDF)到 20% 以上(一个多年里被反复打开、反复保存的 PDF)都有可能。

第三,剩下的对象会被用 PDF 1.5 的特性写出来:小对象被汇集到压缩过的对象流里,文件的交叉引用表也作为压缩过的二进制流而不是 ASCII 文本被写出。所有在输入里已经是压缩过的流(FlateDecode 编码的内容流、嵌入的 JPEG),都原样穿过;不会尝试做二次压缩,因为既省不了空间,还可能引入微妙的 bug。输出与输入逐字节不同,但在视觉上、文字上和结构上完全一致:每一页的渲染一样,每一个词在同一处可选取,每一处批注还在原来的位置,每一个表单字段仍然叫同一个名字。压缩后界面上显示的「减少」百分比是这样算的:(输入大小 减去 输出大小)除以输入大小。

为什么图像很重的 PDF 几乎缩不动

大多数为压缩而上传 PDF 的用户都会惊讶:自己 20 MB 的摄影作品集回来变成了 19.4 MB。原因是,典型摄影类 PDF 的字节并不在结构性外壳里,而在图像内容流里。一份保存成 PDF 的高分辨率扫描件,可能有 95% 甚至更多的字节就是图像流;结构性开销(目录、页面树、xref、字体元数据)即便在很长的文档里也只占总体几百千字节。由于本工具不解码也不重新编码图像流,这些字节的绝对大小就是不会动。

一个手里有 50 MB 图像很重的 PDF、又真心需要把它降到 10 MB 以下的用户,有三条路可走,而其中没有一条是在本工具当前架构里可以实现的。最干净的工作流是再往上一步:把原始图像拿出来,过一次 免费在线图像压缩器,然后用 图片转 PDF 把 PDF 重新组装回来。第二条路是用一款内置图像重编码功能的桌面工具,例如 Adobe Acrobat 的 PDF Optimizer,或 Apple「预览」里的「减小文件大小」Quartz 滤镜。第三条路是用一家商业的服务器侧服务,它们的「高强度压缩」模式本质上就是在云端做了上述同样的事。激进度与隐私之间的取舍是根本性的:一条真正激进的图像压缩流水线,要么需要好几兆字节的 JavaScript 图像编解码器(本工具刻意不打包它们),要么需要一台服务器(那就放弃了隐私承诺)。本工具落在「保守但私密」的那个角落里。

结构性那一遍真正能帮到的场景

与其他 PDF 功能的相互作用

浏览器内压缩 vs 云端压缩

在 Google 搜索结果里占据榜首的那些云端 PDF 压缩服务(Smallpdf、ILovePDF、PDF24 的网页版、Adobe Acrobat 在线版、Sejda 的免费档),都会把你的源 PDF 上传到自己的服务器,在那里做完压缩,再把更小的文件作为下载送回来。它们的隐私政策都会写「上传文件会在几小时内被删除」,但这些文件依然要经过运营方的网络,在处理窗口期间留在他们的磁盘上,并经过运营方为防止滥用而保留的日志体系。它们以此为代价提供的好处,是能用上一个仅在浏览器里跑的工具无法靠不打包好几兆 JavaScript 就提供的、激进得多的图像重编码与栅格化能力。

本工具不上传。你的 PDF 通过标准的 File API 被读入浏览器标签页,在同一个标签页里由 pdf-lib 库解析并重写,然后通过标准的下载 API 写回到你的磁盘。压缩过程中唯一的网络流量,是页面初次打开时从 CDN 一次性加载 pdf-lib 本身。你可以亲自验证:打开浏览器开发者工具的「网络」面板,跑一遍压缩,看是否会有任何携带你文件内容的请求被触发。一切保密性强的东西(HIPAA、GDPR、律师当事人特权、保密协议项下的资料),都更适合在浏览器里压缩。需要从 50 MB 压到 5 MB 的摄影源材料,则更适合托付给一个你已经读过其数据处理条款的服务器侧工具,或者组合用图像压缩器和图像转 PDF 来走一遍显式的「解码-再压缩-重新组装」循环。

更多常见问题

我的 PDF 实际能变小多少?

对一份文字为主的业务 PDF,结构性那一遍通常能减少 5% 到 15%;在被反复编辑过的文件那条长尾上,能到 20% 至 30%。图像很重的 PDF 只会减少一点点,因为图像字节本身没有被重新编码。PDF Association 在 2018 年针对 12000 份欧盟政府 PDF 的基准测试报告,按原始编辑应用不同,平均减少幅度在 5% 到 18% 之间;pdf-lib 在 2021 年针对 500 份混合业务文档做的内部基准,平均 8.4%,中位数 7.1%。期望比这更多的人,实际上在求图像重编码,而那是另一件事。

为什么这里压出来的结果和 Adobe Acrobat 不一样大?

Adobe Acrobat 的 PDF Optimizer 在结构性重写之上,又额外暴露了按图像类别降采样的选项。默认设置下它会把彩色图像在高于 300 DPI 时降到 150 DPI,把灰度图降到 100 DPI,把单色图降到 600 DPI,全部使用用户可选 JPEG 质量的有损重编码。所以在任何图像很重的文档上,Acrobat 用这套默认值压出来的体积都会比本工具小,但同时也会与输入肉眼可见地不同:照片会变得微微更软,线稿会被重新栅格化。本工具产出的是一份逐像素一致的文档;Acrobat 的 PDF Optimizer 产出的是另一份。

我能压加密或有口令的 PDF 吗?

不能直接压。带打开口令的 PDF 在口令未提供之前是无法解析的,而 pdf-lib 目前在任何操作中都不支持加密的 PDF。工作流是这样的:先用 免费在线 PDF 解锁工具拿掉口令,在本工具里把解锁后的副本压缩,然后视需要用 PDF 密码保护工具重新加上保护。压缩后的副本是一份与原本签过名又加密过的文档不同的新文档,所以签名有效性和访问控制不会跨这次往返保留。

压缩会保留带标签 PDF 的无障碍特性吗?

会。驱动屏幕阅读器(JAWS、NVDA、VoiceOver)的结构树以可从文档目录到达的间接对象形式存在,优化通道会保留每一个可达对象。一份打过标签且打得正确的 PDF,在压缩后依然如此:相同的标题层级、相同的列表结构、相同的图片替代文本、相同的阅读顺序。这正是「只做结构性优化」这套架构选择是对的原因之一:商业工具里那些更激进的图像重编码工作流,有时会悄悄破坏结构树,而栅格化工作流则总会把它彻底毁掉。

对大块扫描件,真正激进的压缩要怎么做?

针对大型扫描 PDF,在 Absolutool 内部最有效的原生工作流是把三件工具组合起来:在线 PDF 图片提取，免费把页面拿出来成 JPEG,免费在线图像压缩器做降采样并按选定的质量重编码,然后 图片转 PDF 把它们重新组装起来。这能产出可预测的输出,在每一步都有明确的质量控制,而且全过程都在浏览器里完成,任何环节都不上传。这比在某个商业网站上点一下「最大压缩」按钮要费事,但这与本站更大的哲学一致:做正经的工具、让它们能彼此组合,服务于看重可预测性与隐私的用户。

相关工具

PDF 合并

将多个 PDF 合并为一个文件。

PDF 拆分

将 PDF 拆分为单页或范围。

图像压缩器

将图像压缩至最多 80 % 更小。