🔐 JWT Decoder
By ToolNimba Editorial Team · Updated 2026-06-19
This tool only decodes the token. It does not verify the signature, so never trust an unverified token's contents for authorization.
Paste a JWT above and press Decode.
This JWT decoder takes a JSON Web Token and shows you what is inside it. Paste the token and it splits on the dots, Base64URL-decodes the header and payload, and pretty-prints both as readable JSON. Timestamp claims like exp and iat are converted to human dates, and the signature is shown exactly as it appears. The decoding happens entirely in your browser, so the token you paste never leaves your device. One important note: this tool decodes but does not verify the signature, so it cannot tell you whether a token is genuine.
What is the JWT Decoder?
A JSON Web Token (JWT) is a compact, URL-safe way to carry a set of claims between two parties, most often used for authentication and authorization in web APIs. A signed JWT has three parts separated by dots: the header, the payload, and the signature. Each of the first two parts is a JSON object that has been Base64URL-encoded, and the third part is a cryptographic signature over the first two. Written out, a token looks like header.payload.signature.
The header usually states the signing algorithm (the "alg" field, such as HS256 or RS256) and the token type ("typ": "JWT"). The payload holds the claims: statements about the user or the token itself. Some claim names are reserved and standardised, such as "sub" (subject), "iss" (issuer), "aud" (audience), "exp" (expiry), "iat" (issued at), and "nbf" (not before). The time-based claims are stored as Unix timestamps, that is the number of seconds since 1 January 1970 UTC, which this tool converts into readable dates so you can see at a glance when a token was issued or when it expires.
Decoding a JWT is not the same as verifying it. Anyone can read the header and payload because Base64URL is just an encoding, not encryption, so a JWT should never carry secrets like passwords. The signature is what proves the token has not been tampered with and was issued by a party holding the signing key. Verifying it requires that key and the matching algorithm, which a client-side decoder does not have. That is why this tool deliberately shows the signature as-is without checking it: it is built for inspecting and debugging tokens, not for deciding whether to trust one.
When to use it
- Debugging an API login flow by inspecting which claims your auth server actually puts in the token.
- Checking the exp claim to see whether a token has already expired and why a request is being rejected.
- Confirming the roles, scopes, or user id encoded in a token while building or testing a backend.
- Teaching or learning how JWTs are structured by seeing the header, payload, and signature pulled apart.
How to use the JWT Decoder
- Copy the JWT from your network tab, cookie, Authorization header, or environment file.
- Paste it into the input box. You can press Decode or use the bundled sample token to try it out.
- Read the pretty-printed header and payload, and check the decoded iat, exp, and nbf dates.
- Use the Copy buttons to grab the header or payload JSON. Remember the signature is shown but not verified.
Formula & method
Worked examples
Decode the classic jwt.io sample token.
- Token: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
- Split on the dots into three parts.
- Base64URL-decode part 1 to get the header JSON.
- Base64URL-decode part 2 to get the payload JSON.
Result: Header {"alg":"HS256","typ":"JWT"}, payload {"sub":"1234567890","name":"John Doe","iat":1516239022}
Turn the iat timestamp into a readable date.
- The payload above has "iat": 1516239022.
- iat is in Unix seconds, so multiply by 1000 for milliseconds: 1516239022000.
- new Date(1516239022000) gives the moment in time.
- Format it as UTC for a stable, timezone-independent reading.
Result: iat 1516239022 is Thu, 18 Jan 2018 01:30:22 GMT
Spot an expired token from its exp claim.
- Suppose the payload contains "exp": 1700000000.
- Convert: new Date(1700000000 * 1000) is Tue, 14 Nov 2023 22:13:20 GMT.
- Compare that to the current date and time.
- If now is later than the exp date, the token has expired.
Result: An exp of 1700000000 means the token expired on 14 Nov 2023
The three parts of a signed JWT
| Part | Contents | Encoding |
|---|---|---|
| Header | Algorithm (alg) and token type (typ) | Base64URL of JSON |
| Payload | Claims about the user and the token | Base64URL of JSON |
| Signature | Cryptographic proof over header and payload | Base64URL of raw bytes |
Common registered (reserved) JWT claims
| Claim | Name | Meaning |
|---|---|---|
| iss | Issuer | Who created and signed the token |
| sub | Subject | Who the token is about, often a user id |
| aud | Audience | Who the token is intended for |
| exp | Expiration time | Unix time after which the token is invalid |
| nbf | Not before | Unix time before which the token is not valid |
| iat | Issued at | Unix time the token was created |
| jti | JWT ID | A unique identifier for the token |
Common mistakes to avoid
- Thinking a decoded token is a verified token. Decoding only reads the contents. It does not prove the token is genuine. Authorization decisions must verify the signature on the server with the correct key.
- Putting secrets in the payload. The payload is only Base64URL-encoded, which anyone can decode. Never store passwords, card numbers, or other secrets in a JWT, signed or not.
- Misreading the exp and iat values as milliseconds. JWT time claims are in seconds since the Unix epoch, not milliseconds. Multiply by 1000 before passing them to JavaScript Date, or the date lands in 1970.
- Assuming alg:none is safe. A header of "alg": "none" means the token is unsigned. Some libraries used to accept these by default, which let attackers forge tokens. Always reject none in production.
Glossary
- JWT
- JSON Web Token, a compact token format that carries signed claims as three Base64URL parts: header, payload, and signature.
- Claim
- A single statement inside the payload, such as a user id (sub) or an expiry time (exp).
- Base64URL
- A URL-safe variant of Base64 that uses - and _ instead of + and / and usually drops the = padding, used to encode the JWT parts.
- Signature
- A cryptographic value over the header and payload that proves the token has not been altered and came from the signing party.
- alg
- The header field naming the signing algorithm, for example HS256 (HMAC with SHA-256) or RS256 (RSA with SHA-256).
- Unix timestamp
- A point in time expressed as the number of seconds since 1 January 1970 UTC, used by the exp, iat, and nbf claims.
Frequently asked questions
What is a JWT decoder?
A JWT decoder splits a JSON Web Token on its dots and Base64URL-decodes the header and payload so you can read the JSON claims inside. This one also converts time claims like exp and iat to readable dates. It decodes but does not verify the signature.
Does this tool verify the JWT signature?
No. It only decodes and pretty-prints the header and payload and shows the signature as-is. Verifying a signature needs the secret or public key and the matching algorithm, which a browser tool does not have. Never trust an unverified token for authorization.
Is it safe to paste my token here?
The decoding runs entirely in your browser with JavaScript, so the token is never sent to any server. That said, a real JWT is a credential, so avoid pasting production tokens into any online tool and prefer test tokens when you can.
How do I read the exp date in a JWT?
The exp claim is a Unix timestamp in seconds. Multiply it by 1000 and pass it to a Date to get a calendar date and time. This decoder does that for you and flags whether the token has already expired.
Why does my token have three parts separated by dots?
A signed JWT is structured as header.payload.signature. The header and payload are Base64URL-encoded JSON, and the signature protects them. A token with a different number of parts is not a standard signed JWT.
Can anyone read the data inside a JWT?
Yes, for a standard signed JWT. The payload is only Base64URL-encoded, not encrypted, so anyone with the token can decode and read its claims. That is why you must never place secrets such as passwords in a JWT payload.