JWT 解码器 · 在线解码工具

免费 JWT 解码器，在线即时解码 JWT 令牌。查看头部、载荷、签名以及过期时间、算法和声明详情。100% 浏览器本地运行——令牌绝不离开你的设备。无需注册、无跟踪。

无追踪浏览器中运行免费

JWT 令牌

已审核 RFC 7519 合规性与隐私保障 — Go Tools 安全团队 · 2026年4月22日

什么是 JWT？

JSON Web Token，简称 JWT（读作「jot」），是一种紧凑、URL 安全的令牌格式，用于在双方之间传递声明。它由 RFC 7519 定义，是 OAuth 2.0 访问令牌、OpenID Connect ID Token、现代认证服务商（Auth0、Okta、Clerk、Supabase、Firebase）的 API 密钥以及微服务架构中服务间令牌的主流格式。

「JSON Web Token（JWT）是一种紧凑的声明表示格式，适用于 HTTP Authorization 头和 URI 查询参数等空间受限的环境。」——RFC 7519 第 1 节

JWT 由三段用点分隔的 Base64URL 编码 JSON 对象组成：header.payload.signature。头部描述令牌的签名方式（alg 声明——如 HS256 或 RS256，以及 typ 声明，通常为「JWT」）。载荷承载各种声明：注册声明如 iss、sub、aud、exp、iat，以及签发者所需的自定义声明（role、scope、email、租户 ID 等）。签名是在头部和载荷上使用签发者的密钥或私钥计算出的加密凭证，接收方可借此检测篡改。

关键之处在于，JWT 是编码而非加密。任何持有令牌的人都能读取其载荷——解码只是 Base64URL 和 JSON 解析。安全保证来自签名：攻击者可以读取 JWT，但在没有签名密钥的情况下无法产生另一个能通过签名验证的 JWT。这也是为什么 JWT 可以安全地通过网络传输，但不应在其中放入秘密。

JWT 解码器会准确展示令牌的内容——算法、声明、过期时间——而不触碰签名。它是回答「这个令牌过期了吗？」「这个用户是什么角色？」「是哪个签发者签发的？」或「这是一个应当拒绝的 alg:none 令牌吗？」的最快方式。本工具的所有解码都在浏览器本地运行，因此粘贴线上生产令牌也是安全的。

JWT 相关工作常与其他开发工具配合使用。调试格式异常的令牌时，你可能需要解码一个 Base64URL 段；从代理抓取 Authorization 头后可能需要对其进行 URL 解码；或者需要手动将 exp 声明转换为人类日期。如需深入了解生产环境中 JWT 的签名、验证和轮换流程，请阅读我们的 Base64 基础指南——Base64URL 是每个 JWT 的基石。

// Decode a JWT in the browser — header & payload only
function decodeJwt(token) {
  const [h, p, s] = token.split('.');
  const pad = (seg) => seg + '==='.slice((seg.length + 3) % 4);
  const decode = (seg) => JSON.parse(
    atob(pad(seg).replace(/-/g, '+').replace(/_/g, '/'))
  );
  return { header: decode(h), payload: decode(p), signature: s };
}

const { header, payload } = decodeJwt(token);
console.log(header);   // → { alg: 'HS256', typ: 'JWT' }
console.log(payload);  // → { sub: 'user_123', exp: 1999999999, ... }

// Expiration check
const expired = payload.exp * 1000 < Date.now();

核心功能

即时解码 JWT

粘贴即可实时看到 JWT 的头部、载荷和签名解码结果。没有解码按钮，也没有任何服务器往返。

过期检测

自动读取 exp 声明，在令牌过期时显示红色标签，并以你的本地时区展示准确的过期日期。

算法无关

可解码所有 JWS 算法——HS256/384/512、RS256/384/512、PS256/384/512、ES256/384/512、EdDSA 以及 alg:none。

100% 本地运行

解码通过浏览器原生的 atob 和 JSON.parse 在本地完成。你的令牌绝不会被上传——可以安全处理生产凭证。

声明感知展示

突出显示 RFC 7519 的注册声明（iat、exp、nbf、iss、aud、sub、jti），让你一眼识别认证问题。

一键复制

