JWT Decoder
Decode JWT tokens to inspect header, payload and expiry. Decoding runs entirely in your browser: the token is never uploaded.
How to use
- Paste the JWT token into the input box: no button needed; the header and payload are decoded and pretty-printed instantly.
- The token is split on "." and each part is decoded as Base64URL (with "=" padding restored automatically), then shown as formatted JSON for easy reading of nested structures.
- The summary below lists alg / typ plus the local times for the iat (issued at), nbf (not before) and exp (expires) claims; exp also gets an "Expired / Valid" badge with the remaining time.
- The signature is shown as-is for comparison or copying only; this tool does not verify it and cannot prove the token is untampered.
- Click "Example" to generate a demo token, or "Clear" to remove the input and all results.
FAQ
Is my token uploaded to a server?
Why does it say "Valid" but the server still rejects the token?
Which token formats are supported?
Which time zone is used for the times?
How to use
- Paste the token
Drop a three-part JWT into the input box; no button press is needed. The header and payload are decoded and pretty-printed as JSON at once.
- Read the claim summary
The result area lists alg and typ plus local times for iat, nbf and exp. Unix timestamps are converted into your browser's time zone.
- Check expiry at a glance
The exp row carries an Expired or Valid badge with the remaining time. You can judge token status without converting timestamps by hand.
- Copy the parts you need
The Header, Payload and Signature boxes each have a Copy button. Paste claims into documentation, an issue tracker or a test script.
- Remember the signature limits
The signature is displayed as-is and never verified. A Valid badge does not prove the token is untampered; trust decisions belong to the server.
About this tool
A JWT is three Base64URL-encoded parts joined by dots. The header names the signing algorithm, the payload carries the claims, and the signature lets a server verify both. Encoding is not encryption; anyone holding the token can read the first two parts. This decoder splits and decodes each part locally, formats the JSON and converts the iat, nbf and exp timestamps into your local time zone.
Use it to debug API authentication and check whether claims like sub, iss and exp match expectations. When a token looks unexpired but is still rejected, the cause is often a clock or time-zone mismatch. Five-part JWE encrypted tokens cannot be decoded here, and the tool never verifies signatures. Paste only test or redacted tokens. The decoded content stays visible on screen, so production credentials do not belong here.
How it works
The token format itself is specified in RFC 7519, and the header's alg field names the signing algorithm. HS256 is symmetric HMAC, where issuer and verifier share one secret. RS256 and ES256 use asymmetric key pairs: sign with the private key, verify with the public one, which suits third-party integrations. All three segments use the Base64URL variant, replacing plus and slash with minus and underscore and dropping the padding. That is what lets a token survive inside URLs and cookies. Encoding and encryption are different things. The tradeoff: the first two parts are readable by design.
The signature structure comes from RFC 7515, and servers use it to verify authenticity. Claims such as iss, sub, aud, exp, nbf, iat and jti are registered claims. The three time claims are all second-precision Unix timestamps: iat marks issuance, nbf sets the earliest acceptance and exp the expiry. Servers usually tolerate a clock skew of tens of seconds. Every other claim is business-defined with no standard meaning. This decoder renders the time values in your device's time zone for reading, but real validity comes from the issuer's key and the signature. While the signature stays unverified, an unexpired token is one claim among several, not proof of trust.
When to use it
- Chasing a rejected-but-valid token
When exp still shows valid yet the API keeps returning 401, compare the algorithm and key first. Then check device clock skew, and finally whether aud or iss matches the server-side configuration.
- Diagnosing 403 instead of 401
A 403 usually means the token itself is fine but a claim falls short. Decode it and inspect the scope, role or tenant claims for the required value instead of blind-retrying the request.
- Auditing tokens for leaked secrets
Fresh signing logic often tucks phone numbers or email addresses into the payload. Decode a production-shaped token once and such design flaws surface before they turn into an actual data exposure.
Tips & tricks
- The payload is readable by anyone, so never store secrets in JWT claims. Base64 encoding only obscures them.
- An empty signature with alg set to none is expected for unsigned tokens, not a decoding error.
- Time claims are second-precision Unix timestamps converted to your device's zone; a server in another zone may judge validity differently.
Things to watch
- Do not log tokens verbatim
Printing a whole JWT into logs duplicates a credential. Logs are usually visible to far more people than the codebase. Log only sub and jti, and truncate or redact the token itself.
- Treat alg none with suspicion
Several historic vulnerabilities came from servers accepting unsigned tokens with alg set to none. An empty signature during debugging should prompt a check that the server rejects that algorithm, not a shrug.
- Base64URL is not standard Base64
Tokens use the Base64URL variant, whose alphabet drops plus, slash and padding. Feeding one to a generic Base64 decoder errors out or yields garbage; only Base64URL rules reconstruct it cleanly.