How to use the JWT Decoder
Decode a JWT in two steps:
1
Paste the JWT token
Paste any JWT — from an Authorization header, cookie, or clipboard — into the token input field. The token is decoded in real time with no button click needed.
2
Inspect the three sections
The header (rose), payload (violet), and signature (sky) panels show all decoded values. Timestamps are shown as UTC strings. Hover over any claim to reveal its copy button. Use 'Copy All' to export the full breakdown.
When to use this tool
Use the JWT decoder to inspect, debug, and understand JWT tokens:
- →Inspecting the claims inside a JWT returned by an authentication server to verify the user identity and roles
- →Debugging an expired or rejected JWT by reading the exp claim and comparing it to the current time
- →Reading the algorithm (alg) and key identifier (kid) from the header to understand how the token was signed
- →Verifying that a token contains the expected claims (sub, iss, aud, scope) before troubleshooting an API authorisation failure
- →Inspecting JWT tokens stored in browser cookies, localStorage, or Authorization headers during frontend development
- →Reading the payload of an OpenID Connect ID token to see which user attributes the identity provider included
Frequently asked questions
Q:Is it safe to paste my JWT into this tool?
Yes — all decoding runs entirely in your browser using JavaScript. The token is never sent to any server, stored in a database, or transmitted anywhere. The tool uses Base64url decoding to read the header and payload, which are only base64-encoded, not encrypted. However, treat any JWT as sensitive data — avoid pasting production tokens containing personal data into any online tool when you can avoid it. Use sample or development tokens for testing.
Q:Can this tool verify the JWT signature?
No — signature verification requires the secret key (for HMAC algorithms like HS256) or the public key (for RSA/ECDSA algorithms like RS256, ES256). This tool only decodes the header and payload, which are Base64url-encoded and require no key. Signature verification must be done server-side where the secret is stored securely. The signature panel shows the raw Base64url-encoded signature for inspection but cannot validate it without the key.
Q:What is the structure of a JWT?
A JWT consists of three Base64url-encoded parts separated by dots: Header.Payload.Signature. The header is a JSON object containing the algorithm (alg) and token type (typ). The payload is a JSON object containing the claims — assertions about the user or session. The signature is computed by signing the encoded header and payload with a secret or private key using the algorithm specified in the header. Only the signature provides authenticity — the header and payload are readable by anyone.
Q:Why are exp, iat, and nbf shown as UTC strings and numbers?
The exp (expiration), iat (issued at), and nbf (not before) claims are defined as NumericDate values — Unix timestamps in seconds since 1970-01-01T00:00:00Z. The raw number is shown because that is what the token actually contains and what your code compares against. The UTC string is shown alongside it as a human-readable translation because Unix timestamps are opaque to humans. Both representations are correct — the UTC string is derived directly from the Unix timestamp.
Q:What are the standard JWT registered claims?
The IANA JWT Claims Registry defines seven standard registered claims: iss (Issuer — who issued the token), sub (Subject — who the token is about, typically a user ID), aud (Audience — who the token is intended for), exp (Expiration Time — when the token expires), nbf (Not Before — the earliest time the token is valid), iat (Issued At — when the token was created), and jti (JWT ID — a unique identifier for the token, used to prevent replay attacks). All other claims are called private or public claims.
Q:What is the difference between a JWT and a session cookie?
A session cookie stores a random session ID on the client; the server maintains the session state (user data, permissions) in a database and looks up the session on every request. A JWT is self-contained — the server encodes the user's claims directly into the token, signs it, and sends it to the client. On subsequent requests, the server only needs to verify the signature to trust the claims without a database lookup. JWTs are stateless and work well for microservices and APIs; session cookies are stateful and easier to revoke immediately.