JWT Decoder
Paste any JSON Web Token to inspect its header, payload, and standard claims including expiry status. Runs entirely in your browser.
- On-device
- No uploads
- Works offline
JWT decoder
About this tool
This tool splits a JWT into its three dot-separated parts, base64url-decodes the header and payload, and displays each as formatted JSON. A claims summary table highlights the most common registered claims: alg, typ, iss, sub, aud, exp, nbf, iat, and jti. Time-based claims show both the raw number and the equivalent UTC date.
The expiry badge tells you at a glance whether the token is still valid, has expired, or is not yet active.
How to use
- Paste your token into the text area. Decoding happens as you type.
- Click Load sample token to try the tool with a classic HS256 demo token.
- Check the expiry badge to see whether the token is valid, expired, or not yet active.
- Review the claims summary table for a quick overview of standard claims.
- Use the Copy buttons to copy the header or payload JSON for further inspection.
Security
All decoding runs locally in your browser. Your token is never sent to any server. You can confirm this by opening your browser's network tab while using the tool.
This tool does NOT verify the signature. The signature section shows the raw third part of the token only. Verifying requires the signing key, which this tool does not have. Always validate tokens server-side before trusting their claims.
A decoded JWT is not the same as a verified JWT. Do not treat decoded claims as trustworthy unless your server has independently verified the signature.
About JWT Decoder
JSON Web Tokens are the most common format for representing authentication and authorization claims in modern web and mobile applications. An Android app that talks to a REST API almost certainly uses JWTs: the server issues one after login, and the app includes it in the Authorization header of every request. Being able to inspect that token quickly is essential when debugging auth flows, checking claim values, or verifying that an expiry is set correctly.
JWT structure
Every JWT has exactly three parts separated by dots. The first part is the header, a small JSON object that identifies the signing algorithm (such as HS256 or RS256) and the token type. The second part is the payload, a JSON object containing the actual claims. The third part is the signature, a cryptographic value that proves the token was issued by a specific party and has not been altered since.
Both the header and payload are encoded with base64url, a URL-safe variant of base64. This is an encoding, not encryption. Anyone who has the token string can decode and read the header and payload. Never put secrets in a JWT payload.
Standard claims
The IANA JWT registry defines a set of well-known claim names. iss (issuer) identifies who created the token. sub (subject) is usually the user identifier. aud (audience) restricts which services may accept the token. exp (expiry) is a Unix timestamp after which the token must be rejected. nbf (not before) prevents use before a specific time. iat (issued at) records when the token was created. jti (JWT ID) is a unique identifier for this specific token, useful for revocation.
Decoding vs. verification
Decoding reads the claims from the base64url-encoded parts. Any client can do this without any key. Verification checks the cryptographic signature to confirm the token came from the expected issuer and was not tampered with. A decoded-but-unverified token can be forged or replayed. Always verify server-side before acting on any claim.
Frequently asked questions
Can I see my token's claims without verifying the signature?
Yes. The header and payload are base64url-encoded, not encrypted. Any tool can decode them without a key. That is exactly what this decoder does. Just remember that reading the claims does not mean the token is authentic: verification is a separate step that requires the signing key.
Why does my token say "Expired"?
The exp claim is a Unix timestamp (seconds since 1970-01-01). Your browser clock is compared against it. If the token was issued for a short window (common in access tokens: 5 to 60 minutes) it may already be past its expiry. Refresh tokens are usually long-lived and are used to obtain new access tokens.
What is base64url and why is it used?
Standard base64 uses + and / characters that have special meaning in URLs and HTTP headers. Base64url replaces + with - and / with _, making the encoding safe to embed directly in a URL query string or Authorization header without percent-encoding.
Is this tool safe to use with production tokens?
Decoding runs entirely in your browser and no data is sent to a server. However, you should still be cautious: treat access tokens as credentials and avoid pasting them into untrusted tools. For extra safety, use this tool offline, or paste only tokens that have already expired.