JWT Decoder

Paste a JSON Web Token into the Encoded token box and the JWT decoder reads it as you type. The three parts appear in colour under the box, the header and payload show as formatted JSON, and a table lists every claim with what it means. Times such as exp and iat are shown as dates in your own time zone, with a note such as in 2 h or 3 days ago.

A badge next to Payload says whether the token has expired, and a yellow box lists anything that looks risky. Paste a secret or a public key under Verify signature to check that the token is genuine. Switch the mode to Encode and sign to build a new token from your own header and payload.

When the page opens, a sample HS256 token is already in the box, so you can see how everything looks. You can paste with or without the word Bearer in front; it is removed for you, and so are spaces and line breaks.

A JSON Web Token (JWT) is a short piece of text that carries facts about a user or a system, called claims, in a form that can be checked. It has three parts joined by dots: header.payload.signature. Each part is written in Base64URL, a form of Base64 that is safe in web addresses because it uses - and _ instead of + and /, and leaves out the = padding.

The header, shown in red, is a small JSON object that names the signing algorithm in alg, often the type in typ, and sometimes a key ID in kid. The payload, in purple, holds the claims: who the token is about, who issued it, when it expires and anything else the issuer added. The signature, in blue, is made from the first two parts with a secret or a private key.

This is what a “jwt decode token online” search is usually after: turning the unreadable eyJ… text into plain JSON. Decoding simply undoes the Base64URL step. No key is needed and nothing is decrypted, because nothing was encrypted in the first place.

Most of the time you just want to see what is inside a token: which user it belongs to, which roles or scopes it carries and when it expires. A JWT decoder online should show that the moment you paste, without an account or a button, and here the result updates as you type.

Copy the header or payload as formatted JSON with the Copy buttons. If the payload is long or deeply nested, the JSON Formatter helps you read it. If the token came from a link such as ?token=…, it may still be percent-encoded; decode it with URL Encode first.

The claims table is where the JWT decoder saves the most time. It lists each claim with a short meaning and its value, covering the standard claims (RFC 7519) and common OpenID Connect ones such as scope, roles, nonce and sid.

Times in a JWT are NumericDate values: seconds since 1 January 1970 UTC. A value like 1767225600 means nothing at a glance, so for exp, nbf, iat, auth_time and updated_at the table shows the date and time in your browser's time zone and how far away it is, such as in 45 min or 2 days ago. For any other Unix time, the Timestamp Converter does the same job.

Next to the word Payload, a badge sums up exp: Valid for 59 min in green, or Expired 3 h ago in red. The badge only reads exp from your device's clock. It does not check the signature, so a token can look valid and still be fake.

Decoding shows what a token says. Verifying proves who said it. Anyone can create a token with any payload, for example “admin”: true, and it decodes perfectly. Only the signature tells you whether it was made by someone who holds the right key, and whether a single character has changed since.

To verify, paste the key into the Verify signature box below the token. The check runs as soon as there is a key, using the algorithm from the token's header. You get ✓ Signature verified in green or ✗ Invalid signature in red. If the key cannot be used at all, for example a key of the wrong type for the algorithm, a yellow message explains why.

A jwt verify signature online check is only as good as the key you give it. Take the secret from your own configuration, or the public key from the issuer's published key set, never from the token itself. Your API must still run the same check on the server for every request; a page like this is for debugging and learning. The Algorithm menu normally says From token (HS256) or similar; you can override it for tests.

Tokens with alg HS256, HS384 or HS512 are signed with HMAC and a shared secret: the same secret signs and verifies. Paste it into the Secret box and the result appears at once. A JWT decoder with secret support has to know how the secret is written, so there is a checkbox: The secret is Base64 / Base64URL encoded.

Leave it off when your configuration holds plain text, such as a passphrase. Tick it when the secret is a random key written in Base64 or Base64URL, as many frameworks and identity services store it. If verification fails with a secret you are sure is right, this checkbox is the first thing to try.

The JWT algorithms standard (RFC 7518) asks for an HMAC key at least as long as the hash: 256 bits for HS256, 384 for HS384 and 512 for HS512. If your secret is shorter, the result still shows, with a note saying the secret is shorter than the standard allows. Short or guessable secrets can be cracked from a single captured token, so use a long random one.

Tokens from login services usually use a key pair: the issuer signs with a private key and publishes the public key so anyone can verify. For RS, PS, ES and EdDSA tokens the key box accepts four forms, and it works out which one you pasted.

