手机扫描的合同发给对方
扫描 App 导出的 20 页合同有 40 MB,邮件附件超限。平衡档压缩后约 5–6 MB,屏幕阅读无差别;对方若需打印,打印档约 12 MB 也在多数邮箱限制内。
使用指南
PDF 压缩把文件的每一页在浏览器里渲染成一张位图,按你选的清晰度重新编码为 JPEG,再把这些 JPEG 拼回一份页面尺寸不变的新 PDF——文件不上传,结果通常只有原件的几分之一到几十分之一。
更新于 2026-09-09复核:owner4 个来源约 12 分钟读完
PDF 压缩把文件的每一页在浏览器里渲染成一张位图,按你选的清晰度重新编码为 JPEG,再把这些 JPEG 拼回一份页面尺寸不变的新 PDF——文件不上传,结果通常只有原件的几分之一到几十分之一。
它最适合的对象是扫描件和以图片为主的文件:手机扫描 App 生成的 PDF、复印机直出的合同、相机拍的票据。这类文件每页本来就是一张大图,重新按合理的分辨率和质量编码,体积往往能减少 70% 以上,而屏幕上几乎看不出差别。
它不适合以文字为主、体积本就不大的文件。整页图像化意味着原本几 KB 的矢量文字会变成一张一两百 KB 的图片,文件不但不会变小,还会失去「可选中、可搜索、可复制」的特性。工具面板里的黄色提示说的正是这件事,本文原理一节会解释为什么。
三个档位对应三组固定参数:屏幕(72 DPI,JPEG 质量 0.55)、平衡(110 DPI,0.70,默认)、打印(150 DPI,0.82)。压缩前先决定文件的去处——发微信看用屏幕档,存档兼顾打印用平衡或打印档——比事后反复试更省时间。
scan_压缩_省87%.pdf;若输出比原件还大,文件名里就没有「省」字——这是在提醒你这份文件不适合图像化压缩。结果卡可「再次下载」或「加入工作区继续处理」。一份 6 页的扫描件,每页是 2480×3508 像素(相当于 A4 纸 300 DPI)的 JPEG,原件 2.41 MB。三个档位的实际结果:
档位 渲染分辨率 每页像素 每页 JPEG 6 页合计 节省
屏幕 72 DPI · 质量 0.55 595×841 ≈ 20 KB 120 KB 95%
平衡 110 DPI · 质量 0.70 909×1286 ≈ 51 KB 302 KB 87%
打印 150 DPI · 质量 0.82 1240×1753 ≈ 109 KB 642 KB 73%
作为对照,一份 12 页、只有矢量文字的合同(11.7 KB)用平衡档压缩后变成 1.65 MB——每页都成了一张约 137 KB 的图片,文字也不再能选中。

