JWT解析能帮你排查什么？
接口返回401时，可以先确认手上的token是否发给了正确的服务、是否已到过期时间。JWT载荷中的iss表示签发者，sub通常标识主体，aud表示预期接收者。aud可能是字符串，也可能是字符串数组，不能只凭“有这个字段”就判断匹配。
这些内容都是token自身声称的信息。解码器能把它们展示出来，但不能证明签发者真实可信，也不能代替服务端的权限判断。是否必须包含某个声明，由应用或协议要求决定。
三段JWT怎么读
常见签名JWT采用header.payload.signature格式。前两段是Base64url编码的UTF-8 JSON，第三段是签名或MAC的字节数据，不是另一份JSON。Base64url只改变表示方式，并没有加密内容。
可以粘贴token本身，也可以粘贴Bearer或Authorization: Bearer加token的值，不要连同整份HTTP请求一起输入。头部和载荷分开展示，支持单独复制，原始JSON中的大整数和数字写法也会保留。
exp是秒，不是毫秒
exp是过期时间，nbf是允许开始使用的时间，iat是签发时间，均按NumericDate秒数解释。例如1704067200对应2024年1月1日00:00 UTC。不要把JavaScript的毫秒时间戳直接当成JWT秒数。
时间表按设备时钟比较，不额外添加时钟偏差容限。“尚未到过期时间”不等于token有效：签名可能是伪造的，aud也可能不匹配。未来的iat只是值得排查的现象，是否拒绝仍应遵循应用规则。
解码、解密和验签不是一回事
解码无需密钥，因为普通签名JWT的内容本来就能被持有者读取。验签需要可信密钥和明确配置的允许算法；不能只相信输入头部里写的alg。应用还应检查签发者、受众、时间及业务要求的声明。
本工具不会请求jku或x5u地址，也不会使用jwk等内嵌密钥。五段加密JWE、嵌套JWT和b64: false载荷不在支持范围内。输入上限为50,000个字符，JSON最多64层；重复键会报错，避免对同一声明出现不同解释。
用示例理解token
常见问题
JWT解码需要secret吗？
不需要。读取三段JWT的头部和载荷只需还原Base64url。secret或公钥用于验签；本工具不执行验签，也不解密JWE。
为什么签名看起来不像JSON？
签名段编码的是二进制签名或MAC。工具展示原始Base64url和解码后的字节长度，不将其当作文本内容解析。
alg为none还能算JWT吗？
它是没有密码学保护的非安全JWT。仍然有三段，但第三段为空，因此末尾保留一个点号。能解码并不代表可以用于认证。
token会被上传或保存吗？
工具在浏览器内处理输入，不提交给解码API，不持久保存，也不写入地址栏。示例全部使用虚构数据；调试时尽量使用测试token，因为真实Bearer凭证可能授予账号或接口访问权限。
三个示例有什么区别？
已过期示例的exp对应2024年1月1日01:00 UTC，签名为占位内容。无签名示例使用alg: none。Unicode示例包含中文、日文和带重音字符的姓名，以及多个aud。它们均不是可用的认证凭证。
为什么会提示格式错误？
请确认三段完整、头部与载荷非空，且没有多余空白、引号或等号填充。非法UTF-8、非对象JSON、重复键和签名段与alg不一致也会被拒绝。错误输入不会继续显示上一份解码结果。