Base64 末尾的 = 号是什么？

补位符。Base64 以 3 字节为一组编码，长度不是 3 的倍数时用 = 补齐到 4 字符的整数倍：余 1 字节补 ==，余 2 字节补 =。它不携带数据，只保证长度可整除，解析器据此还原原始长度。

URL-safe Base64 和标准 Base64 有什么区别？

标准 Base64 用 + 和 /，在 URL 里是特殊字符；URL-safe 变体把它们换成 - 和 _，并且通常省略尾部 =。JWT（JSON Web Token）用的就是 URL-safe 变体。两者可以无损互转（-↔+、_↔/、补回 =）。

Base64 和 URL 编码（百分号编码）分别什么时候用？

URL 编码只转义 URL 语法不允许的字符（空格、中文、& 等），原文大部分可读，用于 query 参数和路径；Base64 把任意字节整体重编成 64 个安全字符，完全不可读，用于二进制数据走文本通道（Data URL、邮件附件、JWT）。

为什么我的 Base64 解出来是乱码？

多数情况是编码侧不是 UTF-8：老系统用 latin1 或 GBK 编码中文再转 Base64，UTF-8 解码自然乱码。确认发送方编码为 UTF-8 后重编即可；纯二进制数据（如图片）解成文本本来就是乱码，应解成文件保存。

发布于 2026-09-27 · CATAITO

Base64 与 URL 编码指南

Q: Base64 为什么会让数据变大 33%？

Base64 把每 3 个字节（24 位）重排成 4 个字符（每个字符承载 6 位），数据位没有损失但载体变多了：4 字符替代 3 字节，体积固定膨胀 4/3 ≈ 133%。加上换行符（MIME 场景）可能更多。

Base64 和 URL 编码无处不在：图片 Data URL、JWT、邮件附件、链接参数。本文讲清原理、变体与选型。附免费在线编解码工具。

Base64 的 3 字节→4 字符原理
URL-safe 变体
常见应用：Data URL / JWT / 邮件
URL 编码（百分号编码）
怎么选
常见问题

Base64 的 3 字节→4 字符原理

Base64 解决的问题是：让任意二进制数据安全地通过只认文本的通道。它把 64 个字符（A–Z、a–z、0–9、+、/）编成一个「字母表」，每 3 个字节（24 位）拆成 4 组、各 6 位，每组映射到字母表里的一个字符：

字节数据:  0xE4  0xB8  0xAD        （"中" 的 UTF-8 前三字节）
二进制:    11100100 10111000 10101101
6 位分组:  111001 | 001011 | 100010 | 101101
查表:      5        11       34       45
Base64:    5        L        i        t   →  "5Lit"

两件衍生物：

= 补位：输入长度不是 3 的倍数时补 = 凑整（余 1 补 ==，余 2 补 =）
体积 +33%：3 字节变 4 字符，固定膨胀 4/3

想动手验证，用本站 Base64 编解码工具输入「中」看输出 5Lit。

URL-safe 变体

标准 Base64 的 + 和 / 在 URL 里有语法含义，放进链接会被误解。URL-safe 变体做两个替换：

标准	URL-safe
`+`	`-`
`/`	`_`
尾部 `=`	通常省略

两者无损互转。看到「既没有 + 也没有 / 的 Base64」，基本就是 URL-safe 变体。

常见应用：Data URL / JWT / 邮件

Data URL：data:image/png;base64,iVBOR... 把图片直接内嵌进 HTML/CSS，省一次请求，代价是 HTML 变大且无法单独缓存
JWT：三段式 header.payload.signature，前两段是 URL-safe Base64 编码的 JSON，所以你能在 jwt.io 直接「看懂」你的 token——也说明 JWT 默认不加密，敏感信息别放 payload
邮件 MIME：附件二进制走 Base64 才能在 SMTP 文本协议里传输

URL 编码（百分号编码）

URL 只允许一小部分字符出现，其余都要转义成 %XX 字节序列：

空格:    → %20
中:      → %E4%B8%AD   （UTF-8 的三个字节各转一个 %XX）
&:       → %26         （在参数值里要转义，否则被当成参数分隔符）

它和 Base64 的根本区别：URL 编码逐字符转义、原文大多可读；Base64 整体重编、完全不可读。

怎么选

场景	选什么
链接参数、路径里的中文/特殊字符	URL 编码
图片内嵌进 HTML/CSS	Base64（Data URL）
token / 签名放 URL	URL-safe Base64
邮件附件	Base64（MIME 规定）
「加密」敏感信息	都不是——用真正的加密