一键复制头部 JSON、载荷 JSON 或原始签名到剪贴板——非常适合编写 Bug 报告和测试用例。

示例

HS256 令牌（有效）

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyXzEyMyIsIm5hbWUiOiJBbGljZSIsInJvbGUiOiJhZG1pbiIsImlhdCI6MTcxNTAwMDAwMCwiZXhwIjoxOTk5OTk5OTk5fQ.4NhxPjwoZxPNuxG-2C5ugGxaUsUJ0QyskAz7Ymz5Sg0

{
  "alg": "HS256",
  "typ": "JWT"
}

{
  "sub": "user_123",
  "name": "Alice",
  "role": "admin",
  "iat": 1715000000,
  "exp": 1999999999
}

使用 HMAC-SHA256 签名的令牌，包含主题、角色和未来的过期时间——最常见的会话认证 JWT 结构。

RS256 令牌（已过期）

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6ImtleS0yMDI1LTAxIn0.eyJpc3MiOiJodHRwczovL2F1dGguZXhhbXBsZS5jb20iLCJhdWQiOiJhcGkuZXhhbXBsZS5jb20iLCJzdWIiOiI5MDA4NzE2NSIsImlhdCI6MTYwMDAwMDAwMCwiZXhwIjoxNjAwMDAzNjAwLCJzY29wZSI6InJlYWQ6dXNlciB3cml0ZTpwb3N0In0.signature_placeholder

{
  "alg": "RS256",
  "typ": "JWT",
  "kid": "key-2025-01"
}

{
  "iss": "https://auth.example.com",
  "aud": "api.example.com",
  "sub": "90087165",
  "iat": 1600000000,
  "exp": 1600003600,
  "scope": "read:user write:post"
}

RSA 签名的 OAuth 风格访问令牌——注意头部的 kid（密钥 ID）以及 exp 声明显示令牌已经过期。

OIDC ID Token

eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwczovL2FjY291bnRzLmdvb2dsZS5jb20iLCJzdWIiOiIxMTA1MDIyNTExNTU4OTkwNzY2Mzk1IiwiYXpwIjoiY2xpZW50LWlkIiwiYXVkIjoiY2xpZW50LWlkIiwiZW1haWwiOiJhbGljZUBleGFtcGxlLmNvbSIsImVtYWlsX3ZlcmlmaWVkIjp0cnVlLCJpYXQiOjE3MTUwMDAwMDAsImV4cCI6MTk5OTk5OTk5OSwibm9uY2UiOiJhYmMxMjMifQ.signature

{
  "alg": "ES256",
  "typ": "JWT"
}

{
  "iss": "https://accounts.google.com",
  "sub": "110502251155899076639",
  "azp": "client-id",
  "aud": "client-id",
  "email": "alice@example.com",
  "email_verified": true,
  "iat": 1715000000,
  "exp": 1999999999,
  "nonce": "abc123"
}

使用 ECDSA 签名的 OpenID Connect ID Token，包含邮箱声明和用于防重放的 nonce。

alg:none 令牌（未签名）

eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJkZWJ1Zy11c2VyIiwiaWF0IjoxNzE1MDAwMDAwfQ.

{
  "alg": "none",
  "typ": "JWT"
}

{
  "sub": "debug-user",
  "iat": 1715000000
}

alg:none 的未签名令牌。在生产环境接受此类令牌是经典的 JWT 安全漏洞——服务端必须始终拒绝 alg:none。

使用方法

1

粘贴你的 JWT 开始解码

将完整的 JWT（包括三段由点分隔的内容）粘贴到输入框。解码器会在浏览器中即时解码，无需点击按钮。
2

查看解码后的头部、载荷与状态

在解码后的头部读取算法和令牌类型，在载荷查看所有声明，在顶部查看过期时间与签发时间。已过期的令牌会以红色标记。
3

复制解码结果

使用每个面板的复制按钮即可复制解码后的头部 JSON、载荷 JSON 或原始签名。你的令牌没有发送到任何地方——解码完全在浏览器本地完成。

Common Errors

接受 alg:none

未签名的 JWT 任何人都能伪造。生产环境中绝不允许 alg:none——始终向 verify 调用显式传入算法列表。

