JWT 解码器 · 在线解码工具

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

无追踪浏览器中运行免费

JWT 令牌

仅解码——不验证签名。

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

我们的团队根据 RFC 7519 验证 JWT 解析，针对 HS/RS/ES/PS/EdDSA 各类算法测试令牌，并遵循 OWASP JWT 安全指南。

什么是 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 声明

在载荷中存放秘密

常见使用场景

技术细节

最佳实践

常见问题

相关工具

AES 解密工具 — 兼容 OpenSSL 与 CryptoJS

AES 加密工具 — GCM、CBC 与 CTR 模式

Bcrypt 哈希生成器与验证器

CRC校验计算器（循环冗余校验）

HMAC 生成器与签名校验工具

JWT 编码器与生成器