PDF 转 WebP v1.0

把 PDF 转成 WebP，真正决定输出体积的不是质量滑块，而是每一页里装的是什么内容。DocPivot 的 PDF 转 WebP 工具在浏览器里逐页渲染，再逐页判断这一页该走无损还是有损通道：文字页、表格页、线稿页走无损，输出画面与 PNG 逐位一致，体积却只有 PNG 的十分之一左右；照片页走有损，因为同一张照片页用无损编码在实测里体积会涨到 11 倍、耗时拉长到 19 倍。一份 22 页的文字文档在 150 DPI 下输出 660 KB，用时 7.4 秒，文件全程不离开你的设备。如果你要的是交给打印店或第三方软件的通用位图，PDF 转 PNG 是更稳妥的选择。

什么是 PDF 转 WebP，为什么必须逐页判断

PDF 转 WebP 是把文档的每一页渲染成一张 WebP 图片的过程，输出的是位图，不再是可选中的文字。WebP 由 Google 在 2010 年推出，同时具备有损与无损两种编码模式，这一点和只有有损模式的 JPEG、只有无损模式的 PNG 都不同。也正因为两种模式共存于同一个格式里，编码器选谁，结果差得极远。

问题出在真实文档的构成上。一份 40 页的产品手册，可能只有 3 页是实拍照片，其余 37 页是文字、表格和矢量图表。市面上绝大多数在线转换器只给你一个质量滑块，然后把这个设置套用到整份文档：调高，37 页文字被当成照片编码，体积白白膨胀，字形边缘还会出现有损压缩特有的毛边；调低，3 页照片糊成一片。无论怎么调，都有一半页面被处理错了。

DocPivot 把判断粒度从“整份文档”降到“单页”。渲染完一页，读一次像素，回答两个问题，然后再决定这一页交给哪个编码器。40 页文档就是 40 次独立判断，照片页和文字页各得其所。需要保留统一格式、方便在图库软件里批量打开的场合，可以改用 PDF 转 JPG。

DocPivot PDF 转 WebP 工具概述

核心功能

工具在本地完成解析、渲染、判断、编码四步，不调用任何服务端接口。pdf.js 负责解析文件并读出页面尺寸；渲染阶段按 DPI ÷ 72 计算缩放倍数，画到一块不透明的白色画布上，任一边尺寸超过 16,384 像素就会被限制住；随后一次 getImageData 把整页像素读进内存，供后面所有判断复用；最后按判断结果调用 libwebp 的 wasm 版本或浏览器自带的 WebP 编码器。整套流程没有 API 密钥，没有上传，也没有任何账号记录。

目标用户与使用场景

最常用这套流程的是外贸独立站和跨境电商运营。产品手册、认证证书、规格书原本是 PDF，要放进网站详情页就得转成图片，而 Google 的 PageSpeed 和 LCP 指标又对图片体积极其敏感。其次是技术文档团队、需要把说明书拆成网页素材的内容运营，以及要把合同、财报、报关单页面留档为图片的法务与财务岗位。想先把整份文档瘦身再决定要不要转图片的，可以先过一遍 PDF 压缩工具。

问题与解决方案

老办法的代价是体积。同一页文字文档，浏览器画布直出的 PNG 是 338,686 字节，有损 WebP（质量 92）是 306,128 字节，几乎没省下什么；换成无损 WebP，只有 29,832 字节，画面还与原始渲染逐位相同。也就是说，选对通道，这一页从 331 KB 掉到 29 KB，画质分毫未损。22 页整份文档跑下来是 660 KB，而同样的文档在按整份统一设置的转换器上通常要好几 MB。

无损与有损的分界线：256 色是怎么来的

256 不是拍脑袋定的经验值，它是 WebP 无损模式自己的调色板上限，也是编码器内部真正切换策略的那条线。工具只是把这条线搬到了前面来用：一页的颜色数在 256 以内，无损编码能用调色板高效表达它；超过 256，这一页在编码器眼里就是连续色调图像，无损会退化成逐像素硬扛，代价急剧上升。

读一次像素之后，工具问两个问题。第一个是这一页有没有彩色，用全图扫描加提前退出的方式做，扫到第一个彩色像素就停——所以一条 2 像素宽的彩色分隔线，或者脚注里一个红色的字，都不会被漏掉。第二个是这一页有多少种不同颜色，用抽样统计，一旦越过 256 就立即停手，不做无谓的计算。有彩色的有损页交给 wasm 编码器，纯灰度的有损页交给浏览器自带编码器，后者在同样输出下快 4 倍。

