My Tool Studio
Developer

JWT Decoder

This JWT decoder splits a JSON Web Token into its header, payload and signature, shows the JSON, and verifies the signature when you give it a key. Paste a token and it decodes as you type, with each part color-coded and every claim explained in plain words, including iat, nbf and exp as dates with relative times. To verify, paste the shared secret for HS256, HS384 or HS512, or a public key as PEM, X.509 certificate, JWK or JWKS for RS, PS, ES and EdDSA tokens. The Encode and sign tab builds test tokens from your own header and payload and can create a throwaway key pair. Verification uses the Web Crypto API, so tokens and keys never leave your browser.

Always freeNo sign upRuns in your browser

How to use

01

Paste your token

Paste the full JWT into the JSON Web Token box; a Bearer prefix is fine. Try sample loads a signed HS256 token and its secret, so you can see a verified result straight away.

02

Verify with a secret or public key

Paste the secret, ticking Secret is Base64-encoded if your provider gives it that way, or paste the issuer's public key, certificate, JWK or JWKS. A green or red notice says whether the signature matches.

03

Read the claims or build a token

Claims explained lists every header and payload field with its meaning, and time claims as dates. Switch to Encode and sign to create a test token, then click Open in decoder to check it.

Why JWT Decoder

JWT structure and the standard claims

A JWT is three base64url strings joined by dots: header.payload.signature. The header says which algorithm signed the token, such as HS256 or RS256. The payload holds the claims, which are simple key and value pairs about the user and the token. The signature is computed over the first two parts, so changing even one character of the header or payload makes it invalid.

Because the header and payload are only encoded, never put secrets such as passwords in them. RFC 7519 defines a short list of registered claims that most libraries understand. Your auth server can add any other claims it needs, such as roles or an email address.

ClaimNameMeaning
issIssuerWho created and signed the token
subSubjectWho the token is about, usually a user ID
audAudienceWhich service the token is meant for
expExpiration timeUnix time after which the token is invalid
nbfNot beforeUnix time before which the token is invalid
iatIssued atUnix time when the token was created
jtiJWT IDUnique ID, used to stop a token being replayed

Keys you can verify with

The key box accepts the formats identity providers and libraries hand out. The algorithm comes from the token's header, so you only paste the key.

Algorithm in the headerPaste thisExample source
HS256, HS384, HS512The shared secret, as text or Base64Your app's JWT_SECRET setting
RS256, RS384, RS512, PS256, PS384, PS512PEM public key, X.509 certificate, JWK or JWKSAuth0, Okta, Microsoft Entra ID, Firebase
ES256, ES384, ES512PEM public key, JWK or JWKSApple, Google and many API gateways
EdDSA (Ed25519)PEM public key or JWKNewer services; needs a browser with Ed25519 support
noneNothing: the token is unsigned and must be rejectedMisconfigured or forged tokens

Common questions

Is a JWT encrypted or just encoded?
A normal JWT is only encoded and signed, so anyone who has the token can read the header and payload, which is exactly what this page does. Encrypted tokens (JWE) have five parts and cannot be read without the key. The tool tells you when it sees one.
What is the difference between decoding and verifying a JWT?
Decoding reads the header and payload, which needs no key. Verifying checks the signature with the secret or public key, which proves the token came from the key holder and was not changed. This page does both: it decodes as you paste and verifies once you add a key. Your server must still verify every token itself.
Why does my JWT show as expired right after login?
Usually the issuing server's clock or settings are off. exp is a Unix time in UTC, so a server clock that runs fast, or a very short lifetime, makes a fresh token look expired. Compare iat with the current time in the Time claims list, and allow a small leeway for clock skew in your verification library.
What is the difference between HS256 and RS256?
HS256 signs with HMAC and SHA-256 using one shared secret, so every service that verifies tokens must hold that secret. RS256 signs with an RSA private key and verifies with the matching public key, so verifiers never need the private key. The alg value in the header shows which one a token uses.
Does this JWT decoder verify the signature?
Yes, when you give it a key. Paste the shared secret for HS256, HS384 or HS512, or for RS, PS, ES and EdDSA tokens a PEM public key, an X.509 certificate, a JWK or the issuer's JWKS. The check runs with the jose library and the Web Crypto API in your browser. Expiry is shown separately, so an expired token can still have a valid signature.
Is it safe to paste a real JWT into this page?
Yes. Decoding and verification happen with JavaScript in your browser, and the token and key are never transmitted or stored. Still, treat production tokens and secrets like passwords, and rotate any you have shared in chat or a bug report.
Why does my JWT fail to decode?
A JWT needs three parts separated by dots, and the error message says how many parts it found. A partial copy, a trailing quote or comma from a log line, or a stray character inside a part will also break decoding. Copy the token again from its source.
What do the iat, nbf and exp claims mean in a JWT?
All three are Unix timestamps in seconds. iat is when the token was issued, nbf is the earliest time it may be used, and exp is when it stops being valid. The tool shows each one as a date so you do not have to convert them.
Will editing the decoded JWT payload change my token?
No. The decoder is read-only, and changing a claim would invalidate the signature anyway. To experiment, use the Encode and sign tab with your own test secret or key, then decode the new token. For real tokens with different claims, ask the issuing server.
Where do I find the public key to verify a JWT?
Most identity providers publish a JWKS, a JSON list of public keys, at an address such as /.well-known/jwks.json, which is also listed in their OpenID configuration. Open it in your browser, copy the JSON and paste it into the key box; the kid in the token header picks the right key. A single PEM key or certificate works too.

More Developer tools

View all