JWT Decoder

Decode JSON Web Tokens to inspect header, payload, and signature. View claims, expiration time, and token structure.

JWT Token

A user reports "401 Unauthorized" and the logs show their token. You need to know: is it expired, what user does it claim to belong to, was it issued by your auth server or someone else? Paste a JWT here and see the answer in two clicks — header algorithm, payload claims with timestamps converted to readable dates, and the signature segment preserved as raw bytes for reference. Nothing leaves the browser. Validation (signature verification, audience check) is a server-side concern; this tool is for inspection during debugging.

A JWT (RFC 7519) is three base64url-encoded segments joined by dots: header.payload.signature. The header says what algorithm signed it, the payload carries arbitrary claims as JSON, and the signature proves the token hasn't been tampered with. The sections below cover the structure, the standard claims you'll keep seeing, and the "none" algorithm vulnerability that keeps making the security news.

JWT anatomy

Header (segment 1)

JSON like {"alg":"HS256","typ":"JWT"}. The alg field tells the verifier which algorithm to use. The typfield is informational. base64url-encoded so it's URL- and cookie-safe.

Payload (segment 2)

JSON containing standard registered claims (iss, sub, aud, exp, iat, nbf, jti) plus any custom fields your app needs (roles, tenant ID, etc.). Not encrypted — anyone with the token reads the payload in plain JSON.

Signature (segment 3)

Cryptographic signature computed as HMAC-or-sign(base64url(header) + "." + base64url(payload), key). Proves the token came from someone who owns the key and that the header+payload haven't been modified. Cannot be verified without the corresponding key.

Standard JWT Claims

Claim	Full name	Meaning
iss	Issuer	Which service issued the token
sub	Subject	Who the token represents (usually user ID)
aud	Audience	Intended consumer service or API
exp	Expiration	Unix timestamp after which the token is invalid
nbf	Not Before	Unix timestamp before which the token is invalid
iat	Issued At	Unix timestamp when the token was created
jti	JWT ID	Unique token identifier for replay-prevention lists

Algorithms: HS256 vs RS256 vs ES256 vs "none"

HS256, HS384, HS512 (HMAC-SHA)

Symmetric: the same shared secret signs and verifies. Simple to deploy when one team owns both sides, but the verifier needs the signing key. Don't use HS* if any third party needs to verify your tokens — they'd need the secret too.

RS256, RS384, RS512 (RSA + SHA)

Asymmetric: issuer signs with a private key, anyone with the public key can verify. Standard for OIDC and public APIs because you can publish the public key via JWKS without leaking signing capability. Larger signatures than HMAC.

ES256, ES384, ES512 (ECDSA)

Asymmetric with elliptic curves. Smaller keys and signatures than RSA at equivalent security (ES256 ≈ RS3072). Increasingly the default for modern auth providers (Auth0, Firebase optionally).

EdDSA (Ed25519) — newest, fastest

Asymmetric. Modern curve, deterministic, immune to timing attacks. Use where supported.

`alg: "none"` — the trap

RFC 7519 allows an unsigned token where alg is the string "none" and the signature segment is empty. Libraries that accept this without explicit opt-in have a critical vulnerability: an attacker can forge any payload, set alg="none", and pass verification. Always pin the expected algorithm on the verifier; never trust the alg from the token header alone.

How to Use

Paste your JWT into the input field.
The decoder parses in real time as you type.
Review the header for the signing algorithm and token type.
Review the payload for claims and embedded user data.
Timestamp claims (exp, iat, nbf) are converted to readable dates.
Use Copy to grab the decoded JSON for further inspection.

Examples

The decoder splits on dots, base64url-decodes the first two segments, and renders each as JSON. The signature segment is preserved verbatim — verification needs the signing key and happens on the server.

Example 1: Decode an HS256 token

A typical three-segment token signed with HMAC-SHA256, carrying standard claims.

Input

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkFsaWNlIiwiaWF0IjoxNzEzNjAwMDAwfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Output

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

Payload:
{
  "sub": "1234567890",
  "name": "Alice",
  "iat": 1713600000
}

Example 2: Token with an expired exp claim

The exp claim is rendered as a date. If the date is in the past, the payload still decodes — expiration is a server-side enforcement, not a parsing rule.

Input

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ1c2VyXzQyIiwiZXhwIjoxNjAwMDAwMDAwfQ.dummy

Output

Payload:
{
  "sub": "user_42",
  "exp": 1600000000  // 2020-09-13 12:26:40 UTC (expired)
}

JWT segment reference

Header — alg (HS256/RS256/EdDSA), typ (JWT), optional kid for key rotation.
Payload — registered claims iss, sub, aud, exp, iat, jti.
Signature — HMAC or asymmetric signature over base64url(header) + "." + base64url(payload).
Security tip — reject alg: none at the verifier and pin expected algorithm on each endpoint to block key-confusion attacks.

Security note — read before pasting production tokens

JWTs are not encrypted.The payload is plain JSON behind a base64url wrapper. Don't put passwords, API keys, or PII in claims.
This tool does not verify signatures. Decoding shows you the claims regardless of whether the signature is valid, missing, or forged.
Don't paste production access tokens into random online tools. This one runs entirely in your browser, but a habit is a habit — for live user-session tokens, decode in your own scripts.
Pin the algorithm on the verifier. Never accept whatever alg the token claims; specify the expected algorithm explicitly to avoid the alg=none bypass.

Related guides

JWT tokens explained for developers

The structure, common claims, signature algorithms, refresh-token patterns, and where JWTs are the wrong tool.

Base64 encoding: the complete guide

JWTs are three base64url segments joined by dots — once you understand base64url, JWT structure decodes itself.