阈值刻意压得偏低，因为两种误判的代价并不对等。一页满版彩色图表可能越过 256 色被送进有损通道，结果是文件比它本该有的大一些，但看上去仍然正确；反过来，一页照片被送进无损通道，实测体积是 374 KB 对 33 KB，耗时是 1,956 毫秒对 101 毫秒——11 倍体积、19 倍时间。既然一定要犯错，就犯便宜的那个。想反向验证某一页的颜色构成，把单张图片丢给 PNG 转 WebP 对比编码结果是最快的办法。

主要优势

• 逐页选编码器：照片页和文字页在同一份文档里各走各的通道，不用为了迁就其中一类而牺牲另一类。
• 文字页是真无损：输出与未编码的渲染结果逐位一致，实测已验证，体积约为等价 PNG 的九分之一到十一分之一。
• 全程本地处理：合同、身份证扫描件、内部财报不上传任何服务器，页面关掉数据就没了。
• 分辨率写成像素：四档 DPI 都直接标出 A4 与 Letter 的实际输出像素，不用转换完再回来量。
• 灰度页走快车道：黑白扫描件用浏览器原生编码器，同样的输出快 4 倍。
• 没有页数上限和水印：不限页数、不注册、不加水印，200 页的文档和 2 页的一样跑。
• 不推荐无用的下游步骤：结果面板只给出转换和调整尺寸的入口，不推销压缩，因为这些文件出编码器时已经是该格式能给的最小体积。如果你的原始素材本来就是散图而不是 PDF，用 图片压缩工具 才有意义；整站图片资源的取舍则可以参考 PDF 网页优化工具 的思路。

核心功能

• 逐页编码判断：每一页独立决定无损或有损，判断依据是实测像素而非文件类型猜测。
• 页面管理：导出前可以旋转、删除、重新排序，或者只保留指定的几页，渲染器在导出时读取这份页面清单。批量调整页面朝向也可以先用 PDF 旋转工具 处理。
• 四档分辨率：96、150、300、600 DPI，覆盖屏幕预览到高精度打印稿。
• 尺寸保护：缩放后任一边超过 16,384 像素会被限制，避免超长页面在 600 DPI 下把浏览器内存吃光。
• 不透明白底画布：渲染时关闭 alpha 通道并填白，页面被当作纸张处理，不会出现半透明区域发黑的问题。
• 彩色全扫描：颜色检测走全图扫描加提前退出，细到 2 像素的彩色元素也能被识别出来。
• 双编码器调度：彩色有损页与全部无损页用 libwebp 的 wasm 版本，灰度有损页用浏览器原生编码器。
• 零填充命名：输出文件名按页码补零，在文件管理器里天然按页序排列。
• 打包方式：多页输出为仅存储模式的 ZIP，不做二次压缩，避免对已压缩数据做无用功；单页直接给出裸文件。
• 质量设置的边界：质量参数只对走有损通道的页面生效，无损页面完全忽略它。如果你要的其实是可复制的文字而不是图片，应该改用 PDF 转文本工具；只需要挑出其中几页的场景，配合 PDF 删除页面工具 更省事。

使用方法

1. 打开文件。把 PDF 拖进页面，pdf.js 在本地完成解析，页面尺寸随即显示在面板上。
2. 整理页面。需要的话旋转、删页、调序，或勾选只保留其中几页；多份文档想一次处理完，先用 PDF 合并工具 拼成一份再来。
3. 选择分辨率。网页素材选 150 DPI，打印稿选 300 DPI，面板会同步显示对应的输出像素。
4. 开始导出。工具逐页渲染、判断、编码，无损页会明显慢于有损页，这是正常的。
5. 取回文件。单页直接下载，多页得到一个按页码排序的 ZIP 包。

分辨率对照表，以及 96 DPI 反而更大的原因

注意第一行：96 DPI 的文件比 150 DPI 更大。这不是笔误。分辨率低的时候，字形抗锯齿会把每个笔画摊到更多的中间灰阶上，而中间灰阶正是无损编码器最难压的东西——像素少了，但颜色种类多了，后者赢了。所以工具不会假定“降低 DPI 就一定得到更小的文件”，这也是它把每一档的实测体积摆出来的原因。这是一页文档的实测值，不是普遍规律，但足以说明凭直觉调 DPI 未必划算。需要在导出后再改尺寸的话，图片尺寸调整工具 可以直接接手。

什么时候该用这个工具

当你的目标是把文档内容放到网页上，并且在意加载速度时，PDF 转 WebP 是当前性价比最高的路径。以下几类场景收益最明显。

