JWT Decoder
Decode the header, payload, and signature of any JSON Web Token. See expiry status and time claims as ISO timestamps. Browser-only — your tokens never leave this page.
{
-700">"alg": -700">"HS256",
-700">"typ": -700">"JWT"
}{
-700">"sub": -700">"1234567890",
-700">"name": -700">"John Doe",
-700">"iat": 1516239022,
-700">"exp": 1516242622,
-700">"role": -700">"admin"
}- exp2018-01-18T02:30:22.000Z3034d ago
- iat2018-01-18T01:30:22.000Z3035d ago
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
About this tool
WRRK's JWT decoder splits the token at its dots, Base64URL-decodes the three segments, parses the header and payload as JSON, and pretty-prints them with syntax highlighting. Numeric time claims (iat, exp, nbf, auth_time) are converted to ISO 8601 timestamps and shown alongside a relative time so you can immediately see whether a token is fresh or stale.
The signature is displayed as raw Base64URL but not verified— verification requires the issuer's secret (for HS256) or public key (for RS256/ES256), which should live on a trusted server, never in a browser. For production verification use a library like jose, jsonwebtoken, or your auth provider's SDK. Everything runs locally — your tokens never touch a network.
How to decode a JWT (5 steps)
- Paste the JWT. Drop or paste any token in the form header.payload.signature into the left input.
- Read the header. See the signing algorithm (alg) and token type (typ). Confirms how the issuer signed the token.
- Inspect the payload. Standard claims (iss, sub, aud, exp, iat, nbf, jti) and custom claims appear with syntax highlighting.
- Check expiry. If 'exp' is set, a banner shows whether the token is still valid plus the ISO date and a relative time.
- Copy any segment. Use the inline Copy buttons to grab the header, payload, or signature for further work.
Use cases
- Debugging 401 errors by checking the exp claim of a stored token
- Inspecting Cognito, Auth0, Firebase, or Clerk session tokens locally
- Reading scopes and roles from access tokens during integration work
- Confirming the alg field hasn't silently switched to none or HS256
- Copying the kid header value to look up the right JWKS key
- Inspecting custom claims that drive feature flags or tenant routing
- Verifying iat / nbf clocks during cross-region time-skew debugging
Frequently asked questions
+−What is a JWT (JSON Web Token)?
A JSON Web Token is a compact string with three Base64URL-encoded segments separated by dots: header.payload.signature. The header describes the algorithm, the payload contains claims (like user ID, expiry, role), and the signature lets the issuer prove the token wasn't tampered with. JWTs are the standard for stateless authentication in modern APIs.
+−Is the JWT signature verified?
No — this tool only decodes the token for inspection. Verifying a JWT signature requires the issuer's secret (HS256) or public key (RS256/ES256), which should never leave a trusted server. For production verification, use a library like jose, jsonwebtoken, or your auth provider's SDK.
+−Is my token sent to a server?
No. Decoding happens entirely in your browser. Your JWT — including any access tokens, refresh tokens, or session credentials — never leaves your device. Safe to use with production tokens.
+−What does 'token expired' mean?
JWTs include an 'exp' claim (a Unix timestamp). When the current time is past that value, the token is considered expired and a properly configured server will reject it with 401 Unauthorized. The decoder shows a red warning banner if exp is in the past.
+−What are common JWT claims?
Standard registered claims: iss (issuer), sub (subject / user ID), aud (audience), exp (expiry), nbf (not before), iat (issued at), jti (token ID). Custom claims are added by the issuer — for example role, email, scope, tenant_id. The decoder converts iat / exp / nbf / auth_time to readable ISO timestamps automatically.
+−Why does the payload look like JSON?
Because it is JSON. The middle segment of a JWT is a JSON object encoded with Base64URL — once decoded, it's just regular JSON. Anyone with the token can read the payload, so never put secrets like passwords or PII inside a JWT.
+−What's the difference between HS256 and RS256?
HS256 uses a single shared secret to sign and verify (symmetric). RS256 uses a private key to sign and a public key to verify (asymmetric) — better for distributed systems where verifiers shouldn't be able to mint tokens. The 'alg' field in the JWT header tells you which is in use.