接口限制 1MB，Base64 图片最多能有多大？把 JSON 和前缀一起算进去

**如果 1MB 限制针对整个 JSON 请求体，不能上传接近 1MB 的原图再转 Base64。**标准带补位的 Base64 会把每 3 个原始字节编码为 4 个字符，外面还可能有 Data URL 前缀、字段名和其他参数。

本例把上限明确设为 1,000,000 字节，不代表任何真实服务的限制。先查清接口按什么计数，再倒推原图预算；不要把“通常增大三分之一”当成足够精确的边界校验。

先确认上限约束的是哪一层

同样写着“图片最大 1MB”，实际合同可能不同：

被限制的对象	应检查的量
解码后的单张图片文件	原始图片字节数
Base64 字符串字段	编码后字段长度，是否包含前缀
整个 JSON 请求体	最终序列化文本的字节数
多张图片总量	所有字段或解码文件的合计，按实际合同
压缩传输后的请求	对应压缩阶段的体积，另看服务解压后限制

有些服务同时设置多层上限。某一层通过，并不代表整个请求被接受。HTTP 头、表单边界是否计入，也要按具体网关或服务规则确认，不能自动加到本文的 JSON 算例里。

MB 与 MiB 也不相同。若文档给出的只是模糊单位，应先确认精确字节定义，不靠反复碰上限猜测。

标准 Base64 长度可以精确计算

依据 MDN 的 Base64 说明，每个 Base64 字符表示 6 个比特。对于不换行、保留标准补位符的编码，n 个二进制字节对应：

Base64 长度 B = 4 × ceil(n / 3)

ceil 表示向上取整。这个公式计算的是编码长度，不是图片解码后的像素内存，也不是网络压缩后的实际流量。

如果接口使用去掉补位符的变体、额外转义或自动插入换行，应按它的实际格式重新计算。不要一边使用标准公式，一边删除末尾字符去凑上限。

一个包含前缀的完整请求体算例

假设接口只接收一个 image 字段，其值为 JPEG Data URL，JSON 不包含额外空格、换行或其他字段。下面展示的是编码尚未插入时的外壳，不是有效图片请求：

{"image":"data:image/jpeg;base64,"}

按 UTF-8 编码，这个固定外壳共 35 字节：包括 JSON 结构、字段名以及 Data URL 前缀。标准 Base64 字符都是 ASCII，在这种没有额外转义的序列化方式下，一个字符占一个 UTF-8 字节。

若整个请求体最多 L 字节、固定开销为 H，则需要满足：

4 × ceil(n / 3) + H ≤ L

当 L 不小于 H 时，该假设下的最大原图字节数为：

n最大 = 3 × floor((L - H) / 4)

floor 表示向下取整。把 L=1,000,000、H=35 代入，得到 749,973 字节。实际代回比较：

假设原始字节数	Base64 长度	加外壳后的 JSON 字节数	是否在上限内
749,973	999,964	999,999	是
749,974	999,968	1,000,003	否

多一个原始字节，可能让编码长度跨到下一组 4 字符。这是编码与序列化算例，已用本地合成字节复算，不是用真实 JPEG 上传接口的测试。

增加一个字段，749,973 就不再是通用答案

若请求还包含提示词、文件名、模型选项或第二张图，固定开销和图片总长度都会变化。尤其包含中文或其他非 ASCII 字符时，字符串字符数不等于 UTF-8 字节数；不同序列化设置还可能将字符转义。

更稳妥的办法是使用真实请求结构生成最终 JSON，然后计算该文本编码为 UTF-8 后的字节数。不要只量 Base64 字段，也不要只看编辑器显示的字符总数。

多图请求需要对每张图片分别计算 4 × ceil(n / 3)，再加其他内容。不能把所有原图字节先相加再只做一次取整，因为每个独立字段都有自己的编码末组。

若程序会额外转义斜杠或插入换行，也应以实际序列化结果为准。本文的 35 字节只适用于给出的精确外壳。

先减源文件，再重新编码，不要剪 Base64 尾巴

发现超限后，优先从原图准备新的合适副本，再生成编码。如果允许改变尺寸或格式，可以按合同处理；如果像素固定，则应先考虑允许的编码优化，并核对清晰度。

图叮格式转换与压缩可用于准备候选图片；具体做法见“固定像素压到目标体积”。不能为过上限删掉 Base64 后半段，那会破坏编码或文件内容。

Data URL 与纯 Base64 也不能随意互换。MDN 的 data URL 说明给出 data:[媒体类型][;base64],数据 的结构。接口要哪一种，就提交哪一种；删除前缀只能节省少量外壳，不能代替必要的图片压缩。

使用工具时，仍要核对真实请求

截至 2026-09，图叮图片 Base64 互转公开说明支持本地文件、截图和允许跨域读取的图片链接，可将编码还原为图片；处理在本机进行，转换、复制与下载时需要登录。

它适合准备编码和检查数据，不代替目标接口的完整请求校验。远程链接读取还受 CORS 限制，不应为了取到字节把私有链接交给不明代理；Base64 也不是加密，不会隐藏图片内容。

若接口明确支持文件上传或受控资源 URL，可以比较这些方案，但不能据此绕过服务的尺寸、内容或权限限制。只支持 Base64 的接口，则按其规则准备合规数据。

对网页正式图片，是否采用内嵌编码还需要考虑独立缓存与响应式资源交付，不能因为少了一个图片请求就认为整体更快。

最终检查对象应是即将发送的完整请求体。把图片、编码和外层协议分开计数，才能解释“原图不大，为什么请求还是超限”。

参考来源

• MDN：Base64 编码与长度增长
• MDN：data URL 结构
• 图叮：图片 Base64 互转
• 图叮：格式转换与压缩