PDF 转 Base64 转换器
最大 10 MB。不会上传任何内容——文件始终不离开你的设备。
可用于 <img src> 属性或 CSS 的 url()。
不含 data: 前缀——适用于 JSON 载荷和 API。
在页面中显示该文档。若要做下载链接，请把 data URI 放进带 download 属性的 <a href> 中。
您的文件始终保密
这项转换完全在你的浏览器中完成。图片不会被上传，因此你在这里编码的任何内容都不会到达我们的服务器或其他任何人手中。
关于 PDF 转 Base64
把图片编码成 Base64，通常是一个网页性能决策。把 PDF 编码成 Base64，几乎从来不是。人们转换文档，是因为对面的某个系统——电子签名服务、开票系统、税务机关、消息接口——只接受以 JSON 字段中的文本形式提交的文件。这是一个传输问题，规则完全不同。
如何将 PDF 转换为 Base64
- 1 把 .pdf 文件拖到上传区域。
- 2 看一眼体积那一行：编码后的字符串大约大三分之一，而你的 API 限额正是对这个数字生效的。
- 3 要放进 JSON 字段就复制原始字符串；若需要显示或链接该文档，则复制 data URI。
它到底是用来做什么的
JSON 没有办法承载原始字节。如果一个 API 要求把文档放在 JSON 主体里，文档就必须先变成字符串，而 Base64 正是做这件事的标准方式。当你把合同发给电子签名服务商、把发票提交到政府门户、通过事务邮件接口附加文件，或把文档推入消息队列时，都会遇到它。每种情况下的替代方案都是 multipart 上传——许多 API 支持它，也有一些不支持。
不要把 PDF 内联进网页
本页的 embed 片段是为那种你确实需要它的少见场合准备的——一个自包含的 HTML 文件、一份离线报告、一次邮件预览。它并不是发布文档的好办法。通过链接提供的 PDF 可以流式传输：阅读器先下载前几页并显示出来，其余部分随后到达。data URI 做不到，因为浏览器必须先把整个解码后的文档保存在内存里，阅读器才能看到其中的第一个字节。对于几兆字节的文件，这会把即时预览变成卡顿，而且页面也无法与文档分开缓存。
要盯的是请求体上限，而不是文件大小
一个 4 MB 的 PDF 会变成约 5.4 MB 的文本，而你的 API 衡量的正是这个更大的数字。几兆字节的请求体上限很常见，所以一个作为文件看起来绰绰有余的文档，编码之后可能就会被拒绝。撞到这堵墙时，答案通常不是把 PDF 压得更狠：先看看该 API 是否提供单独的文件上传端点或预签名 URL，因为它们接收原始字节，完全绕开这 33%。本页面的上限是 10 MB，这已经超出大多数 JSON 端点所能接受的范围。