PDF 本身已经是一种压缩格式:文字用字体轮廓描述,图片内部通常已是 JPEG 或 Flate 压缩。所谓「PDF 压缩」在不同工具里可能指三类完全不同的事:
本工具采用第 3 种。理解这一点,就能预判它在什么文件上有效、在什么文件上适得其反。
PDF 的页面尺寸用**点(pt)**度量,1 pt = 1/72 英寸,A4 纸是 595.28 × 841.89 pt。渲染时工具用 pdf.js 把页面画到画布上,缩放比例是 DPI ÷ 72:
这一步是重采样:原扫描件如果是 300 DPI,输出 110 DPI 就丢掉了约 87% 的像素((110/300)² ≈ 0.13)。像素少了,JPEG 编码前的数据就少了,这是体积下降的第一个来源,也是不可逆的。
渲染时页面上的所有元素——文字、矢量图形、图片、批注外观——都被合成到同一张位图里,背景铺成白色(JPEG 不支持透明)。
位图随后经浏览器的 JPEG 编码器编码,质量参数(0–1)来自画布的 toBlob() 接口。JPEG 把图像切成 8×8 的块,做离散余弦变换后按量化表舍弃高频细节:质量越低,量化步长越大,保留的高频越少,文件越小,边缘附近的「振铃」与块状伪影越明显。
三档的质量值 0.55 / 0.70 / 0.82 是为「扫描文字仍可读」调过的:低于 0.5 时笔画边缘会出现明显噪点,高于 0.85 后体积增长很快而肉眼收益很小。编码细节(是否做色度抽样、用哪套量化表)由浏览器决定,因此同一档位在不同浏览器里输出体积可能相差一两成。
一页矢量文字在 PDF 里的成本是:字体一次性嵌入(几十 KB,全文档共用)+ 每个字符几个字节的定位指令。一页 A4 密排文字可能只有 2–5 KB。
同一页图像化后,110 DPI 就是 1.17 兆像素。文字边缘是 JPEG 最不擅长的高频内容,即使质量 0.7 也要 100–150 KB 才能把黑白边缘编得像样。于是 12 页合同从 11.7 KB 涨到 1.65 MB,涨幅超过 100 倍。这不是 bug,是图像化方法的固有性质:它只在「原件每页本来就是一张更大的图」时才有收益。
输出是一个全新的 PDF:每页一个与原页视觉尺寸相同的空页,上面铺一张覆盖整页的 JPEG(PDF 里叫 DCTDecode 滤镜的图像对象)。原文件的字体、矢量、文本层、书签、表单、链接、元数据都不会进入新文件。在工作台里插入的空白页保持为矢量空页,不会被图像化;扫描件里原有的空白页则和其他页一样会被渲染成图片。
因为新文件是纯图片,任何 PDF 阅读器都能打开,兼容性极好;但「查找」功能会一无所获,屏幕朗读器也读不到任何文字。
扫描 App 导出的 20 页合同有 40 MB,邮件附件超限。平衡档压缩后约 5–6 MB,屏幕阅读无差别;对方若需打印,打印档约 12 MB 也在多数邮箱限制内。
几十张发票拍照生成的 PDF 只需留档备查。屏幕档能把体积压到原来的 5% 左右,文字仍可辨认。
网申系统要求单个附件不超过 5 MB,而学历证明扫描件有 18 MB。选平衡档,若仍超限再试屏幕档;最后核对文件名里的节省比例。
老师把扫描版讲义发到班级群,学生大多在手机上看。屏幕档压缩后加载快、流量省;需要打印的同学可以另取原件。
因为原文件以矢量文字为主,本来就很小。图像化会把每页变成一张一两百 KB 的图片。这类文件不需要压缩;若确实要减小体积,问题往往出在几张内嵌大图上,请用「PDF 提取图片」检查。
先想清楚去向:只在屏幕上看选屏幕档;不确定就选平衡档;可能打印选打印档。三档之间体积大致是 1 : 2.5 : 5,清晰度随之递增。
不会。新文件每页的尺寸与原页(含你在工作台里做的旋转)完全一致,只是内容变成了图片。
目前压缩作用于当前文件的全部页面。可以先用「PDF 拆分」把需要压缩的部分分出来,压缩后再「PDF 合并」回去。
不能直接恢复。图像化是不可逆的。如果需要文字,只能对压缩件做 OCR,识别精度取决于档位——屏幕档的 72 DPI 对 OCR 来说通常太低。
每页都要渲染成大位图再编码,页数多、原件分辨率高时耗时明显;手机上尤甚。可以先用「PDF 拆分」分段处理,或换到桌面浏览器。
压缩的每一步——用 pdf.js 渲染页面、用画布编码 JPEG、用 pdf-lib 重建文件——都在你的浏览器里进行,文件不会上传到任何服务器。中间产生的位图只存在于内存,关闭页面后释放。断网状态下同样可用。
HTMLCanvasElement.toBlob()——quality 参数的定义与取值范围:https://developer.mozilla.org/zh-CN/docs/Web/API/HTMLCanvasElement/toBlob(访问日期:2026-09-08)getViewport({ scale }) 语义(scale = 1 对应 72 DPI):https://mozilla.github.io/pdf.js/(访问日期:2026-09-08)更新于 2026-09-09 · 复核:owner
图像化重编码减小体积,屏幕 / 平衡 / 打印三档
所有处理均在你的浏览器本地完成,文件不会上传到任何服务器