✗ 错误

jwt.verify(token, secret)  // library default may allow 'none'

✓ 正确

jwt.verify(token, secret, { algorithms: ['RS256'] })

缺少 exp 声明

没有 exp 的 JWT 永远有效。一旦泄露，就没有自然的吊销节点。请始终根据令牌类型设置合适的过期时间。

✗ 错误

{ "sub": "user_123", "role": "admin" }  // no exp

✓ 正确

{ "sub": "user_123", "role": "admin", "exp": 1715003600 }

在载荷中存放秘密

JWT 载荷不是加密的——任何持有令牌的人都能读取。切勿在 JWT 载荷中存放密码、API 密钥或未脱敏的 PII。

✗ 错误

{ "sub": "user_123", "password": "hunter2" }

✓ 正确

{ "sub": "user_123", "role": "admin" }  // payload stays minimal

常见使用场景

解码 Authorization Bearer 令牌: 解码 Authorization: Bearer 头中的 JWT 令牌，确认后端收到的声明、受众和过期时间是否正确。
解码 OAuth 2.0 与 OIDC 令牌: 在对接过程中解码授权服务器（Auth0、Okta、Google、Keycloak）返回的访问令牌和 ID Token。
过期会话诊断: 一秒内确认被拒绝的令牌是过期、受众错误，还是因时钟偏差导致。
密钥轮换检查: 读取头部的 kid（密钥 ID），验证 JWKS 轮换是否按预期签发令牌。
安全审查: 在代码审查和渗透测试中识别使用 alg:none、缺少 exp 或在载荷中泄露 PII 的令牌。
微服务令牌检查: 解码服务网格内服务间的令牌，查看下游调用被授予的作用域和主体。

技术细节

符合 RFC 7519 标准: 处理符合 RFC 7519（JWT）、RFC 7515（JWS）和 RFC 7518（JWA）的 JWS 令牌——所有注册算法都可解码。
Base64URL 解码: 使用 RFC 4648 定义的 URL 安全 Base64 字母表（使用 - 和 _ 替代 + 和 /），并对填充宽容解析。
浏览器原生、零依赖: 基于浏览器的 atob、TextDecoder 和 JSON.parse 构建——无外部库、无网络请求、无任何埋点。

最佳实践

未验证就不可信: 解码器只展示声明，并不证明其真实性。在信任任何声明之前，务必在服务端用签发者的密钥验证签名。
生产环境拒绝 alg:none: 为 JWT 库配置明确的算法白名单。绝不接受 alg:none，并对密钥轮换时出现的 alg 不匹配保持警惕。
保持载荷精简: 在 JWT 中放置标识符和短期声明；体积较大的数据应藏在不透明会话 ID 之后。臃肿的令牌会在每次请求上浪费带宽。

常见问题

如何在线解码 JWT 令牌？

把完整的 JWT——三段由点分隔的内容(header.payload.signature)——粘贴到上方解码器即可。解码在浏览器中即时完成：头部和载荷会被 Base64URL 解码为可读 JSON，签名则以原始字符串形式展示。顶部状态栏会显示签名算法、签发时间和过期时间，一眼就能识别过期令牌。如果想手动解码 JWT，只需把令牌按点拆分，对前两段做 Base64URL 解码，再按 JSON 解析——任何持有令牌的人都能读取其声明，因为载荷是编码而非加密的。本解码器可以安全处理生产令牌，因为任何内容都不会离开你的设备：没有网络请求、没有日志、没有跟踪。

什么是 JWT（JSON Web Token）？

JSON Web Token（JWT）是一种紧凑、URL 安全的凭证格式，用于在双方之间传递声明。它由 RFC 7519 定义，由三段用点分隔的 Base64URL 编码组成：头部（算法与令牌类型）、载荷（声明——关于用户和令牌本身的数据）以及签名（证明令牌由可信方签发的加密凭证）。JWT 是 OAuth 2.0 访问令牌和 OpenID Connect ID Token 的标准表示方式。

使用这个 JWT 解码器时我的令牌安全吗？

