开发者专用的JWT工具 解码、编码和检查令牌过期时间

每个后端开发者都曾经历过这样的场景：控制台中出现401未授权错误，随之而来的是一场排查。令牌是否已过期？是否使用了错误的密钥签名？在服务之间传输过程中，载荷是否丢失了某个声明？JWT（JSON Web Token）是现代身份验证的连接纽带，一旦它们出错，所有经过身份验证的后端服务都将失效。

问题不在于JWT复杂。其结构实际上很简单：三个经过base64url编码的段，由点连接——头部、载荷、签名。真正的问题是，一个原始令牌本身在未解码前几乎没有任何信息。而快速、在浏览器中、无需安装任何软件地解码它，正是这三个免费工具所实现的功能。 eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyXzEyMyIsInJvbGUiOiJhZG1pbiIsImV4cCI6MTc0NjA5NjAwMH0.mK2xVpQ8nZ3aF7tLdRhW6sYbcXeUoIPjNvGqTmAS1kE tells you nothing until you decode it. And decoding it — fast, in a browser, without installing anything — is exactly what these three free tools handle.

本指南将带您完整了解JWT的工作流程：解码令牌以查看其内部内容，编码令牌以在测试中模拟身份验证，以及检查过期时间以诊断超时错误。每个部分都使用上述的示例令牌，以便您能够全程跟随操作。

工具1 — JWT解码器：立即查看任意令牌内容

这 JWT 解码器 takes any token and splits it into its three components, decoding the header and payload from base64url to readable JSON.

Paste the example token above and you’ll see the header decoded to:

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

And the payload:

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

那 exp field is a Unix timestamp. At a glance it means nothing — but the decoder converts it to a human-readable date so you immediately know whether the token is still valid or already stale.

One thing to understand: the decoder does not verify the signature by default. Signature verification requires the secret (for HS256) or the public key (for RS256/ES256). What the decoder gives you is the decoded content — which is everything you need when you’re debugging a 401, checking what claims were included, or inspecting a token from a third-party identity provider.

Worth noting: the JWT payload is base64url encoded, not encrypted. Any tool (or person) with the token can read the payload without the secret. The signature only proves the token hasn’t been tampered with. That’s why you should never store sensitive data — passwords, credit card numbers, SSNs — inside a JWT payload.

工具2 — JWT编码器：为测试构建令牌

这 JWT encoder does the reverse: you supply a JSON payload, choose an algorithm (HS256 is the default), enter a secret, and the tool generates a signed token you can use immediately.

最常见的用例是在测试中模拟身份验证。假设您的集成测试需要调用一个受保护的API端点。与其搭建真实的登录流程，不如构建一个包含端点所需具体声明的令牌：

{
  "sub": "test_user_001",
  "role": "editor",
  "iat": 1746009600,
  "exp": 1746096000
}

Sign it with your test secret, drop the resulting token into your test headers, and your protected routes respond as if a real user authenticated. No mocking the auth middleware, no spinning up an identity provider — just a valid token with the claims you need.

编码器在您构建新服务并希望手动测试特定声明组合时也非常有用：缺失的角色、过期的令牌、意外的范围。生成具有边缘情况载荷的令牌，并将其投向您的中间件，以观察其响应方式。

If you need to understand the base64url encoding step itself — since the JWT payload is just encoded, not encrypted — the base64 decoder lets you decode either segment manually. Paste the middle portion of any token (the payload segment) into the base64 decoder and you’ll get the raw JSON back. Same approach, one step at a time.

工具3 — JWT过期检查器：无需数学运算即可调试401错误

Token expiry is responsible for a large share of auth failures in production. The JWT 过期检查器 takes any token and tells you immediately: is it expired? If so, by how much?

Paste the example token and the checker extracts the exp field, converts it from a Unix timestamp to a readable date, and compares it against the current time. You get a clear status: valid (with time remaining) or expired (with how long ago it expired).

This matters more than it sounds. When a 401 hits in production, the first question is always “is the token expired or is something else wrong?” Answering that question by mental arithmetic on a Unix timestamp — 1746096000 - current_time / 3600 — wastes time and introduces errors. The expiry checker answers it in one paste.

It also surfaces the iat (issued at) timestamp when present, so you can see exactly when the token was generated and how long the session has been active. Useful when debugging token refresh bugs or tracking down why a long-lived session suddenly failed.

整合使用：典型的调试工作流程

You get a 401. Here’s the fastest path from error to resolution:

1. Check expiry first. Paste the token into the 过期检查器. If it’s expired, the fix is a token refresh — no further debugging needed.
2. Inspect the payload. If the token is still valid, paste it into the JWT 解码器. Check the claims: is the sub correct? Is the expected role 或 scope present? Is the audience (aud) right for the endpoint you’re hitting?
3. Reproduce with a custom token. If you suspect a specific claim combination is causing the rejection, build a token with the encoder and test directly. This isolates whether it’s the claim content or the token structure itself causing the failure.

Three tools, under a minute, no installs. Most JWT-related 401s resolve at step 1 or 2.

你可能也会喜欢

新的

git stash——不仅仅是恐慌保存（部分暂存、命名暂存以及其他内容）

阅读更多 ”

更新于 2026年6月16日

新的

基于游标的分页与偏移量分页 — 为何 page=2 会静默丢弃记录

阅读更多 ”

更新于 2026年6月15日

新的

Docker 多阶段构建： 在不破坏部署的情况下缩小镜像大小

阅读更多 ”

更新于 2026年6月14日

新的

OAuth 2.0 流程： 授权码、PKCE 和客户端凭据

阅读更多 ”

更新于 2026年6月13日