Frequently Asked Questions

Q: Can I decode expired JWT tokens?

Yes. Decoding reveals the payload regardless of whether exp is in the past — expiration is a server-side enforcement check, not a parsing rule. The tool decodes the base64url header and payload independent of validity. Theexp claim is shown as a readable date so you can see at a glance whether the token is fresh or stale.

Q: Does this validate JWT signatures?

No. The tool only decodes and displays the header and payload. Signature verification requires the signing key (for HS*) or the public key (for RS*/ES*). Use a server-side library (jose, jsonwebtoken, pyjwt) and an explicit algorithm pin to verify in production.

Q: What's the difference between HS256 and RS256?

HS256 is symmetric — the same secret signs and verifies. RS256 is asymmetric — a private key signs, a public key verifies. Use HS256 when one team owns both ends; use RS256 (or ES256 / EdDSA) when third parties or distributed services need to verify without holding signing capability. OIDC publishes RS256 public keys via JWKS.

Q: Is "alg: none" safe to allow?

No — it's the most famous JWT vulnerability. A library that honors alg: "none" accepts unsigned tokens, letting an attacker forge any payload by setting alg="none" and an empty signature. Always specify expected algorithms explicitly on the verifier; reject anything else.

Q: What JWT claims are recognized?

All standard registered claims: iss (Issuer), sub (Subject), aud (Audience), exp (Expiration), nbf (Not Before), iat (Issued At), jti (JWT ID). Custom claims display as-is. Timestamp claims are auto-converted to readable dates.

Q: How can I tell if my JWT has expired?

Find the exp claim in the decoded payload — the tool converts it to a readable date so you can compare against the current time. If the date is in the past, the token is expired (assuming the server checks exp). Also check nbf (Not Before) and iat (Issued At) for clock-skew issues.

Base64 Encoding Explained: What It Is and When to Use It8 min read JWT Tokens Explained: A Developer's Guide to JSON Web Tokens10 min read HTTP Status Codes: A Complete Reference Guide for Developers11 min read

JWT Decoder

Decode JSON Web Tokens to inspect header, payload, and signature. View claims, expiration time, and token structure.

JWT Token

JWT anatomy

Header (segment 1)

JSON like {"alg":"HS256","typ":"JWT"}. The alg field tells the verifier which algorithm to use. The typfield is informational. base64url-encoded so it's URL- and cookie-safe.

Payload (segment 2)

Signature (segment 3)

Standard JWT Claims

Claim	Full name	Meaning
iss	Issuer	Which service issued the token
sub	Subject	Who the token represents (usually user ID)
aud	Audience	Intended consumer service or API
exp	Expiration	Unix timestamp after which the token is invalid
nbf	Not Before	Unix timestamp before which the token is invalid
iat	Issued At	Unix timestamp when the token was created
jti	JWT ID	Unique token identifier for replay-prevention lists

Algorithms: HS256 vs RS256 vs ES256 vs "none"

HS256, HS384, HS512 (HMAC-SHA)

RS256, RS384, RS512 (RSA + SHA)

ES256, ES384, ES512 (ECDSA)

Asymmetric with elliptic curves. Smaller keys and signatures than RSA at equivalent security (ES256 ≈ RS3072). Increasingly the default for modern auth providers (Auth0, Firebase optionally).

EdDSA (Ed25519) — newest, fastest

Asymmetric. Modern curve, deterministic, immune to timing attacks. Use where supported.

`alg: "none"` — the trap

How to Use

Paste your JWT into the input field.
The decoder parses in real time as you type.
Review the header for the signing algorithm and token type.
Review the payload for claims and embedded user data.
Timestamp claims (exp, iat, nbf) are converted to readable dates.
Use Copy to grab the decoded JSON for further inspection.

Examples

Example 1: Decode an HS256 token

A typical three-segment token signed with HMAC-SHA256, carrying standard claims.

Input

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkFsaWNlIiwiaWF0IjoxNzEzNjAwMDAwfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Output

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

Payload:
{
  "sub": "1234567890",
  "name": "Alice",
  "iat": 1713600000
}

Example 2: Token with an expired exp claim

The exp claim is rendered as a date. If the date is in the past, the payload still decodes — expiration is a server-side enforcement, not a parsing rule.

Input

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ1c2VyXzQyIiwiZXhwIjoxNjAwMDAwMDAwfQ.dummy

Output

Payload:
{
  "sub": "user_42",
  "exp": 1600000000  // 2020-09-13 12:26:40 UTC (expired)
}

JWT segment reference

Header — alg (HS256/RS256/EdDSA), typ (JWT), optional kid for key rotation.
Payload — registered claims iss, sub, aud, exp, iat, jti.
Signature — HMAC or asymmetric signature over base64url(header) + "." + base64url(payload).
Security tip — reject alg: none at the verifier and pin expected algorithm on each endpoint to block key-confusion attacks.

Security note — read before pasting production tokens

JWTs are not encrypted.The payload is plain JSON behind a base64url wrapper. Don't put passwords, API keys, or PII in claims.
This tool does not verify signatures. Decoding shows you the claims regardless of whether the signature is valid, missing, or forged.
Don't paste production access tokens into random online tools. This one runs entirely in your browser, but a habit is a habit — for live user-session tokens, decode in your own scripts.
Pin the algorithm on the verifier. Never accept whatever alg the token claims; specify the expected algorithm explicitly to avoid the alg=none bypass.

Related guides

JWT tokens explained for developers

The structure, common claims, signature algorithms, refresh-token patterns, and where JWTs are the wrong tool.

Base64 encoding: the complete guide

JWTs are three base64url segments joined by dots — once you understand base64url, JWT structure decodes itself.