A key set is the quickest way to do a jwt decode with public key check against a real provider. Open the issuer's key set, often at /.well-known/jwks.json, copy the whole JSON and paste it. The page picks the key whose kid matches the token's header, which is shown next to the Algorithm menu. With no match it uses the first key made for that algorithm, and the note under the result names the key used, such as Key “abc123” of 3 from the key set.

Certificates are common in older enterprise setups, where the signing key is shared as a .cer or .pem file. Paste the whole -----BEGIN CERTIFICATE----- block and the public key is read out of it. The certificate's dates and chain are not checked; only its key is used.

Each algorithm family signs in its own way, and the page uses the browser's Web Crypto for all of them. A JWT decoder with signature checking for every common algorithm saves you from writing test code just to see whether a key and a token belong together.

RSA keys work for both RS and PS tokens, but the token's alg decides the method, and a signature made one way will not verify the other way. EdDSA here means Ed25519; on an older browser without Ed25519 in Web Crypto, you will see a message that the key could not be used.

Web Crypto reads public keys in the SPKI format (BEGIN PUBLIC KEY) and private keys in PKCS#8 (BEGIN PRIVATE KEY). Some tools still write older formats: BEGIN RSA PUBLIC KEY, BEGIN RSA PRIVATE KEY or BEGIN EC PRIVATE KEY. If you paste one of those, the page says so and shows the OpenSSL command that converts it:

You do not need a key to read a token. Base64URL is an encoding, not encryption, so anyone who gets a copy of a token can read every claim in it. A jwt decode without secret works on any signed token, and that is by design: the signature protects the token against changes, not against being read.

This has a practical side. Never put passwords, card numbers, national ID numbers or other private data in a JWT payload. If the page sees claim names that suggest such data, such as password, secret, card, ssn or cvv, it warns you. Put in only what the receiver needs, such as a user ID and roles, and look up the rest on the server.

Treat a token like a password while it is valid, too. Anyone who holds it can use it until it expires, which is why short expiry times matter.

Almost every JWT you meet is a JWS, a signed token with three parts. There is also JWE, an encrypted token with five parts: header, encrypted key, initialization vector, ciphertext and authentication tag. Its content really is secret and can only be read with the right decryption key.

If you paste a JWE, the page recognises the five parts, shows the header, which is not encrypted and names the algorithms (for example alg RSA-OAEP and enc A256GCM), and tells you the payload can only be read with the private key. It does not decrypt JWE tokens.

Switch the mode to Encode and sign and the page becomes a JWT decoder and encoder in one. Write the header and payload as JSON on the left, pick an algorithm, enter a key and press Sign token. The alg in the header is set for you from the Algorithm menu, so the header only needs typ and anything extra, such as kid.

The payload starts with a sample: sub, name, admin, iat and an exp one hour later. Buttons under it save typing: iat = now sets the issued time, exp in 1 hour, exp in 1 day and exp in 7 days set the expiry, and add jti inserts a random unique ID.

For HS algorithms, type a secret or press Random 256-bit secret to get a strong one from your browser's random generator, written in Base64URL with the matching checkbox ticked. For RS, PS, ES and EdDSA, paste a private key in PKCS#8 PEM (BEGIN PRIVATE KEY) or a private JWK. The finished token appears with Copy token and Decode it buttons. Decode it opens the token in the decoder and, for HS tokens, fills in the secret, so you can watch it verify.

Signing here is meant for tests, demos and debugging. Keep real production signing keys on your server, in a secret store, and let your server create real tokens.

Everything this page does, it does with the browser's built-in Web Crypto and its own code. Once the page has loaded, it needs no server to decode, verify or sign. Tokens and keys are not sent anywhere, and no request goes out when you paste.

That is what most people want from a JWT decoder offline: it keeps working when the network drops, and it leaks nothing. Load the page, and you can disconnect and keep decoding and verifying. It is a web page, not an installable app, so keep the tab open. A key set has to be pasted in by you; the page does not fetch keys from URLs.

Decoding and verifying happen in your browser with Web Crypto. Tokens, secrets and keys are never uploaded, never logged and never put in the address bar, and the page stores nothing, not even your choices.

Even so, think twice before pasting live tokens or production keys into any page outside your own systems, this JWT decoder included. A test token or an expired one is the safer thing to paste. If you have ever shared a production secret somewhere you do not control, rotating it is the careful step.

Need a strong HMAC secret? The Password Generator makes long random ones, and the Hash Generator computes HMAC-SHA256 values you can compare by hand. The Base64 Encode and Decode tool converts a secret between text and Base64. The UUID Generator gives you values for jti claims, and the Diff Checker compares two decoded payloads side by side.