What Is a JWT and How Do You Decode It?

If you've worked with a login system or an API, you've seen strings like eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjMifQ.…. That's a JSON Web Token (JWT), defined in RFC 7519.

The three parts

A JWT is three pieces joined by dots:

1. Header: which algorithm signed the token, for example {"alg": "HS256", "typ": "JWT"}.
2. Payload: the claims, statements about the user or session.
3. Signature: computed over the first two parts with a secret or private key.

Header and payload are JSON encoded with base64url, a URL-safe variant of base64. That's why every JWT starts with eyJ: it's the encoding of {".

Common claims

Claim	Meaning
iss	Issuer: who created the token
sub	Subject: usually the user ID
aud	Audience: which service should accept it
exp	Expiration time
nbf	Not valid before
iat	Issued at
jti	Unique token ID

Times are Unix timestamps in seconds since 1 January 1970 UTC. exp: 1767225600 means 1 January 2026, 00:00 UTC. The Unix timestamp converter translates such values.

Encoded is not encrypted

The payload of a normal JWT (a JWS) is readable by anyone who has the token. Never put passwords or sensitive personal data into it. There is an encrypted variant (JWE), recognizable by five parts instead of three, but most tokens you'll see are signed only.

What the signature guarantees

• HS256/384/512 use a shared secret. Anyone who can verify can also create tokens.
• RS256, PS256, ES256, EdDSA use a key pair. The server signs with a private key; anyone can verify with the public key, often published as a JWKS (JSON Web Key Set).

A valid signature means the token hasn't been modified since it was signed. It doesn't mean the token is still valid in time: check exp and nbf too.

Decode a token

1. Open the JWT decoder.
2. Paste the token. A leading Bearer from an Authorization header is removed automatically.
3. The header and payload appear as formatted JSON, with the claims listed in a table. exp, iat and nbf are shown in your local time, with a status such as "expires in 2 hours" or "expired 3 days ago".
4. To verify the signature, enter the secret (for HS algorithms) or the public key, certificate or JWKS (for RS, PS, ES and EdDSA).

Decoding and verification happen in your browser; the token is never sent anywhere. Still, treat a live token like a password: whoever holds it can act as that user until it expires.

Red flags when inspecting tokens

• "alg": "none": an unsigned token. Servers must never accept these.
• Very long lifetimes: an exp weeks away increases the damage if a token leaks.
• Sensitive data in the payload: email addresses or roles are common; anything more personal shouldn't be there.
• Missing aud: a token issued for one service might be accepted by another.

Formatting the payload

For large payloads, copy the decoded JSON into the JSON viewer to browse it as a tree.

Frequently asked questions

Can I change a claim and reuse the token? You can edit the payload, but the signature won't match anymore, and any correctly configured server will reject the token.

Where should apps store JWTs? For browser apps, a common recommendation is an HttpOnly cookie, which JavaScript can't read, so a cross-site scripting bug can't steal it directly. Tokens in localStorage are readable by any script on the page.