我们的做法

四条搭建规矩

兼容性对照表

它是第一件工具动笔之前那轮核查的成果，而且带日期。浏览器一直在变：每次复核它都重新核对，从不照抄上一版。

兼容性核对于 July 30, 2026

浏览器打得开的图片格式

这一项决定了一件工具能不能显示您的文件、能不能在上面干活。这里没有的格式不是“快了”：它就是不在。

浏览器写得出来的格式

这一项决定了一件工具能把您的图片转成什么。这里的坑是无声的：浏览器写不出所要的格式时，会一声不吭地给出一个 PNG。所以我们的工具去核实结果的类型，而不是选择相信。

工具所依赖的那些浏览器能力

内存上的限制，那些真会让标签页崩溃的东西

它们没有写进任何一份标准，正因如此才有那么多转换器在手机上一声不吭地崩掉。本站每件工具都写明自己的上限，超过就干脆拒绝。

浏览器里的 PDF，以及各个库的真实状况

浏览器对一份 PDF 什么都不会做，除了把它显示出来。任何加工都需要内嵌代码，而这是本站的原则唯一允许的例外。以下是 2026 年 7 月 30 日那次核查确认的事实，以及 PDF 专区为什么在等一个决定，而不是半开着。

我们放弃了什么，为什么

• 图片里的文字识别，以及读 iPhone 的 HEIC 照片：需要的引擎有十到十五兆。网速不好的时候，为了读几个字先下十五兆，这笔账不划算。以后可以重新考虑，但绝不会悄悄改。
• 视频，任何形式的视频：浏览器里的视频转换引擎有三十兆上下。不做。
• 用人工智能抠背景：得先下载一个模型，而模型是又大又看不透的文件。不做。
• 任何天生离不开网络的东西：把链接变短、把短链接还原、查一个域名归谁、显示远程页面的预览。这些工具没法做成本地的，所以这里没有。这不是缺口，这就是这个项目的定义。
• 用地图标出照片拍摄地：那会是一个发往第三方服务器的请求，而本站一个都不发。而且它带走的正是文件里最敏感的那条信息。坐标会明明白白列出来，怎么用由您决定。
• 把 PDF 变成图片：那得把页面画出来，而画 PDF 是一整门手艺（字体、矢量、透明、色彩空间）。我们内嵌的那个库会造 PDF，不会画 PDF 的页面。网上唯一像样的渲染引擎，按它自己发布的文件量出来，单为这一件事就要 1.72 MB，而且这已经是压缩过的体积。反过来的方向，图片转 PDF，已经摆上台，而且能用。
• 给 PDF 签名：理由一样，而这一条最让人不甘心。没有渲染引擎就没法把页面显示出来；显示不出来，就没法让人把签名放在自己想放的位置。闭着眼睛按固定坐标盖上去的签名，比没有还糟。宁可留一个空位，也不出一件会毁掉文件的工具。
• 读二维码：浏览器提供的那个功能靠操作系统撑着。所以它只存在于一部分 Chromium 上，也就是 macOS、ChromeOS 和 Android；Windows 和 Linux 上没有，Firefox 从来没实现过，Safari 的实验版从 iOS 18 起就是坏的。靠它的工具，在大多数台式机访客那里根本不能用。反过来，生成二维码留在计划里：手写得出来，而且标准可以自由使用。
• 禁止打印或复制一份 PDF：格式确实允许写上这些限制，很多工具也把这些勾选框摆出来，因为看着让人安心。它们只是对阅读器提的请求：文件一打开内容就已经解密了，不理这个请求的阅读器照样打印。卖一把其实只是贴纸的锁，那正是这个网站存在的理由：不撒这种谎。
• 用麦克风录音，也就是 34 号位置里“录音笔”那一半：本站工具页面的构造，每件工具只给一个入口，一个文件、一段文字或者什么都不要，而每一条信任横幅讲的正好就是那个入口。麦克风会是第四种，得配一条自己的承诺。更重要的是，每次发布前检查本站的那台机器没有麦克风：我们没法证明一段录音不会外传，而证不了的承诺我们不发布。所以 34 号位置是“裁剪录音”，录音这件事交给您的设备，它本来就做得很好。
• 课堂计时器的投影大屏显示：我们视觉规范里最大的字号是计数块用的那一号，它当初不是为了从教室最后一排看清而画的。大屏显示会是一个全新的图形组件，而规范已经冻结；缺什么就记下来，而不是在做工具的半路上自己发明。全屏模式是有的，会铺满整个屏幕，但它不会把数字放大，页面上这一点说了两遍。这是一条需求，已记录在案，没有被埋掉。
• 随机抽取的转盘动画，理由相同：这是视觉规范里没有的组件。而且转盘并不会让抽签更公平，它只是把抽签演出来。让抽签公平的是背后用的随机源和没有偏差，工具把这两样连同算式一起显示出来：n 分之一的机会，n 的阶乘种可能顺序。
• 日期计算器里可点击的日历：我们的视觉规范没有画过日期输入框，而浏览器自带的日期框会带着它自己的边框和高度进来，落在规范之外。所以日期按国际格式输入，这有个实实在在的好处：“03/04”在半个世界指 4 月 3 日，在另外半个指 3 月 4 日。
• 日期计算器里的法定假日：各国不同，同一个国家有时各地区还不同，日期每年会变，而假日碰上周末往往还有一个逐案决定的补休。一份写死的清单十二个月内就会出错，而这个项目面向的是全世界。所以算出来的工作日一律是周一到周五，没有例外，页面上也写着这一点。
• 单位换算器里的迪多点，这是最能说明问题的一条：没有任何计量机构给它下过定义，引用它的书给出了四个不同的数值。当四份二手资料互相打架、又没有任何一手来源时，就没有什么可抄的。相比之下，网页里的点正好等于一英寸的七十二分之一，白纸黑字写在规范里。
• 给 ZIP 压缩包设密码，收发两个方向都不做：这个格式历史上的加密早在 1994 年就被一篇公开的攻击破掉了，而现代那套是私有扩展，还有好几个变体。我们会做一堆重活，换来一层没法老实说它结实的保护。安全专区里的加密工具解决的是真问题，而且它把整套做法都摆出来。

