JWT Decoder

A JWT decoder reads a JSON Web Token and shows you what is inside it. Paste a token and our free tool splits it into its three parts, decodes the header and payload from Base64URL, and displays them as tidy, colour-coded JSON. Time claims such as exp, iat and nbf are converted into real dates in your time zone and in UTC, with a live status that tells you whether the token has expired or how long it remains valid. Each claim is explained in plain English. If the token uses HS256, HS384 or HS512, you can also verify its signature with your secret using the browser's built-in Web Crypto. Tokens and secrets never leave your browser.

How to use the JWT decoder

1. 1 Paste the tokenPaste a JWT into the box. A leading Bearer and any line breaks are removed automatically, or load the sample to try it out.
2. 2 Read the header and payloadThe decoded header shows the algorithm and token type. The payload shows the claims, with strings, numbers and booleans colour coded.
3. 3 Check the expiry statusThe status panel shows whether the token is valid, expired or not yet valid, and updates every second.
4. 4 Look up each claimThe claims list gives the meaning of registered claims such as iss, sub, aud and jti, and shows every time claim as a readable date.
5. 5 Verify the signatureFor HMAC tokens, enter the shared secret to confirm the token was signed with it and has not been changed. Tick the Base64 option if your secret is stored that way.

What a JSON Web Token is

A JSON Web Token, or JWT, is a compact way of passing a set of facts, called claims, between two systems in a form that can be checked for tampering. It is defined in RFC 7519 and is widely used for logins, single sign-on, API access tokens and OpenID Connect ID tokens. When you sign in to an app, the server may hand your browser a JWT that says who you are and when the token expires, and the browser then sends it with each request, usually in an Authorization header.

A token is three pieces of Base64URL-encoded text joined by dots. The first is the header, a small JSON object that names the signing algorithm and the token type. The second is the payload, a JSON object holding the claims. The third is the signature, which is calculated from the first two parts using a key. Change a single character in the header or payload and the signature no longer matches.

Decoding is not verification

The header and payload of a normal signed JWT are encoded, not encrypted. Base64URL is just a way of writing data in URL-safe characters, and anyone who has a token can read its contents, which is exactly what this tool does. Never put passwords, payment details or other secrets in a JWT payload, because they are visible to anyone who sees the token.

Reading a token tells you what it claims, not whether those claims are true. Anyone can create a token that says they are an administrator and expires in the year 2099. What makes a JWT trustworthy is the signature, checked by the receiving server with the correct key, together with checks on the issuer, audience and expiry. Use a decoder like this one for debugging and inspection, and always rely on a well-maintained JWT library to verify tokens in your own code.

Registered claims explained

RFC 7519 defines seven registered claim names. None are compulsory, but most systems use several of them, and libraries know how to check them. Their names are deliberately short to keep tokens small.

• iss (issuer): who created and signed the token, often the URL of an identity provider. Services should accept tokens only from issuers they trust.
• sub (subject): who the token is about, usually a user ID that is unique within that issuer.
• aud (audience): which application or API the token is intended for. A service should reject a token addressed to someone else, even if the signature is valid.
• exp (expiration time): the moment after which the token must not be accepted.
• nbf (not before): the moment before which the token must not be accepted.
• iat (issued at): when the token was created, useful for working out its age.
• jti (JWT ID): a unique identifier for the token, used to detect replays or to revoke a single token.

Reading exp, iat and nbf

Time claims in a JWT are written as NumericDate values: the number of seconds since midnight UTC on 1 January 1970, often called Unix time. A value such as 1793000000 is not readable at a glance, so the tool converts every time claim into a date in your own time zone and in UTC, and works out how long ago or how far ahead it is.

The status panel combines them. If nbf is in the future, the token is not valid yet. If exp has passed, it has expired. Otherwise it shows how much time is left and the token's total lifetime from iat to exp. A token with no exp claim never expires on its own, which is rarely a good idea for access tokens. If a time value is around a thousand times too large, it was probably written in milliseconds by mistake, a common bug that the tool points out.

Remember that the status is based on your computer's clock. Servers usually allow a small amount of leeway, often a minute or so, to cope with clocks that are slightly out of step, so a token that has only just expired here may still be accepted briefly elsewhere.

Verifying HS256, HS384 and HS512 signatures

Tokens signed with HS256, HS384 or HS512 use HMAC with a shared secret: the same secret both creates and checks the signature. Enter it in the verify box and the tool recalculates the signature over the header and payload using your browser's Web Crypto API, then compares it with the third part of the token. A match proves the token was signed with that secret and has not been altered since.

Some systems store the secret as Base64 rather than plain text. If verification fails with a secret you know is right, try ticking Secret is Base64-encoded. Tokens signed with RS256, PS256 or ES256 use a private key to sign and a public key to verify, so a shared secret will not work for them; this tool decodes them but checks HMAC signatures only. A token with alg set to none has no signature at all and should always be rejected.

HMAC is only as strong as its secret. Use a long, random value, at least as long as the hash output, so 32 bytes or more for HS256, and keep it on the server. A short or guessable secret can be found by trying candidates offline against a single captured token.

Keeping tokens safe while debugging

A valid access token is effectively a temporary password: whoever holds it can usually act as that user until it expires. This tool decodes and verifies everything inside your browser, and neither the token nor the secret is sent to a server or saved. Even so, it is good practice to debug with tokens from a test environment, or with tokens that have already expired, rather than live production credentials.

Take the same care elsewhere. Avoid pasting tokens into chat messages, support tickets or shared documents, mask them in screenshots and logs, and revoke or rotate anything you think may have leaked. If you are storing tokens in a web app, short expiry times, secure cookies and a strong Content Security Policy all reduce the damage if one is stolen.

Examples you can copy

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9      <- header
.eyJzdWIiOiJ1c2VyXzg0MjEiLCJleHAiOjE3OTMwMDAwMDB9   <- payload
.<signature>                              <- signature

Header:  {"alg": "HS256", "typ": "JWT"}
Payload: {"sub": "user_8421", "exp": 1793000000}

signature = Base64URL(
  HMAC-SHA256(
    secret,
    Base64URL(header) + "." + Base64URL(payload)
  )
)

Common mistakes to avoid

Frequently asked questions