• 独立站产品页：把规格书、认证文件转成网页配图，同时压住 LCP 指标。
• 电商详情页：说明书、尺码表、安装步骤直接变成可滚动的长图素材。
• 文档站与知识库：把 PDF 版手册切成逐页图片嵌入文章，文字页无损意味着截图里的代码和小字仍然清晰可读。
• 公众号与小红书图文：需要把文档页面做成图片发布，且平台对单张体积有限制。
• 内部归档：合同、发票、报关单留存为图片，本地处理避免敏感文件外传。
• 邮件与即时通讯附件：对方不方便打开 PDF 时，几十 KB 的图片比几 MB 的文档更容易送达。

反过来，如果输出要交给不确定的第三方软件、要送印刷厂，或者要在老设备上打开，就不该用 WebP。单张图片的格式互转另有更直接的入口，比如 JPG 转 WebP 和 SVG 转 WebP。

实际应用案例

外贸独立站的产品手册上架

背景：一家做工业配件的外贸独立站，要把 22 页的英文产品手册放进网站的资料下载区，同时做成可直接浏览的图片页。

操作：整份文档按 150 DPI 导出，其中 19 页是文字与线稿走无损，3 页实拍照片走有损，得到一个 660 KB 的 ZIP，用时 7.4 秒。

效果：相比按整份统一设置导出的几 MB 结果，页面图片资源体积下降一个数量级，移动端首屏时间明显改善。

跨境电商详情页的说明书切图

背景：卖家需要把多语言说明书的指定页面做成详情页长图，只要其中 6 页。

操作：导出前用“仅保留这几页”筛掉其余页面，直接得到 6 张按页码命名的图片；页数更多、需要先按语种拆开的，可以先用 PDF 拆分工具 分卷。

效果：省掉了先导出全部再手动删除的环节，文件名天然有序，上传后台时不会错位。

技术文档团队的版本归档

背景：研发团队要把每个版本的 API 手册留一份不可编辑的快照，方便日后比对。

操作：按 150 DPI 导出全部页面，文字页逐位无损，代码块里的下划线和标点不会被压糊。

效果：归档体积只有 PNG 方案的十分之一，而比对时的可信度和 PNG 一样。已经是 AVIF 素材的旧归档，可以用 AVIF 转 WebP 统一格式。

法务与财务的敏感文件留档

背景：律所需要把签署完成的合同页面转成图片存入内部系统，文件包含当事人身份信息。

操作：整个转换在浏览器内完成，不产生任何上传请求，关闭页面后本地内存即释放。

效果：流程不触发对外传输个人信息的合规审查环节，也不需要向 IT 部门申请第三方工具白名单。

与常见免费转换器的差异

兼容性与已知限制

把限制讲清楚，比多列几条优点更有用。以下几点在使用前值得知道。

• “无损”只针对走无损通道的页面。照片页仍然是有损编码，工具的副标题也只承诺体积，不承诺照片页的逐位保真。
• 分类可能判错。一页满版彩色图表可能越过 256 色被当成连续色调处理，结果是文件偏大，但显示正确。
• 无损页忽略质量设置。WebP 无损模式本身没有质量参数，面板上的滑块对这些页面不起作用。
• 无损更慢。单页 305 毫秒对 144 毫秒，整份 22 页文档约 7 秒而不是 4 秒，换来的是十分之一的体积。
• 老环境不认 WebP。Safari 14 以前的版本和 Internet Explorer 无法显示 WebP。要把图片交给不确定的软件或老设备，用 WebP 转 PNG 或 WebP 转 JPG 回退更保险。
• 低端安卓上的解码开销。WebP 解码耗时高于 JPEG，长列表里一次性加载大量高清 WebP 时要注意主线程压力，首屏小图未必值得换格式。

数据安全与合规

整个转换过程没有网络请求，文件不经过任何服务器。这对处理含个人信息的文档是硬性差别，而不是营销说法。《个人信息保护法》要求处理个人信息遵循最小必要原则，《数据安全法》对重要数据的处理和跨境流动另有规定；把合同、身份证件、员工名册上传到境外服务器做格式转换，本身就是一次对外提供行为，需要走内部审批流程。本地处理绕开了这个环节：没有上传，就没有需要说明的接收方。

需要提醒的是，转换成图片会让文字失去可搜索性，这既是好处也是代价——归档时不易被误改，检索时却查不到内容。要在图片里恢复可检索文字，得另外做识别，PDF OCR 工具 处理的正是这一步。

常见问题