常见问题

Q：Base64 为什么会让数据变大 33%？

A：每 3 字节（24 位）重排成 4 字符（各承载 6 位），4/3 ≈ 133%，固定膨胀。

Q：末尾的 = 是什么？

A：补位符，不携带数据，只把长度补齐到 4 字符的整数倍，解析器据此还原原始长度。

Q：URL-safe Base64 和标准 Base64 的区别？

A：+ 换 -、/ 换 _、通常省略尾部 =。JWT 用的就是它。两者可无损互转。

Q：Base64 和 URL 编码分别什么时候用？

A：URL 参数用 URL 编码（逐字符转义、可读）；二进制走文本通道用 Base64（整体重编、不可读）。

Q：为什么解出来是乱码？

A：多半是发送方不是 UTF-8（latin1/GBK 编码后再转的）；或解码对象本来就是二进制（如图片），应存成文件而非当文本。

免费在线 Base64 / URL 编解码

双向转换 · UTF-8 中文安全 · 实时输出 · 纯浏览器本地处理

打开编解码工具 →

Table of Contents

The 3-byte → 4-character principle
The URL-safe variant
Common uses: Data URL / JWT / email
URL encoding (percent-encoding)
How to choose
FAQ

The 3-byte → 4-character principle

Base64 solves one problem: carrying arbitrary binary safely through text-only channels. It maps 64 characters (A–Z, a–z, 0–9, +, /) as an alphabet; every 3 bytes (24 bits) split into 4 groups of 6 bits, each mapped to one character:

bytes:     0xE4  0xB8  0xAD        (first 3 UTF-8 bytes of "中")
binary:    11100100 10111000 10101101
6-bit:     111001 | 001011 | 100010 | 101101
index:     5        11       34       45
Base64:    5        L        i        t   →  "5Lit"

Two consequences:

= padding: inputs not divisible by 3 get = padding (1 leftover → ==, 2 → =)
+33% size: 3 bytes become 4 characters, a fixed 4/3 expansion

Verify it yourself: type「中」into our Base64 tool and you'll get 5Lit.

The URL-safe variant

Standard Base64 uses + and /, which have special meaning in URLs. The URL-safe variant swaps two characters:

Standard	URL-safe
`+`	`-`
`/`	`_`
trailing `=`	usually omitted

They convert losslessly. A "Base64 without + or /" is almost always the URL-safe variant.

Common uses: Data URL / JWT / email

Data URLs: data:image/png;base64,iVBOR... embeds an image right in HTML/CSS — one fewer request, at the cost of bigger HTML and no separate caching
JWT: the header.payload.signature segments are URL-safe Base64 of JSON — which is why you can "read" your token on jwt.io, and why JWTs are not encrypted by default: keep secrets out of the payload
Email MIME: attachments travel as Base64 through the text-only SMTP protocol

URL encoding (percent-encoding)

URLs permit only a small character set; everything else is escaped as %XX byte sequences:

space:   → %20
中:      → %E4%B8%AD   (each of the 3 UTF-8 bytes)
&:       → %26         (escaped inside parameter values)

The fundamental difference from Base64: URL encoding escapes character-by-character and stays mostly readable; Base64 rewrites everything and is fully unreadable.

How to choose

Scenario	Use
Chinese/special chars in query params or paths	URL encoding
Images embedded in HTML/CSS	Base64 (Data URL)
Tokens / signatures in URLs	URL-safe Base64
Email attachments	Base64 (MIME mandate)
"Hiding" secrets	Neither — use real encryption

FAQ

Q: Why does Base64 inflate data by 33%?

A: Every 3 bytes (24 bits) become 4 characters (6 bits each): a fixed 4/3 ≈ 133% expansion.

Q: What's the trailing = for?

A: Padding. It carries no data; it rounds the length to a multiple of 4 so parsers recover the original length.

Q: URL-safe vs standard Base64?

A: + → -, / → _, padding usually omitted; JWTs use it. They convert losslessly.

Q: When to use Base64 vs URL encoding?

A: URL params → URL encoding (per-character escaping, readable); binary over text channels → Base64 (full rewrite, unreadable).

Q: Why does my Base64 decode to garbage?

A: Usually the sender didn't use UTF-8 (latin1/GBK before Base64); or the source was binary (like an image) and should be saved as a file, not read as text.

Free Online Base64 / URL Tool

Bidirectional · UTF-8-safe · Live output · 100% browser-local

Open the Tool →