JWT Decoder
Decode and inspect any JWT instantly in your browser. View header, payload, claims, and expiry status — 100% client-side, nothing sent to a server.
Paste a JWT above to inspect its header, payload, and claims.
What is a JWT and How Does This Decoder Work?
A JSON Web Token (JWT) is a compact, URL-safe credential format defined in RFC 7519. It is the backbone of modern authentication flows — OAuth 2.0, OpenID Connect, and most REST API token schemes all rely on JWTs to carry claims between parties. Despite being ubiquitous, the raw token is a dense opaque string. This tool decodes the three dot-separated segments and presents the header, payload, and signature in a readable, structured format — instantly, with no server involved.
Anatomy of a JWT
Every JWT has exactly three parts separated by periods (.):
- Header — a JSON object declaring the token type (
typ) and the signing algorithm (alg), e.g.HS256,RS256, orEdDSA. Base64url-encoded. - Payload — a JSON object containing claims: assertions about the
subject (user, service) and any application-specific data. The standard registered claims
include
sub(subject),iat(issued at),exp(expiration), andnbf(not before). Base64url-encoded. - Signature — a cryptographic MAC or digital signature computed over the encoded header and payload using the signing key. It proves integrity; it does not encrypt anything.
Reading Timestamp Claims
The iat, exp, and nbf claims are Unix timestamps — integers
representing seconds elapsed since 1 January 1970 UTC. This decoder converts each one to a
human-readable date and also shows relative time ("3 hours ago", "expires in 2 days") so you can
immediately tell whether a token is fresh, active, or stale without converting manually.
An Expired badge appears if exp is in the past, and a warning
badge highlights tokens that expire within the next hour.
Common Developer Use Cases
- Debugging an API that returns 401 Unauthorized — inspect the token to see if it
has expired or is missing a required claim like
scopeorrole. - Verifying that your auth server is encoding the correct user ID in the
subclaim after a login flow. - Checking that the
algheader matches what your backend expects — a mismatch causes signature verification to fail even for otherwise valid tokens. - Inspecting a third-party token (e.g. from a social login provider) to understand what claims it contains before writing claim-mapping code.
- Quickly confirming that a token refresh is working by comparing the
iatof successive tokens.
Decode vs. Verify
This tool performs decoding only — it reads the payload and header without
validating the signature. This is intentional: signature verification requires your HMAC secret
or RSA/EC private key, which should never leave a secured environment and should be handled
server-side or in a local CLI, never in a public web tool. If you need to verify a token
signature, use your language's JWT library (jsonwebtoken for Node.js,
python-jose for Python, etc.) with your actual signing key.
Privacy
Every operation here runs entirely in your browser using native JavaScript. Your JWT is never uploaded, sent to a server, or logged anywhere. You can inspect this by opening your browser's DevTools → Network tab and confirming there are no outgoing requests while you decode. This makes it safe to use even with tokens that carry sensitive user data — but as always, be mindful about where you open browser tabs that contain production credentials.
Frequently Asked Questions
Is it safe to paste my JWT into this tool?↓
Yes. This decoder runs entirely in your browser using JavaScript — your token is never transmitted to any server, logged, or stored. You can verify this by checking your browser's network tab while using the tool: no outbound requests are made. That said, JWTs often contain authentication credentials, so as a general practice avoid sharing them with any tool you cannot verify as private.
What is the difference between decoding and verifying a JWT?↓
Decoding means base64url-decoding the header and payload sections to read their contents as JSON. It requires no secret and anyone who holds the token can do it. Verification is a separate step: it uses the signing key (HMAC secret or public key) to confirm the signature matches the header and payload, proving the token has not been tampered with and was issued by a trusted party. This tool only decodes — it does not verify signatures, because that requires your secret key and should happen server-side.
What do the standard JWT claims (iat, exp, sub, nbf) mean?↓
These are registered claim names defined in RFC 7519. "iat" (issued at) is the Unix timestamp when the token was created. "exp" (expiration time) is the Unix timestamp after which the token must not be accepted. "sub" (subject) identifies the principal the token represents, usually a user ID. "nbf" (not before) is the earliest Unix timestamp at which the token is valid — useful for tokens issued in advance. All timestamps are in seconds since the Unix epoch (1970-01-01 UTC).
Why does my JWT have three parts separated by dots?↓
A JWT is composed of three base64url-encoded segments joined by periods: the header (algorithm and token type), the payload (claims), and the signature. The header and payload are plain JSON objects encoded in base64url. The signature is a cryptographic hash of the first two parts, computed with the signing key — it lets the receiver confirm the token has not been altered in transit.
Can I decode a JWT without the signing secret?↓
Yes. The header and payload of a JWT are simply base64url-encoded JSON — they are not encrypted. Any holder of the token can decode and read them without knowing the secret. The secret is only needed to verify or produce the signature. If you need to keep the payload data confidential, use a JWE (JSON Web Encryption) token instead of a plain JWT.