编码解码哈希加密格式化时间转换开发生成文本处理网络工具其他工具
首页 / 编码解码 / Base64URL编解码

Base64URL编解码

URL 安全的 Base64 编码与解码

输入(编码填原文 / 解码填 Base64URL)
结果

这个工具能做什么

这个工具做的事很直接:把文本或字节在明文和 base64url 之间来回转换。标准 Base64 编码会产出加号、斜杠和末尾的等号三类字符,它们在 URL、查询参数和文件名里都有特殊含义,直接拼进去往往被转义成 %2B、%2F、%3D,甚至破坏链接结构。base64url 正是为解决这个问题而生的变体,但靠手动替换字符、增删填充又繁琐易错。本工具一键完成 base64url 编码与解码,省掉在终端里敲 tr 命令或手写正则替换的步骤。

从算法上看,base64url 与标准 Base64 的主体完全一致:把输入字节流每 3 字节(24 位)分为一组,再切成 4 个 6 位单元,逐个映射到长度为 64 的字符表。二者的差别只在字符表的最后两位和填充方式——标准表的第 62、63 号字符是加号和斜杠,base64url 换成减号和下划线,同时省略末尾用于对齐的等号,因为解码端可以靠字符串长度对 4 取模推算出应补的字节数。处理文本时,中文、Emoji 会先按 UTF-8 编码成字节序列再做 base64url,所以一个常见汉字占 3 字节、扩展成 4 个输出字符,解码时按同样规则还原,不会乱码。

最典型的用途是和 JWT 打交道。JWT 的 Header、Payload、Signature 三段各自用 base64url 编码后以点号连接,把中间的 Payload 段贴进来解码,就能看到 iss、exp、sub 等声明的原始 JSON,排查 token 过期或权限异常时非常直观。另一个常见场景是把短小的结构化数据放进 URL:生成分享链接时,将一段 JSON 状态编成 base64url 直接拼在问号后面,接收端解码即可还原,全程不必担心特殊字符破坏链接结构。OAuth 授权流程里的 state、code 参数也常是 base64url,遇到回调异常时拿来解码核对内容会省事很多。

有几个容易踩的坑值得留意。首先 base64url 与标准 Base64 不能直接混用,把带加号、斜杠的标准结果当 base64url 解码会失败,反过来也一样;本工具解码时会兼容带填充和不带填充两种写法,但字符表必须对得上。其次要清楚 base64url 只是编码而非加密,任何人拿到字符串都能还原原文,别用它来保护密码、密钥这类敏感信息。如果解码报错,多半是字符串被截断、混入了空格或换行,或者它其实是含加号、斜杠的标准 Base64 而非 URL 安全变体,逐一排查通常就能定位。

Base64URL编解码是一个免费的在线工具,打开网页就能用,不用下载也不用注册。平时大家搜的“base64url”、“base64 url安全”、“base64url编码”,说的都是这个。

常见使用场景

使用方法

  1. 把内容粘贴到输入框(生成类工具直接设置选项)。
  2. 按需要选择选项,点操作按钮。
  3. 结果出现在下方,点「复制结果」即可带走。

常见问题

Base64URL 和普通 Base64 有什么区别?
算法完全相同,只有两处不同:base64url 把第 62、63 号字符从加号、斜杠换成减号、下划线,并且默认去掉末尾的等号填充。目的是让结果能安全地放进 URL、文件名和 JWT,不用再做百分号转义。
为什么编码结果末尾没有等号?
base64url 规范(RFC 4648 第 5 节)允许省略填充等号,解码方按字符串长度对 4 取余就能算出该补几个字节。本工具编码默认不加等号,解码时对带不带等号的写法都能识别。
支持中文和 Emoji 吗?
支持。文本会先按 UTF-8 编码成字节再做 base64url,一个常见汉字占 3 字节、Emoji 通常占 4 字节,解码时按同样规则还原,不会出现乱码。
解码一直报错可能是什么原因?
常见原因有三个:字符串里混入了空格或换行、内容被截断不完整、或者它其实是含加号和斜杠的标准 Base64 而非 URL 安全变体。逐一检查这几点通常就能解决。
用它编码敏感信息安全吗?
base64url 是可逆编码而非加密,拿到字符串的人都能直接还原原文,不要用来保护密码、密钥或隐私数据。工具本身全部在浏览器本地运算,输入内容不会上传服务器。

相关工具

查看全部「编码解码」工具 →