JWT Decoder / Verifier

Continue in the tool

JWT and authentication

JWT and Authentication: Structure and Limits

A JWT looks like an opaque string, but it is just text encoded into 3 parts, visible to anyone who knows where to look. Understanding what each part does, and especially what the signature protects and what it does not, avoids the most common mistake: treating the token as if it were encrypted when it is only encoded.

The 3 Parts of a Token and What Each One Guarantees

RFC 7519 defines a JWT as 3 segments separated by dots: header, payload and signature, each encoded in Base64URL. The example token `eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...` decodes its header to `{"alg":"HS256","typ":"JWT"}` and its payload to `{"sub":"1234567890","name":"John Doe","iat":1516239022}`, where `iat` is a Unix timestamp in seconds, not milliseconds.
Base64URL is just encoding, not encryption: anyone holding the token decodes the header and payload without needing any secret, exactly like this decoder does in the browser. A secret or sensitive value placed directly in a claim, like a card number or password, stays readable to anyone intercepting the token, which is why the payload should hold only identifiers and permissions, never confidential data.
The part that actually protects against tampering is the signature: with HS256, it is an HMAC-SHA256 over the concatenated header and payload, computed with a shared secret only the server knows; changing 1 character of the payload invalidates the signature on verification. The real historical trap was the `alg: none` vulnerability, where a misconfigured server accepted a completely unsigned token just because the header said so, which is why validating the expected algorithm server-side is mandatory, never trusting the `alg` that arrives inside the token itself.

One Token, Three Readings

Decoded header

Input: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
Expected output: {"alg":"HS256","typ":"JWT"}

`alg` declares the signing algorithm, but the server must validate that value, never accept it blindly.

Decoded payload

Input: eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ
Expected output: {"sub":"1234567890","name":"John Doe","iat":1516239022}

`sub` identifies the user, `iat` marks when the token was issued in seconds since 1970; none of these fields is secret.

HS256 signature

Input: header.payload assinados com o segredo compartilhado
Expected output: SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

This is an HMAC-SHA256; recomputing it with the same secret and comparing byte for byte is the only valid way to verify the token.

Full tool FAQ

Does the tool decode the header and payload of a JWT?

Yes. This kind of utility is meant to show the token segments in a readable format for debugging and learning, and when applicable it can also help with local HMAC signature checks.

What is a JWT?

Is decoding a JWT the same as validating a JWT?

Is the payload of a JWT secret?

What do `exp`, `nbf` and `iat` mean in a JWT?

If I can read a JWT, can I trust it?

Are JWTs and traditional server sessions the same thing?

Is it safe to paste a real JWT into any website just to decode it?

Frequently asked questions

Is it safe to put sensitive data inside a JWT payload?

Not with standard encoding: Base64URL hides nothing, anyone can decode the payload without any secret; real confidentiality would require a JWE (JSON Web Encryption), a different standard from the common JWS that most systems use for authentication.

Why does an expired JWT still decode normally?

Because decoding and validating are separate steps: the token remains valid Base64URL after expiring, so the header and payload always decode; it is the server that must compare the `exp` claim against the current time and reject the request, the decoder itself does not enforce that rule.

What is the practical difference between HS256 and RS256?

HS256 uses a single shared secret for both signing and verifying, so any service that verifies tokens could also forge them; RS256 uses an RSA key pair, the private key signs and stays only with the issuer, the public key verifies and can circulate freely without the risk of forging a new token.

Why does a JWT payload usually include `iat` and `exp`?

`iat` (issued at) records when the token was born and `exp` (expiration) marks how long it stays valid, both as a Unix timestamp in seconds; without `exp`, a stolen token would remain valid forever, so this claim is the main lifetime boundary for a session JWT.

Next steps

Continue in the tool

Open full tool

JWT and authentication

JWT and Authentication: Structure and Limits

The 3 Parts of a Token and What Each One Guarantees

RFC 7519 defines a JWT as 3 segments separated by dots: header, payload and signature, each encoded in Base64URL. The example token `eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...` decodes its header to `{"alg":"HS256","typ":"JWT"}` and its payload to `{"sub":"1234567890","name":"John Doe","iat":1516239022}`, where `iat` is a Unix timestamp in seconds, not milliseconds.

Base64URL is just encoding, not encryption: anyone holding the token decodes the header and payload without needing any secret, exactly like this decoder does in the browser. A secret or sensitive value placed directly in a claim, like a card number or password, stays readable to anyone intercepting the token, which is why the payload should hold only identifiers and permissions, never confidential data.

The part that actually protects against tampering is the signature: with HS256, it is an HMAC-SHA256 over the concatenated header and payload, computed with a shared secret only the server knows; changing 1 character of the payload invalidates the signature on verification. The real historical trap was the `alg: none` vulnerability, where a misconfigured server accepted a completely unsigned token just because the header said so, which is why validating the expected algorithm server-side is mandatory, never trusting the `alg` that arrives inside the token itself.

One Token, Three Readings

Decoded header

Input: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
Expected output: {"alg":"HS256","typ":"JWT"}

`alg` declares the signing algorithm, but the server must validate that value, never accept it blindly.

Decoded payload

Input: eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ
Expected output: {"sub":"1234567890","name":"John Doe","iat":1516239022}

`sub` identifies the user, `iat` marks when the token was issued in seconds since 1970; none of these fields is secret.

HS256 signature

Input: header.payload assinados com o segredo compartilhado
Expected output: SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

This is an HMAC-SHA256; recomputing it with the same secret and comparing byte for byte is the only valid way to verify the token.

Full tool FAQ

Does the tool decode the header and payload of a JWT?

Yes. This kind of utility is meant to show the token segments in a readable format for debugging and learning, and when applicable it can also help with local HMAC signature checks.

What is a JWT?

Is decoding a JWT the same as validating a JWT?

Is the payload of a JWT secret?

What do `exp`, `nbf` and `iat` mean in a JWT?

If I can read a JWT, can I trust it?

Are JWTs and traditional server sessions the same thing?

Is it safe to paste a real JWT into any website just to decode it?

Frequently asked questions