PDF 专区的几次取舍，以及凭的是什么证据

为了开出 PDF 专区，我们做了三个决定，每一个都有代价。下面把它们连同核查真正查实的东西一起写出来。一个不说自己凭什么的取舍不叫取舍，那叫意见。

内嵌的库

本店的规矩是零依赖。当手写代码不合情理时，可以破例内嵌一个库：绝不从第三方服务器加载，版本一律钉死，许可证核查过，大小写在这里。

对照表的来源

下面是编这张对照表时用到的公开来源，好让这次核查不靠我们也能重做一遍。它们没有逐行挂钩：表里本来就没有这条关联，与其让人以为有，不如直说。

• 图片格式指南（MDN）
  https://developer.mozilla.org/en-US/docs/Web/Media/Guides/Formats/Image_types
• 从画布写出 WebP：支持情况一览表
  https://caniuse.com/mdn-api_htmlcanvaselement_toblob_type_parameter_webp
• canvas.toBlob（MDN）
  https://developer.mozilla.org/en-US/docs/Web/API/HTMLCanvasElement/toBlob
• 原生压缩：到处都可用（web.dev）
  https://web.dev/blog/compressionstreams
• 原生加密（MDN）
  https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto
• 条码识别（MDN）
  https://developer.mozilla.org/en-US/docs/Web/API/Barcode_Detection_API
• “另存为”窗口（MDN）
  https://developer.mozilla.org/en-US/docs/Web/API/Window/showSaveFilePicker
• 离屏处理（MDN）
  https://developer.mozilla.org/en-US/docs/Web/API/OffscreenCanvas
• 各格式里的 EXIF 方向标签
  https://zpl.fi/exif-orientation-in-different-formats/
• WebP 容器（规范）
  https://developers.google.com/speed/webp/docs/riff_container
• pdf-lib：这个库会做什么
  https://github.com/Hopding/pdf-lib
• iOS 上画布的最大面积
  https://pqina.nl/blog/canvas-area-exceeds-the-maximum-limit/
• 把画布序列化成文件（HTML 标准）
  https://html.spec.whatwg.org/multipage/canvas.html
• 密码的存储：推荐参数
  https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html
• 从密码生成密钥（NIST SP 800-132）
  https://csrc.nist.gov/pubs/sp/800/132/final
• 用浏览器的接口做加密
  https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto/encrypt
• 流式加密：一直开着的那个诉求
  https://github.com/w3c/webcrypto/issues/73
• 原生压缩：支持情况一览表
  https://caniuse.com/mdn-api_compressionstream_compressionstream
• ZIP 文件格式（规范）
  https://pkware.cachefly.net/webdocs/APPNOTE/APPNOTE-6.3.2.TXT
• ICO 图标格式，以及它里面的 PNG
  https://devblogs.microsoft.com/oldnewthing/20101022-00/?p=12473
• 那个 PDF 库还在维护吗？（讨论）
  https://github.com/Hopding/pdf-lib/discussions/1631
• 那个 PDF 库仍在维护的延续版本
  https://github.com/cantoo-scribe/pdf-lib
• 条码识别：所谓“真实支持”是什么意思
  https://developer.chrome.com/docs/capabilities/shape-detection
• Adobe 对 ISO 32000 标准的补充：扩展级别 3 的 AESV3 加密
  https://www.loc.gov/preservation/digital/formats/fdd/fdd000313.shtml
• pdf.js：PDF 的 AES-256 两个加密修订的代码
  https://github.com/mozilla/pdf.js/blob/master/src/core/crypto.js
• PDFium：Chrome 引擎里的 AES-256 密码校验
  https://github.com/chromium/pdfium/blob/main/core/fpdfapi/parser/cpdf_security_handler.cpp
• ISO 32000-1 标准：对象流（§7.5.7）与图像（§8.9.5）
  https://opensource.adobe.com/dc-acrobat-sdk-docs/pdfstandards/PDF32000_2008.pdf
• qpdf：为什么修订 5 只该用来测试兼容性
  https://qpdf.readthedocs.io/en/stable/encryption.html