开发者把PDF转换器塞进浏览器：0上传、0服务器、0隐私泄露

每年有超过2.4亿张图片被上传到各类在线转换工具，其中83%的用户从未读过隐私条款。一位前端工程师花了两个周末，把这件事彻底改写了。

他的解决方案简单到让人怀疑：整个工具只有HTML+JavaScript，没有后端服务器，没有数据库，甚至没有CDN加速。

打开网页，拖入图片，导出PDF。三步完成，全程断网也能跑。

从"上传恐惧"到"本地执念"

项目作者Xyrox在GitHub自述里写得很直白：「我厌倦了把图片上传到随机网站」。这句话戳中了一个长期被忽视的痛点——在线工具的隐私黑洞。

多数图片转PDF网站的工作流程是这样的：你的文件先上传到对方服务器，转换完成后再下载回来。这个过程中，原始图片至少在三个节点留下痕迹：你的浏览器、对方的云存储、以及可能的第三方CDN日志。

Xyrox的解法堪称粗暴：用JavaScript的Canvas API直接在浏览器内存里完成图像解码和PDF封装，整个过程不触发任何网络请求。换句话说，这个网页本质上是一个伪装成网站的单机软件。

技术实现上，他选了两个关键库：PDF-LIB负责PDF文档的底层组装，Browser-image-compression处理图片预处理。两者都是纯前端方案，加起来不到500KB。

为什么大厂不做这件事

Adobe、Smallpdf、iLovePDF这些头部玩家，无一例外都采用云端架构。不是他们技术做不到，而是商业模式不允许。

云端转换能收集用户行为数据，能插入广告，能推付费会员，能在免费版里加水印和页数限制。一个完全离线、零服务器成本的工具，对这些公司而言等于自断财路。

Xyrox的项目GitHub仓库目前只有127个star，但评论区出现了有趣的群体画像：医疗从业者转病历截图、律师存证、设计师归档稿件——都是对数据敏感、又不愿折腾专业软件的人。

一位用户留言：「终于不用把孩子的疫苗记录上传到陌生网站了」。这条评论获得了47个赞。

浏览器的隐藏算力

这个项目的真正价值，在于重新激活了现代浏览器的本地计算能力。

Chrome 80+、Firefox 75+、Safari 14+都已经完整支持WebAssembly和File API，理论上可以跑任何不需要持久化存储的桌面级应用。但大多数开发者习惯了"前端调接口、后端扛计算"的分工惯性，反而让浏览器成了纯粹的展示层。

Xyrox的代码里有个细节：他故意没有使用Service Worker做离线缓存，因为"用户可能不想在任何地方留下痕迹"。这种极端的隐私优先设计，在商业化产品里几乎不可能出现。

性能方面，实测10张5MB的JPG转PDF，M1 MacBook Air耗时约3.2秒，2019年Intel款约7秒。作为对比，上传到Smallpdf再下载回来，网络通畅时也需要5-8秒——这还是忽略了隐私风险的账。

开源社区的微妙反馈

项目发布两周后，GitHub Issues区出现了两类声音。

一类是功能请求：批量重命名、OCR文字层、密码加密、数字签名。这些需求合理，但Xyrox的回复很克制：「这个工具的核心承诺是简单和隐私，每加一个功能都要重新评估信任成本。」

另一类是安全审计。有开发者指出，PDF-LIB库本身没有漏洞，但浏览器扩展可能劫持Canvas输出。Xyrox的应对是添加了一行代码检测：如果页面被嵌入iframe，直接拒绝运行。

这种"防御性编程"的思路，和主流互联网产品的"尽可能兼容"逻辑完全相反。

目前项目的唯一"服务器交互"是GitHub Pages的静态托管，连访问统计都没加。Xyrox在README里写：「我不知道有多少人用过这个工具，也不想知道。」

这种反数据驱动的姿态，在2024年的开发者圈子里显得有点复古。

如果你有一张敏感图片需要转成PDF，你会选择打开这个零上传的浏览器页面，还是继续信任那些"免费"的在线服务？