JWT Decoder: Decode & Verify Tokens Free

A JWT decoder reads the three parts of a JSON Web Token and shows you the header, payload and time claims as formatted JSON. This free tool also verifies HS256, HS384 and HS512 signatures when you supply the HMAC secret, so developers can debug login problems and check a token in seconds.

What Is a JSON Web Token?

A JSON Web Token (JWT) is a compact string that carries claims about a user or a session, defined in the open standard RFC 7519. It has three segments separated by dots: header.payload.signature. Each of the first two segments is JSON encoded as base64url, and the third is a signature over the first two.

The header

The header describes the token. It normally holds alg (the signing algorithm, such as HS256) and typ (usually JWT). A header that starts with eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 decodes to an HS256 token.

The payload

The payload holds the claims. Common registered claims include sub (the subject), iss (the issuer), aud (the audience), iat (issued at), nbf (not before) and exp (expiration). The three time claims are Unix timestamps in seconds.

The signature

The signature proves the header and payload were not changed after signing. With HMAC algorithms, the issuer signs with a shared secret, and anyone who holds that same secret can recompute the signature and compare. Remember that base64url is an encoding, not encryption. Anyone can read a standard JWT payload, so secrets and passwords do not belong in it.

How to Use the JWT Decoder and Verifier

You can decode a token in one step and verify its signature in two. Here is the full flow:

1. Paste your token into the Paste JWT box. It must look like header.payload.signature. Select Load Sample if you want a ready-made token to try first.
2. Select Decode. The Header, Payload, Time Claims and Signature (raw) sections appear below the buttons.
3. Use the Copy button beside Header or Payload to copy that JSON to your clipboard.
4. To check the signature, type the shared key into the HMAC Secret field. It is optional for decoding and needed only for verification.
5. Select Verify Signature. The tool reports either "Signature is VALID for the given secret." or "Signature is INVALID."
6. Select Clear to empty the fields before checking another token.

Editing the token or secret after a check clears the old verification message, so you never read a stale result against new input.

Worked Example: Reading a Token Step by Step

Suppose a login API returns a token whose header decodes to {"alg":"HS256","typ":"JWT"}. The payload decodes to {"sub":"1234567890","name":"Jane Doe","iat":1735682400,"exp":1735689600}.

After you select Decode, the Time Claims section converts those numbers into readable UTC dates:

• iat: 2024-12-31T22:00:00.000Z
• exp: 2025-01-01T00:00:00.000Z

The difference is 7,200 seconds, so this token lives for two hours. If your current time is after the exp date, the line ends with "(expired)". If it is before, the line ends with "(unexpired, signature not verified)". That second note matters: a token can look fresh and still be forged until you verify it.

Now enter the secret the issuing server used and select Verify Signature. A VALID message means the header and payload match the signature for that exact secret. An INVALID message means something differs: the secret, the algorithm, or the token content.

How Do You Read the Results?

Each output section answers a different debugging question, and knowing what to look for saves time.

Header: which algorithm signed this?

Check alg first. Verification here works for HS256, HS384 and HS512. Tokens signed with RSA or ECDSA algorithms (RS256, ES256 and similar) still decode and display, but this tool cannot verify them and shows an unsupported algorithm message instead. A token with alg set to none has no signature at all, and you should not trust it for authentication.

Payload: are the claims what your app expects?

Compare sub, iss and aud with what your API requires. Many "401 Unauthorized" errors come from a token issued for a different audience or by a different issuer than the server accepts. Also look for missing custom claims such as roles or tenant IDs.

Time Claims: is the token inside its window?

A healthy access token usually has an exp a few minutes to a few hours after iat. If exp is already past, request a new token. If nbf is in the future, the token is not valid yet, which often points to a clock difference between the issuer and the verifier. Clock skew of a minute or two is common, and many libraries allow a small leeway for it.

Signature: valid or invalid?

VALID means the HMAC matches. INVALID is not always a forged token. The most frequent causes are a wrong secret, a secret with a trailing space or line break, and a token that was copied with a missing character.

Who Uses a JWT Decoder and When?

A decoder is the fastest way to see what a token actually contains, without writing code. These are the typical situations:

• Debugging authentication: A front-end developer sees a 401 and needs to know whether the token expired or carries the wrong audience.
• Testing an API integration: A back-end developer confirms that the claims their service issues match the documentation.
• Checking a signing secret: A DevOps engineer verifies that staging and production use the keys they think they do.
• Security review: A tester inspects tokens for sensitive data such as emails or internal IDs sitting in a readable payload.
• Learning: A student sees how header, payload and signature relate by loading the sample and changing one character.

If your search was "jwt decode verify signature" for a library such as PyJWT, note that libraries offer an option to skip verification and read claims only. The Decode button is that read-only step. Verify Signature is the full check against your secret.

Best Practices, Common Mistakes and Troubleshooting

Most failed decodes and failed verifications trace back to a handful of input problems.

Error: "A compact JWT must have exactly 3 dot-separated base64url segments."

The token has too few or too many dots. Remove surrounding quotes, and delete the word "Bearer" and the space after it if you copied an Authorization header. Encrypted tokens (JWE) have five segments and will not decode here.

Error: "Header is not valid base64url" or "Payload is not valid base64url."

The segment contains characters outside the base64url set, such as spaces, plus signs or equals signs, or a character was lost when copying. Copy the token again from the source. If you need to inspect a plain base64 string that is not a token, try the Base64 encode and decode tool.

Error: "Header and payload must both be valid JSON objects."

The decoded text is not JSON, or it is JSON but not an object (for example, an array or a bare number). A standard JWT has objects in both places.

Message: "Provide both the JWT and the HMAC secret."

Verify Signature needs both fields filled. Decode needs only the token.

Signature invalid even though the secret looks right

• Check for a trailing space or newline in the secret field.
• Confirm the algorithm: an HS512 token will not match a secret used with HS256 settings elsewhere.
• Check whether your service stores the secret as base64 text but signs with the decoded bytes. This tool uses the text you type as the secret.
• Make sure the token was not edited after signing. Changing even one character in the payload breaks the signature.

Once a payload is readable, you can tidy or compare it using the code beautifier or the code diff tool, which helps when you need to spot what changed between two issued tokens. If a front end cannot call your API at all, the cause may be cross-origin rules rather than the token, so review your headers with the CORS header generator.

Limitations to Know About

This tool is built for inspection and HMAC checking, so keep its scope in mind.

• It verifies HS256, HS384 and HS512 only. It does not verify RSA or ECDSA signatures.
• A valid signature does not mean the token should be accepted. Your application must still check exp, nbf, iss and aud, and must pin the algorithm it expects.
• The expired or unexpired note compares the token's exp to your current device time, so a wrong system clock gives a wrong note.
• The Time Claims section shows only iat, nbf and exp when they are numeric values.
• Treat live production secrets with care. For routine debugging, use test keys and short-lived tokens whenever you can.

Decode Your Token Now

You now know what each part of a JWT means, how to spot an expired or mismatched token, and how to confirm an HMAC signature with the right secret. Paste your token into the box above, select Decode, and add your secret to run Verify Signature. For more utilities like this one, browse the web developer tools collection.