JWT Decoder: How to Decode a JSON Web Token

To decode a JWT, split the token at its two dots and Base64URL-decode the first two parts: the first is the header and the second is the payload, both plain JSON. You do not need the secret key to read a JSON Web Token, because the payload is encoded, not encrypted.

Our free JWT decoder does the splitting and decoding for you and turns the exp, nbf and iat timestamps into readable dates. Decoding only shows what a token says. Proving the token is genuine requires verifying the signature with a key, which this guide also explains.

What a JSON Web Token contains

JSON Web Tokens are defined in RFC 7519. The common signed form (JWS, RFC 7515) has three Base64URL-encoded parts joined by dots: header.payload.signature. Here is a complete example token:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkphbmUgRG9lIiwiaWF0IjoxNzY3MjI1NjAwLCJleHAiOjE3NjcyMjkyMDB9.aWbbNTzOs7uEA6DpB2uelr-7-QYf31QJPnzbaTj3aSA

Decoding the first part gives the header, which names the signing algorithm and the token type:

{
    "alg": "HS256",
    "typ": "JWT"
}

Decoding the second part gives the payload, a set of statements called claims:

{
    "sub": "1234567890",
    "name": "Jane Doe",
    "iat": 1767225600,
    "exp": 1767229200
}

The third part is the signature: binary data, Base64URL-encoded, computed over the first two parts. It cannot be decoded into anything readable. Because the header JSON begins with {" followed by a letter, almost every JWT starts with the characters eyJ, which makes tokens easy to spot in logs.

Standard JWT claims

RFC 7519 registers seven claim names. All are optional, but most identity providers use them:

Claim	Name	Meaning
iss	Issuer	Who created and signed the token
sub	Subject	Who the token is about, usually a user ID
aud	Audience	Which service the token is meant for
exp	Expiration time	The token must be rejected after this time
nbf	Not before	The token must be rejected before this time
iat	Issued at	When the token was created
jti	JWT ID	A unique identifier for the token

The time claims are NumericDate values: seconds since the Unix epoch (1970-01-01 00:00:00 UTC). In the example, iat 1767225600 is 2026-01-01 00:00:00 UTC and exp 1767229200 is one hour later. Convert any of these values with the Unix timestamp converter, or read our guide to Unix time.

Decoding vs verifying a JWT

Anyone can decode a JWT. Only someone with the right key can verify it. The signature is calculated over the exact text header.payload: with HS256 that is an HMAC using SHA-256 and a shared secret, and with RS256 or ES256 it is an RSA or ECDSA signature checked with the issuer's public key. If a single character of the header or payload changes, verification fails.

That is why a decoded payload proves nothing on its own. An attacker can edit "role": "user" to "role": "admin" and re-encode it, and a decoder will happily display the result. Your server must verify every token before trusting its claims.

How to use the JWT Decoder

1. Open the JWT decoder and paste the token into the JWT token box, up to 8,192 characters. Remove any Bearer prefix first.
2. The Header and Payload panels fill in automatically as formatted JSON. Use each panel's Copy button to copy it.
3. The Signature panel shows the raw Base64URL value and its hex bytes, clearly labeled as unverified.
4. If the payload has exp, nbf or iat, the decoder lists them as Expiration, Not Before and Issued At dates in UTC. Compare Expiration with the current time to see whether the token has expired.
5. If the token is malformed, you see an error such as "JWT must contain header, payload, and signature segments."

To decode a token locally instead, Node.js can do it in one line: JSON.parse(Buffer.from(token.split('.')[1], 'base64url').toString()).

Security tips and common mistakes

• Treat tokens as passwords. A valid JWT grants access until it expires. Our decoder sends the token to our server to decode it and never asks for a key, so use test or expired tokens, never production or customer tokens, in this or any online tool.
• Never put secrets in the payload. The payload is only Base64URL-encoded, as our guide to Base64 encoding explains. If claims must stay confidential, use an encrypted JWE token (RFC 7516), which has five parts instead of three.
• Pin the algorithm when verifying. Configure your library with the exact algorithm you expect and reject "alg": "none". Unsecured tokens end with a dot and an empty signature. RFC 8725 collects these JWT best practices.
• Check more than the signature. Validate exp, nbf, iss and aud too. A small leeway of a few seconds to minutes for clock skew is normal.
• Watch for copy errors. Quotes, line breaks, a truncated end or the Bearer prefix all produce "invalid segments" errors.

If you only need one part, you can also decode it by hand: swap - for + and _ for /, then paste it into the Base64 converter, and format the resulting JSON with the JSON formatter.

Frequently asked questions

Can you decode a JWT without the secret key?

Yes. The header and payload are only Base64URL-encoded, so anyone can read them without a key. The key is needed only to create or verify the signature.

Is a JWT encrypted?

A standard signed JWT is not encrypted; its contents are readable by anyone who has the token. Encrypted tokens use the separate JWE format defined in RFC 7516.

How do I check if a JWT is expired?

Decode the payload and read the exp claim, which is a Unix timestamp in seconds. If it is earlier than the current time, the token has expired.

What is the difference between decoding and verifying a JWT?

Decoding turns the header and payload back into JSON so you can read them. Verifying recalculates the signature with the secret or public key to prove the token was issued by a trusted party and has not been altered.

Is it safe to paste a JWT into an online decoder?

Only for test tokens. A live token works like a password until it expires, so decode production tokens locally or in your own backend.

What are the three parts of a JWT?

The header, which names the signing algorithm; the payload, which holds the claims; and the signature, which protects the first two parts from tampering. They are separated by dots.