JWT Decoder and Verifier, Free and Private
Decode a JSON Web Token in your browser, read its claims and expiry, and optionally verify the signature with HS, RS or ES keys. Tokens and keys never leave your device.
0 characters, 0 bytes
0 characters, 0 bytes
About the JWT Decoder
The JWT Decoder reads a JSON Web Token (JWT) and shows what is inside it: the header, the payload with its claims explained in plain language, and the signature. Paste a token on the left and the decoded JSON appears on the right as you type. If the token has an expiry, a badge tells you whether it is still within its dates. You can also check the signature, as a separate and optional step, when you have the secret or public key.
Your token and any key you paste never leave your device. Decoding is plain text processing in the page, and signature verification uses the Web Crypto API built into your browser. Nothing is uploaded, logged or stored, and everything is gone when you close or reload the tab.
One point matters more than any other: decoding a token is not verifying it. A JWT payload is encoded, not encrypted, so anyone who holds the token can read it, and anyone can write a token that claims to be someone else. Only a signature check against the right key says the contents are genuine.
How to use it
Steps
- Paste a token into Token. A leading
Bearer, spaces and line breaks inside the token are ignored, so you can paste straight from anAuthorizationheader or a wrapped log line. - Read the Decoded output: the
headerandpayloadas formatted JSON. - Check the badge and the list of claims below it. Time claims are shown as a UTC date, a local date, and how long ago or how long until.
- To verify the signature, enter the secret (for an
HStoken) or the PEM public key (for anRSorEStoken) and press Verify signature. The result reads Signature verified, Signature does not match, or an explanation of what is wrong.
The three parts of a token
A JWT is three Base64url strings joined by dots: header.payload.signature.
- The header is a small JSON object. It names the signing algorithm in
algand usually the type intyp. It may also carrykid, the ID of the key that signed the token. - The payload is a JSON object of claims: statements about the subject, the issuer and the lifetime of the token.
- The signature is computed over the first two parts with a secret or a private key. This tool shows it exactly as written in the token, because it is binary data that means nothing as text.
Base64url is the URL-safe form of Base64. It uses - and _ in place of + and / and normally leaves out the = padding, so a token can sit in a URL or header unescaped. If you need to decode or produce such strings by hand, the Base64 Encoder has a URL-safe option.
Worked example
This is the sample token used on jwt.io:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
The header decodes to {"alg":"HS256","typ":"JWT"} and the payload to {"sub":"1234567890","name":"John Doe","iat":1516239022}. The claim list shows iat (issued at) as 2018-01-18 01:30:22 UTC. There is no exp, so the badge reads Valid and notes that the token has no expiry. Type the secret your-256-bit-secret and press Verify signature to get Signature verified; any other secret gives Signature does not match.
Registered claims
Claims explained here
iss(issuer): who created and signed the token.sub(subject): who the token is about, often a user ID.aud(audience): who the token is meant for. It may be one string or a list, and a service should reject tokens not addressed to it.exp(expiration time): the moment, in seconds since 1970, from which the token must no longer be accepted.nbf(not before): the moment before which the token must not be accepted.iat(issued at): when the token was created.jti(token ID): a unique ID, useful for revoking a token or detecting replay. The UUID Generator makes values suited to it.
Other claims, such as name or role, stay in the JSON only. A time claim that is not a number of seconds is shown as typed and marked as ignored.
What the badge checks
The badge reads Expired when exp is at or before the current time, Not yet valid when nbf is in the future, and Valid otherwise. A token without exp is Valid and the page says it never expires. This is a check of dates against your device clock, and nothing else. A forged token with a future exp is also Valid. The badge says nothing about who signed the token or whether it was altered.
Verifying a signature
Supported algorithms
The algorithm is always taken from the token's own header, never chosen from the key you paste.
- HS256, HS384, HS512: HMAC with a shared secret. Type it as text, or tick Secret is Base64 encoded if you hold the raw key bytes in Base64.
- RS256, RS384, RS512: RSA signatures. Paste the public key as PEM, starting
-----BEGIN PUBLIC KEY-----. - ES256, ES384: ECDSA on the P-256 or P-384 curve, with the same PEM public key format.
Tokens with alg set to none, and those using PS256, ES512 or EdDSA, are not supported here: the page says so and offers no Verify button. Keys cannot be fetched from a JWKS address; paste the key yourself.
Pitfalls worth knowing
- alg: none. The JWT standard permits unsecured tokens with an empty signature. A server that trusts the
algin the header can be tricked into accepting one with any claims. A server must decide which algorithms it accepts rather than obey the token. This tool decodes such a token and notes that it carries no signature, but will not call it verified. - Algorithm confusion. A server expecting RS256 that lets the token pick the algorithm may be sent an HS256 token signed with its own public key as the HMAC secret. The remedy is to pin the algorithm per key. That is why this tool takes the algorithm from the token and then insists on the matching kind of key: a secret for HMAC, a public key for RSA and ECDSA.
- Payload is public. Do not put passwords or personal data in a JWT unless it is also encrypted.
Privacy and secrets
Because the work happens in your browser, pasting a token here does not send it to a server. Even so, treat live credentials with care. Do not paste production secrets or long-lived tokens into any online tool you cannot inspect, and prefer short-lived test tokens and throwaway keys when you can. A public key is safe to share, but an HMAC secret is the same value that signs tokens. To create strong test secrets use the Password Generator, and to compare digests see the Hash Generator.
Related tools
Need to decode or encode the segments yourself? Use the Base64 Encoder. For random token IDs, see the UUID Generator. For test secrets, try the Password Generator, and for fingerprints of data, the Hash Generator.
Frequently asked questions
Is it safe to paste my JWT into this decoder?
Decoding runs in your browser, so the token is not sent to any server, and the page keeps nothing once you close the tab. Even so, avoid pasting live production tokens or secrets into any online tool you cannot inspect, and use short-lived test tokens when you can.
Does decoding a JWT prove it is genuine?
No. Anyone can write a token with any claims, and the payload is only Base64url encoded, not encrypted. A token is trustworthy only after its signature is checked against the correct key and its claims are checked by the server that receives it.
What does the Valid, Expired or Not yet valid badge mean?
It compares the exp and nbf claims with your device clock and nothing more. A forged or tampered token can still show Valid. Use the optional signature check for authenticity, and remember that a wrong device clock changes the badge.
Which signing algorithms can this tool verify?
It verifies HS256, HS384 and HS512 with a secret, RS256, RS384 and RS512 with a PEM public key, and ES256 and ES384 with a P-256 or P-384 public key. Tokens using none, PS256, ES512 or EdDSA can be decoded but not verified here.
Why does my token fail to decode?
A JWT must have exactly three dot-separated parts, each made of Base64url characters, and the header and payload must decode to valid UTF-8 JSON objects. The error names the faulty part and the position of the first bad character, which usually points to a copy mistake.
What is the difference between alg none and algorithm confusion attacks?
With alg none, a token claims to need no signature, and a careless server may accept forged claims. With algorithm confusion, an attacker switches an RSA token to HS256 and signs it with the public key as the secret. Both are prevented by fixing the accepted algorithms on the server.
Why are the dates in the claims shown in two forms?
The exp, nbf and iat claims are counts of seconds since 1 January 1970 UTC. The page converts each into a UTC date, which is the same everywhere, and into your local time, plus how long ago or how long until, so you can compare it with logs and server times.