Base64URL 编码器和解码器
为 JWT、URL 和 Web 安全数据编解码 Base64URL 字符串。在文本、标准 Base64 和 URL 安全 Base64URL 之间互相转换——输出不含 +、/ 或 = 字符。
在上方输入要编码的文本后查看结果
什么是 Base64URL？
Base64URL 定义于 RFC 4648 第 5 节。它使用与标准 Base64 相同的 64 字符编码，但替换了两个字符，使输出无需百分号编码即可安全用于 URL 和文件名。
填充符（=）是可选的——大多数 Base64URL 实现（包括 JWT）完全省略填充符，因为正确的填充长度总是可以从字符串长度推算出来。
| 标准 Base64 | Base64URL | 原因 |
|---|---|---|
| + | - | + 在查询字符串中表示空格 |
| / | _ | / 在 URL 中是路径分隔符 |
| = (填充) | 省略 | = 在查询字符串中是键值分隔符 |
JavaScript — Base64 与 Base64URL 互转
// Text → Base64URL
function textToBase64Url(text) {
const bytes = new TextEncoder().encode(text)
let binary = ''
bytes.forEach(b => binary += String.fromCharCode(b))
return btoa(binary)
.replace(/\+/g, '-')
.replace(/\//g, '_')
.replace(/=/g, '')
}
// Base64URL → Text
function base64UrlToText(b64url) {
const b64 = b64url
.replace(/-/g, '+')
.replace(/_/g, '/')
const pad = b64.length % 4
const padded = pad ? b64 + '='.repeat(4 - pad) : b64
const binary = atob(padded)
const bytes = Uint8Array.from(binary, c => c.charCodeAt(0))
return new TextDecoder().decode(bytes)
}
// Base64 → Base64URL
const toB64Url = b64 =>
b64.replace(/\+/g, '-').replace(/\//g, '_').replace(/=/g, '')JWT 为何使用 Base64URL
JWT（JSON Web Token）通常在三个地方传输：Authorization HTTP 请求头、URL 查询参数或 Cookie。在这三种场景中，标准 Base64 字符都会引发问题：
+在查询字符串中被解析为空格/在 URL 中被视为路径段分隔符=在查询字符串中用作键值分隔符
Base64URL 规避了以上三个问题。JWT token——即使在标准 Base64 形式下含有 + 或 / 的——都可以安全地放在 URL 或请求头的任意位置，无需任何额外编码。
JWT 结构
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
↑ header（Base64URL）
.eyJzdWIiOiIxMjM0NTY3ODkwIn0
↑ payload（Base64URL JSON）
.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
↑ signature（Base64URL）在 JavaScript 中解码载荷
const token = 'eyJ...SflK...'
const [, payload] = token.split('.')
// Add padding back, then decode
const b64 = payload.replace(/-/g,'+').replace(/_/g,'/')
const pad = b64.length % 4
const padded = pad ? b64 + '='.repeat(4 - pad) : b64
const json = JSON.parse(atob(padded))
// → { sub: '1234567890', ... }切勿在服务端验证签名之前信任解码后的 JWT 载荷。 解码是公开操作——任何人都能读取载荷。签名才是证明 token 由可信服务器签发的凭证。
Base64URL 的使用场景
JWT token
JSON Web Token 对所有三个段（header、payload、signature）均使用 Base64URL。定义于 RFC 7519。
OAuth 2.0 PKCE
PKCE 流程中的 code_verifier 和 code_challenge 均使用 Base64URL 编码。challenge 是 verifier 的 SHA-256 哈希值经 Base64URL 编码后的结果。
URL 安全的 state 参数
OAuth state、CSRF token 和不透明标识符通常经 Base64URL 编码，以便在重定向 URL 中传递而无需额外转义。
Web Crypto API
SubtleCrypto API 返回 ArrayBuffer。Base64URL 是将密钥和签名序列化用于存储或传输的标准方式。
WebAuthn / Passkeys
Web Authentication API 使用 Base64URL 对凭据 ID、认证器数据和认证对象进行编码。
文件 ID 和 token
许多 API 生成随机字节 token（如 session token、上传 ID），并以 Base64URL 字符串返回，以便安全用于 URL。
常见问题
什么是 Base64URL？
Base64URL 是标准 Base64 的变体，可安全用于 URL 和文件名。它将 + 替换为 -，/ 替换为 _，并去掉 = 填充符。字符集与 Base64 相同，只是将在 URL 中具有特殊含义的三个字符（+、/、=）替换或去除。
为什么 JWT 使用 Base64URL？
JWT（JSON Web Token）通过 HTTP 请求头、URL 参数和 Cookie 传输——在这些场景中，标准 Base64 的 + 和 / 字符会被误解析或需要百分号编码。Base64URL 改用 - 和 _ 来避免这个问题。JWT 还去掉了填充符（=）以尽量压缩 token 长度。
可以在 JWT 中使用标准 Base64 吗？
不可以。JWT 规范要求使用 RFC 4648 §5 定义的 Base64URL 编码。期望 JWT 的实现会拒绝使用标准 Base64 编码的 token。这个区别很重要：任何包含 + 或 / 的 token 段都会破坏 URL 解析。
Base64URL 是无损的吗？
是的。Base64 和 Base64URL 之间的转换是完全可逆的。将 + 替换为 - 和 / 替换为 _ 是一一对应的——不会丢失任何信息。去除填充符也是可逆的，因为正确的填充长度总是可以从字符串长度推算出来。
Base64URL 和 URL 编码有什么区别？
它们解决的是不同的问题。Base64URL 使用 64 个字符将二进制数据转换为 URL 安全的文本表示。URL 编码（百分号编码）转义 URL 中不安全的单个字符——例如空格变为 %20。在 URL 参数中携带二进制数据时用 Base64URL，在查询字符串中转义用户输入文本时用 URL 编码。
如何解码 JWT 载荷？
JWT 由三个点分隔的部分组成：header.payload.signature。每个部分都是 Base64URL 编码的。要读取载荷，取第二段并按 Base64URL 解码——它是一个 JSON 对象。注意：解码载荷并不验证签名。务必在服务端验证签名后才能信任 JWT 中的数据。
正在处理 JWT token？
使用 JWT 解码器查看任意 JWT token 的 header 和 payload——自动完成 Base64URL 解码和 JSON 格式化。