JWT Decoder Online Free
Decode and inspect JSON Web Tokens instantly — view the header, payload claims, expiry, and signature details in a clean readable format. No signup, runs entirely in your browser.
JWT Decoder
How to Use the JWT Decoder
- 1Copy your JWT from your browser's localStorage, a network request header, or your application's debug output.
- 2Paste the token into the input box. The decoder splits it on the two dot separators and Base64URL-decodes the header and payload immediately.
- 3The Header shows the signing algorithm and token type. The Payload shows all claims — user ID, roles, expiry, and any custom fields your app sets.
- 4The summary below the JSON panels highlights the issuer, subject, issued-at time, and expiry with a clear Valid / Expired badge.
Understanding JWT Structure
Every JWT has exactly three parts separated by dots: header.payload.signature. Each part is Base64URL-encoded (not encrypted). This means anyone who has the token can read the header and payload — JWTs are not secret by default, only tamper-evident. Never store sensitive data like passwords or payment details in a JWT payload.
Common JWT Debugging Scenarios
401 Unauthorized Errors
Paste the token from the failing request's Authorization header. Check the exp claim — expired tokens are the most common cause of sudden 401s after a period of inactivity.
Wrong User Data in UI
Decode the token your frontend is sending and check the sub, email, or role claims. If the claims are stale or wrong, the token was issued with incorrect data — force a re-login to get a fresh one.
Checking Algorithm
The header's alg field shows the signing algorithm. If you expected RS256 but see HS256 (or worse, none), your token issuance config has a bug — the alg: none attack is a known JWT vulnerability.
Inspecting Custom Claims
Many auth systems add custom claims — tenant ID, feature flags, subscription tier. Decode the token to confirm these are present and contain the expected values before debugging further downstream.
OAuth & OIDC Tokens
OpenID Connect ID tokens are JWTs. Decode them to inspect the standard OIDC claims: nonce, at_hash, azp, and the user's profile fields. Useful for debugging SSO integrations.
Token Refresh Timing
Use the exp claim to calculate how long the token is valid for. If tokens expire too quickly, decode a freshly-issued one and check exp minus iat — that tells you the configured token lifetime.
Frequently Asked Questions
What is a JSON Web Token (JWT)?
A JSON Web Token is a compact, URL-safe way to represent claims between two parties. It consists of three Base64URL-encoded parts separated by dots: a header (algorithm and token type), a payload (the claims — user ID, roles, expiry, etc.), and a signature used to verify the token was not tampered with. JWTs are most commonly used in authentication — after login, the server issues a JWT that the client sends with subsequent requests.
Why does this decoder say "signature is not verified"?
Verifying a JWT signature requires the secret key (for HMAC algorithms like HS256) or the public key (for RSA/ECDSA algorithms like RS256). This decoder runs entirely in your browser and has no access to any server-side keys. It can decode and display the header and payload, but it cannot confirm whether the token is genuine or has been tampered with. Signature verification must always be done server-side.
Is it safe to paste my JWT here?
All decoding runs entirely in your browser — the token is never sent to any server. For production tokens containing sensitive user data or long-lived credentials, the safest practice is to avoid pasting them into any online tool. Use this decoder for development tokens, test JWTs, or tokens you have already invalidated. For highly sensitive tokens, use a local library (e.g. jwt.io library, PyJWT, node-jsonwebtoken) instead.
What are the most common JWT claims?
Standard registered claims: iss (issuer — who created the token), sub (subject — who the token is about, usually a user ID), aud (audience — intended recipient), exp (expiration time — Unix timestamp), iat (issued at — when the token was created), nbf (not before — earliest valid time), jti (JWT ID — unique identifier). Custom claims can be anything the application needs: user roles, permissions, email, display name, etc.
What does "expired" mean in the decoder?
The exp claim stores the token's expiration as a Unix timestamp (seconds since 1 January 1970). The decoder compares this against the current time in your browser. If the current time is past exp, the token is flagged as Expired. An expired token should always be rejected by the server, even if the signature is valid.
What is the difference between HS256, RS256, and ES256?
These are JWT signing algorithms. HS256 (HMAC-SHA256) uses a single shared secret — the same key signs and verifies the token. This is simpler but requires both parties to share the secret. RS256 (RSA-SHA256) uses a public/private key pair — the server signs with the private key and clients verify with the public key. ES256 (ECDSA-P256-SHA256) is similar to RS256 but uses elliptic curve cryptography, producing smaller signatures. RS256 and ES256 are preferred for distributed systems where multiple services need to verify tokens without accessing the signing key.
Can I use this decoder for opaque tokens or session IDs?
No. Opaque tokens (like OAuth access tokens that are just random strings) and session IDs have no internal structure to decode. They are looked up in a database on the server side. This decoder only works with JWTs — tokens that have the three-part header.payload.signature format.