JWT Decoder
Decodes the header and payload of a JSON Web Token from base64url and renders the standard claims in a readable form. Decoding happens entirely in your browser — the token is not sent to a server. The signature is not verified; that requires a secret key.
Last updated:
Decoded Token
Paste a JWT above; the sections are decoded instantly.
- Header
- { "alg": "HS256", "typ": "JWT" }
- Payload
- { "sub": "1234567890", "name": "John Doe", "iat": 1516239022 }
- Signature
- SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
The signature is shown raw only and is not verified. Verifying the signature requires a secret key (HMAC) or a public key (RSA/ECDSA).
Standard Claims
| Claim | Value | Meaning |
|---|
When this decoder earns its keep
Working out why an API says 401
"Unauthorized" carries no diagnosis. Opening the payload and reading exp, aud and iss rules out two of the three usual suspects in seconds, leaving signature problems as the remainder.
Auditing what your identity provider emits
Role checks that fail usually fail because the claim is missing or named differently than the code expects. Decoding a real token settles what the provider actually wrote, as opposed to what its dashboard implies.
Learning the anatomy once, properly
A JWT is three base64url sections joined by dots, and nothing about the first two is secret. Decoding one by hand, as below, permanently changes how you reason about what tokens can and cannot protect.
Worked example: taking a token apart by hand
Take a token whose first section is eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9. No key material is needed for any of the following.
- That first section is plain base64url; decoded it reads {"alg":"HS256","typ":"JWT"}.
- The middle section decodes the same way; suppose it contains iat 1754649600 and exp 1754653200.
- iat converts to 2025-08-08 10:40:00 UTC and exp to 11:40:00 UTC: a one-hour token.
- The difference 1754653200 − 1754649600 = 3600 seconds confirms the lifetime without any calendar math.
- The third section is the HMAC-SHA256 signature; without the secret it is opaque bytes, which is why this page shows it raw.
Everything except the signature is a postcard: readable by any party that handles the token in transit or at rest. The signature prevents modification, not reading. Design payloads accordingly, and treat the verifier's configuration, not the token's contents, as the security boundary.
Four mistakes worth avoiding
Letting the token choose its own algorithm
Verifiers that read alg from the header and obey it invited the classic none and RS256-to-HS256 downgrade attacks. The verifier must pin its accepted algorithms in configuration and treat the header as a hint at most.
Forgetting that JWTs cannot be revoked
A signed token is valid until exp no matter what happens to the account in between. Logout, password change and permission downgrades do not reach tokens already issued. Short lifetimes plus refresh tokens are the standard answer; long-lived access tokens are a design smell.
Misreading audience failures as expiry
A token minted for one API and replayed against another fails validation even though it decodes beautifully and exp is far away. When a fresh-looking token is rejected, compare aud and iss against the verifier's configuration before blaming the clock.
Letting the payload grow unbounded
Tokens ride the Authorization header of every request, and several proxies and servers cap request headers at around 8 KB. A payload that accretes claims eventually produces intermittent 431 errors that look nothing like an auth problem.
Tools commonly used alongside this one
- Base64 Encoder-Decoder Encode text to Base64 or decode it back. Standard and URL-safe (base64url) variants; UTF-8 aware, in the browser.
- Epoch / Unix Timestamp Converter Convert Unix epoch timestamps to readable dates and back. Seconds and milliseconds are auto-detected.
- Kubernetes Resource Budget Calculator Estimate how many nodes you need, your packing efficiency, and the projected monthly cost from pod requests and node size.
- UUID Generator Generate cryptographically secure UUID v4 and time-ordered v7. Bulk generation and format options.
- CIDR / Subnet Calculator Compute the network address, broadcast, subnet mask, usable host range and address type from CIDR notation.
Frequently Asked Questions
Is the token I paste sent to a server?
No. Decoding happens entirely in your browser with JavaScript; the token is not sent to any server and is not stored anywhere. When you close the page, no trace remains.
Does this tool verify the token signature?
No. This tool only decodes the header and payload sections. Verifying the signature requires the issuer's secret key (HMAC such as HS256) or public key (RS256/ES256), and handing that secret to a web tool is not safe. Verify the signature server-side with the JwtBearer middleware.
Is the data inside a JWT encrypted?
No. base64url is only an encoding, not encryption — anyone can decode the payload. Do not put passwords, personal data or secrets in a JWT. If confidentiality is needed, use JWE (encrypted JWT) or keep sensitive data outside the token.
What do the exp, iat and nbf claims mean?
All three are NumericDate values: the number of seconds since 1 January 1970 UTC. exp is the token's expiration moment; iat is when it was issued; nbf is when it starts being valid. This tool converts all three to readable dates and shows whether the token has expired.
How do I verify a JWT in .NET?
Add the Microsoft.AspNetCore.Authentication.JwtBearer package and configure AddAuthentication().AddJwtBearer(...) with TokenValidationParameters: ValidateIssuer, ValidateAudience, ValidateLifetime and IssuerSigningKey. The middleware checks the signature, issuer and lifetime for you — do not decode the signature by hand.