安全。所有解码操作都在你的浏览器中使用原生 JavaScript（atob 和 TextDecoder）完成。令牌绝不会发送到服务器，不会被记录，不会被存储，也不会用于分析统计。没有 Cookie，没有任何追踪。这一点至关重要，因为 JWT 可能包含活跃的访问令牌——把它粘贴到远程调试器就等同于交出凭证。我们的工具可以安全地处理生产环境令牌。

JWT 解码器是如何工作的？

JWT 解码器按点将令牌拆分为三部分，对头部和载荷进行 Base64URL 解码，然后按 JSON 解析。签名保留为不透明的 Base64URL 字符串，因为验证签名需要签发者的密钥或公钥——这是客户端解码器无法安全完成的事情。这意味着解码是即时的并能显示所有声明，但你必须在服务端使用正确的密钥验证签名，才能信任其中的任何内容。

这个工具能验证 JWT 签名吗？

不能，这是有意为之。签名验证需要签发者的密钥（HMAC）或公钥（RSA/ECDSA/EdDSA），这些内容绝不应粘贴到公开的 Web 工具中。验证必须在你的服务器、认证中间件，或可以访问你的 JWKS 端点的 SDK 中进行。这个解码器用于查看令牌的声明内容——它并不代表令牌是真实或未被篡改的。

iat、exp、nbf、iss、aud、sub 和 jti 是什么？

这些是 RFC 7519 中的注册声明。iat（issued at，签发时间）是创建令牌时的 Unix 时间戳。exp（expiration，过期时间）是令牌失效的时间——本工具会将其转换为人类可读的日期，如果 exp 在过去则标记为已过期。nbf（not before，生效时间）是令牌最早可用的时间。iss（issuer，签发者）标识令牌的创建者。aud（audience，受众）指定令牌的预期接收方。sub（subject，主题）标识主体——通常是用户 ID。jti 是唯一的令牌 ID，用于防止重放。应用特定的声明（role、scope、email、name）与这些注册声明并列存在。

我的 JWT 已经过期——为什么解码器还能解出内容？

解码不等于验证。JWT 解码器无论是否过期都会读取内容，这样你就可以查看已过期或无效的令牌，调试被拒绝的原因。本工具的「已过期」标签会将 exp 声明与你的本地时钟进行比较，并对 exp 在过去的令牌进行标记。真正的认证服务器会直接拒绝该令牌——但如果解码器拒绝显示过期令牌，调试时就没有用了。

JWT、JWS 和 JWE 有什么区别？

JWT 是通用概念——一个编码为紧凑令牌的 JSON 对象。JWS（RFC 7515）是签名的 JWT：任何人解码都能读取载荷，签名证明内容未被篡改。这是目前你最常遇到的 JWT 形式。JWE（RFC 7516）是加密的 JWT：载荷本身是密文，没有解密密钥就无法解码。本工具解码 JWS 令牌。JWE 令牌只能解码出头部——未经密钥无法读取加密的载荷。

为什么 alg:none 很危险？

alg:none 的 JWT 没有签名——任何人都能伪造，声称自己是任意用户。早期的 JWT 库默认接受 alg:none，导致了一类众所周知的认证绕过漏洞：攻击者去掉签名，将 alg 设置为 none，伪造出管理员令牌。如今所有成熟的 JWT 库都会拒绝 alg:none，除非显式允许，你也绝不应为已认证请求接受它。本解码器仍会显示 alg:none 的令牌，因为调试时查看这类令牌是合理的——但在生产环境收到的任何此类令牌都应视为敌对。

这个 JWT 解码器支持哪些算法？

解码头部和载荷适用于所有算法，因为解码只需要 Base64URL 和 JSON 解析——与算法无关。本工具可以正确读取 HS256、HS384、HS512（HMAC），RS256、RS384、RS512（RSA + SHA），PS256、PS384、PS512（RSA-PSS），ES256、ES384、ES512（ECDSA），EdDSA（Ed25519/Ed448），以及未签名令牌（alg:none）。只有签名验证与算法相关，而本工具不执行签名验证。

JWT 应该存在 localStorage 还是 Cookie 中？

