Base64、URL 编码和 JWT 解码：该用哪一种？

包含百分号、字母或圆点的一长串内容，可能只是某种文本表示方式。解码前先判断它是什么，以及解码后会被放在哪里。

FormatOwl 的编码工具在本地处理文本。调试优先使用示例内容，不要把真实访问令牌放进截图或共享报告。

按输入结构选择工具

Base64 不是加密

Base64 把字节转换成特定字符集。FormatOwl 以 UTF-8 编码文本，也可以解码回中文等 Unicode 文本，但不是任意二进制文件解码器。背景说明可参考 MDN Base64 文档。

可以先编码 Hello，再把结果解码，确认往返结果。密码变成 Base64 后仍可被直接还原，不能视为得到保护。

如果输入是 Data URL，开头的媒体类型属于 URL 包装，不是 Base64 内容本身。SVG 场景可以使用专门的 SVG Data URL 工具。

URL 应按参数值编码

假设参数内容是 red & blue，编码后是 red%20%26%20blue，这样与号会保留在参数值内，而不是被当成参数分隔符。

用组件编码工具处理整个网址，也会编码 : 和 / 等结构符号。因此应只处理准备插入的值，再按正确上下文组装 URL。

重复编码会把百分号变成 %25，例如 %20 再次编码会得到 %2520。只还原来源实际使用的编码层数。这个工具不会自动把表单风格的 + 还原为空格。

JWT 解码只负责查看

常见的紧凑签名 JWT 分成三个由圆点分隔的部分。FormatOwl 读取 Base64url 表示的 JSON 头部和载荷，但不验证签名、到期时间或权限。看到载荷中写着某个角色，不能证明它可信。

JWT 规范定义了 exp 等声明和处理要求，显示出 JSON 并不等于替应用执行了这些校验。

可以使用示例令牌理解结构，真正的认证判断仍应由接收系统按自己的规则完成。

结果必须放回正确上下文

十六进制和二进制工具表示的是 UTF-8 字节，因此一个可见的非 ASCII 字符可能对应多个字节。十六进制输入必须组成有效字节，二进制输入应包含完整的八位字节，并能还原为有效文本。

HTML 实体解码可能恢复标记字符，不能把任意编解码理解为 HTML 安全净化。处理 JSON 字符串内容时，应改用JSON 字符串转义，两者的引号和反斜线规则不同。

复现问题时不要分享真实令牌

准备问题报告时，把真实声明和标识符替换成虚构值，再复现同一种编码问题。本地解码生产 JWT 不代表可读载荷就适合公开，也不要把原令牌放进截图、问题描述或网址。

解码后的载荷是普通 JSON 时，小样本可用JSON 格式化检查。大型导出另有文件导入流程，两种格式化都不会验证令牌签名或访问权限。

操作要点

先识别表示方式，只转换需要的一层，再按目标上下文检查。编码不等于加密，解码也不等于验证可信度。