A JWT (JSON Web Token) is an authentication token made of three dot-separated parts: header, payload, and signature. The first two parts are just Base64URL-encoded JSON, so anyone can decode them and read the contents. Paste a token into this tool and it expands the header and payload neatly, converts time claims like exp (expiry), iat (issued at), and nbf (not before) into readable dates, and even tells you whether the token is currently valid.
JWTs are mainly used for stateless authentication, where the session is not stored on the server. When you log in, the server packs your information into the payload and issues a signed token; on every subsequent request you send it in the Authorization header, and the server only needs to verify the signature to confirm your identity. This tool is handy when you need a quick look at claims like sub (the subject, or user identifier), iss (the issuer), and aud (the intended audience) carried in the payload.
When you debug an API and find yourself chasing down "why am I getting a 401?", checking the token's expiry time is often the first step. This tool decodes that information entirely inside your browser, so you can safely inspect a real authentication token without sending it to any external server. Keep in mind it only decodes the header and payload and does not verify the signature, so use it strictly for inspecting contents.
How to Use
- 1
Paste the token
Paste the JWT string, which starts with eyJ, into the input box.
- 2
Run the decode
Click the 'Decode' button and the JSON contents of the header and payload are expanded.
- 3
Check the claims
Time values like exp, iat, and nbf are shown as KST dates, and a validity badge tells you whether the token is expired.
- 4
Copy
Use the copy button to grab the header and payload JSON for further analysis in other tools.
When It's Useful
Track down a 401 auth error
When an API suddenly returns 401, paste the token and check whether exp has passed first. The expiry badge lets you judge it instantly.
Inspect login token contents
Expand the payload to confirm that a token issued by your backend carries the intended claims, such as sub, role, and permissions.
Check the alg algorithm
Use the alg field in the header to tell whether it is HS256 (symmetric key) or RS256 (asymmetric key) and match your verification method accordingly.
Debug front-end tokens
Decode a token stored in the browser locally and safely, without sending it to an external site, to check its issued and expiry times.
Tips
- sub is the user identifier, iss is the issuer, and aud is the intended audience — all standard registered claims.
- A token whose exp has passed is rejected by the server. It is the first value to check when you hit a 401 error.
- The alg field in the header tells you the signing algorithm (HS256, RS256, etc.). A token with alg set to none has no signature and is dangerous.
- exp, iat, and nbf are Unix timestamps in seconds. nbf (not before) means the token is not valid before that time.
- A JWT payload is merely encoded, not encrypted. Do not put sensitive information like passwords in the payload.
- This tool does not verify the signature, so to judge whether a token has been forged you must verify it on the server with the secret or public key.
FAQ
Does it verify the signature too?
No. This tool decodes the header and payload to show their contents but does not verify the signature. Judging a token's authenticity must be done on the server with the secret or public key.
Is the token sent to a server?
No. Decoding happens only in your browser and the token is never sent anywhere. You can safely inspect real authentication tokens.
How is expiry determined?
It compares the payload's exp (a timestamp in seconds) with the current time to show whether the token is expired. If your device clock is off, the result can differ too.
Why does decoding fail?
It can fail if the string is not a JWT, part of it was truncated during copying, or whitespace and line breaks got mixed in. Make sure the dot-separated parts are intact.
Can I edit the payload to make a new token?
This tool is a read-only decoder. Even if you change the payload, without a valid signature the server will reject it, so re-issuing a token must be done on the server.
How are the header and payload encoded?
Both are Base64URL-encoded JSON. Unlike standard Base64, it uses - instead of + and _ instead of /, and omits the trailing = padding. This tool automatically restores the standard form before decoding.
Why is the signature part not shown?
The third part, the signature, is a verification value generated with a secret key, so decoding it does not yield human-readable information. This tool is meant for inspecting contents, so it shows only the header and payload.
Which is better, a JWT or a session cookie?
There is no single answer. A JWT keeps no state on the server, which helps with scaling, but it is hard to invalidate immediately after issuing. A session can be revoked on the server right away but needs a store. Choose based on your requirements.