会话令牌优先使用 HttpOnly、Secure、SameSite=Strict 的 Cookie。localStorage 中的令牌可被页面上任何 JavaScript 读取，因此单一的 XSS 漏洞就会泄露所有活跃会话。HttpOnly Cookie 对 JavaScript 不可见，把 XSS 的影响范围压缩到攻击者在活跃页面内能做的事——而不是一个可以重放数天的被盗令牌。如果必须使用 localStorage（例如跨域应用），请缩短访问令牌的有效期（分钟级而非小时级），并在 HttpOnly Cookie 中单独存放刷新令牌。

如何在 Node.js、Python 或 Go 中解码 JWT？

Node.js：jsonwebtoken.decode(token) 用于只读解码，jsonwebtoken.verify(token, key) 用于验证。Python：PyJWT.decode(token, options={'verify_signature': False}) 用于读取，传入密钥则进行验证。Go：jwt.ParseUnverified(token, claims) 用于只读，jwt.Parse(token, keyFunc) 用于验证。在任何语言中，生产代码都不应使用 options={'verify_signature': False} 进行验证——这是本 Web 工具为调试目的有意采用的做法，只有在查看而非认证时才是安全的。

JWT 的最大长度是多少？

JWT 标准没有硬性限制，但大多数 Web 服务器的头部默认上限约为 8 KB。建议将令牌控制在 4 KB 以内，使其能顺利放入 Authorization 头和 Cookie。如果令牌超过这个大小，通常说明载荷中塞了太多声明——应将体积较大的数据改为通过不透明的会话 ID 引用，按需从后端获取。臃肿的 JWT 在每次 API 调用时都会一起传输，代价很高。

我粘贴了令牌却提示「Invalid JWT format」——哪里出了问题？

合法的 JWT 恰好由三段以点分隔的部分组成：header.payload.signature。常见原因：（1）你只复制了载荷段，（2）中间被粘贴进了空白或换行，（3）令牌在传输中被截断（终端换行常导致此问题），（4）令牌实际是 JWE，其格式为 header.encryptedKey.iv.ciphertext.tag（五段），或（5）令牌经过 URL 编码，你需要先对其进行 URL 解码。检查 API 返回的原始值——大多数编辑器在悬停时会显示不可见字符。

没有密钥能解码 JWT 吗？

可以——头部和载荷是 Base64URL 编码的，而不是加密的。任何持有令牌的人都能在没有密钥的情况下读取其中的声明。这是有意为之：载荷本就设计为可读，便于接收方据此做出授权决策。只有验证令牌未被篡改时才需要密钥或公钥。这就是为什么你绝不应在 JWT 载荷中放入敏感数据（密码、私钥、接收方尚不知情的 PII）。

我的 JWT 在 Postman 里能用，后端却拒绝——如何调试？

在这里解码令牌并检查：（1）exp——相对于服务器时钟是否仍未到期？服务器时钟偏差是常见原因。（2）iss / aud——是否与后端期望值完全一致？aud 不匹配是最常见的误拒。（3）alg——你的验证代码是否允许该算法？一个 HS256 令牌在仅配置为 RS256 的库上会失败。（4）kid——如果使用密钥轮换，头部中的密钥 ID 是否存在于你的 JWKS 中？（5）signature——你使用的密钥/公钥是否正确？本解码器会在头部和载荷视图中展示 (1)、(2)、(3) 和 (4)，以便你迅速排除这些原因。

JWT 解码器 · 在线解码工具

什么是 JWT？

核心功能

即时解码 JWT

过期检测

算法无关

100% 本地运行

声明感知展示

一键复制

示例

HS256 令牌（有效）

RS256 令牌（已过期）

OIDC ID Token

alg:none 令牌（未签名）

使用方法

粘贴你的 JWT 开始解码

查看解码后的头部、载荷与状态

复制解码结果

Common Errors

接受 alg:none

缺少 exp 声明

在载荷中存放秘密

常见使用场景

技术细节

最佳实践

常见问题

相关工具

在线 MD5 哈希生成器与文件校验工具

随机密码生成器 — 自定义长度、强度与安全性

UUID 生成器与解析器 — v1, v4, v5, v7 批量生成

进制转换器 — 二进制、十六进制、十进制、八进制互转

Base64 解码与编码工具

在线压缩 JPEG、PNG、WebP 图片 — 免费批量处理