JWT Decoder

About this tool

JWT Decoder is a browser-only tool for decoding and inspecting JSON Web Tokens. Paste a JWT — the three base64URL dot-separated segments produced by any standard authentication system — and the tool decodes it as you type. Summary cards show the signing algorithm (alg), the token type (typ) and a status: Expired or Not expired when the payload has a numeric exp claim, or No exp when it does not. The header and payload appear as indented JSON panels, with time claims such as iat, nbf and exp left as raw Unix seconds, and the signature segment is shown as-is under Signature · not verified. No secret key is required or accepted — this is decode-only, not a verification tool, and a future expiry does not prove a token is valid. All processing runs in your browser with no network requests, making it safe to inspect real access tokens from OAuth2 flows, API gateways, or JWT-based session systems.

Why use it

• Instant Expiry Check: A status card reads Expired, Not expired or No exp by comparing the exp claim with your device's clock — the first thing to rule out when debugging a 401 Unauthorized error.

• Readable Header and Payload: Header and payload are decoded into separate, indented JSON panels, making it easy to find a claim such as sub, scope or roles without reading raw base64.

• Zero Secret Key Exposure Risk: This tool decodes only. It accepts no signing secret and performs no cryptographic verification, so there is no risk of accidentally entering a private key or symmetric secret into an online form. Verification should always happen server-side with your secret.

• Malformation Detection: Tokens that do not have exactly three segments, or whose header or payload is not base64URL-encoded JSON, are rejected with an error message instead of half-decoded output.

• Algorithm Shown Up Front: The alg value from the header — RS256, HS256, ES256, none or others — appears in its own card. Seeing none or an unexpected algorithm in a token you receive is an important security signal.

• Unicode-Safe Decoding: Header and payload are decoded as UTF-8, so names and claims with accented or non-Latin characters display correctly.

How to use

1. Paste the full JWT string — all three dot-separated segments — into the JSON Web Token field.
2. The header and payload panels fill in as you type or paste; the Decode token button re-runs the decode.
3. Check the Algorithm, Type and Status cards: Status reads Expired, Not expired or No exp based on the exp claim and the current time.
4. Read claims such as sub, scope, iat and exp in the payload panel; time claims are shown as raw Unix seconds, which the Unix Time Converter can turn into dates.
5. If you see 'Invalid JWT: expected 3 parts' or 'Could not decode JWT parts', check for a missing segment or a leftover Bearer prefix.
6. Click Clear to empty the field and the decoded panels.

When it helps

• Debugging a 401 Unauthorized API error by checking whether the token is expired or has the wrong scope.
• Inspecting the claims in a JWT returned by an OAuth2 authorization server to confirm the correct scopes and subject were granted.
• Verifying that a newly issued token from your authentication service contains the expected custom claims before testing downstream services.
• Reading the alg field of a received token to confirm the signing algorithm matches your verification configuration.
• Checking the exp and nbf timestamps of a token when debugging a clock-skew related authentication failure.
• Quickly understanding the structure of a JWT format used by a third-party service before implementing a parser in code.

Examples

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c3JfMTIzIiwibmFtZSI6IkFsaWNlIiwic2NvcGUiOiJyZWFkOm9yZGVycyIsImlhdCI6MTcxNjA3NjgwMCwiZXhwIjoxNzE2MDgwNDAwfQ.<signature>

Algorithm: RS256 · Type: JWT · Status: Expired
Header:
{
  "alg": "RS256",
  "typ": "JWT"
}
Payload:
{
  "sub": "usr_123",
  "name": "Alice",
  "scope": "read:orders",
  "iat": 1716076800,
  "exp": 1716080400
}
Signature · not verified: <signature>

eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJhZG1pbiIsInJvbGUiOiJhZG1pbiJ9.

Algorithm: none · Type: JWT · Status: No exp
Header:
{
  "alg": "none",
  "typ": "JWT"
}
Payload:
{
  "sub": "admin",
  "role": "admin"
}
Signature · not verified: (empty)

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c3JfMTIzIiwiZXhwIjoxNzE2MDc2ODAwMDAwfQ.c2lnbmF0dXJl

Algorithm: HS256 · Type: JWT · Status: Not expired
Payload:
{
  "sub": "usr_123",
  "exp": 1716076800000
}
The 13-digit exp is in milliseconds, so the token looks valid until the year 56350.

Tips

• If the token starts with 'Bearer ', remove that prefix before pasting — the tool expects just the three-segment JWT string without the Authorization header scheme prefix.
• Check the alg field in the header first when debugging unexpected verification failures — if it says 'none' or a different algorithm than your server expects, that is the root cause.
• Compare the exp timestamp to the current time in your browser's DevTools console with Date.now()/1000 to calculate exactly how many seconds remain before expiry.
• If a token payload contains a roles or scope claim, copy it out to verify that the user's permission set matches what the API endpoint requires before looking at other potential causes of a 403.
• JWT header typ: 'at+JWT' (access token) versus typ: 'JWT' indicates an OAuth2 Access Token per RFC 9068 — useful when debugging token type mismatches in OAuth2 resource server validation.

Frequently Asked Questions

Glossary

JWT

JSON Web Token — a compact, URL-safe token format defined in RFC 7519 consisting of a base64URL-encoded header, payload, and signature separated by dots.

Claims

Key-value pairs in the JWT payload that assert facts about the subject or the token itself. Registered claims (iss, sub, exp, iat, nbf, aud, jti) have standardised meanings; custom claims are application-defined.

Base64URL

A variant of Base64 encoding that uses - instead of + and _ instead of / and omits padding, making the output safe for use in URLs and HTTP headers without percent-encoding.

exp Claim

The expiration time claim — a Unix epoch timestamp (seconds since 1970-01-01 00:00:00 UTC) after which the JWT must not be accepted. Absence means the token does not expire.

JWS

JSON Web Signature — the signed form of a JWT where the payload is base64URL-encoded and readable. Distinct from JWE (JSON Web Encryption) where the payload is encrypted and opaque.

alg

The algorithm header parameter identifying the cryptographic algorithm used to sign the token — for example RS256 (RSA + SHA-256), HS256 (HMAC-SHA256), ES256 (ECDSA + SHA-256), or none (unsigned).