How to Decode a JWT and Read Its Claims

A compact JWT normally looks like header.payload.signature. Each period separates one segment; the tool rejects input that does not contain exactly three segments. The header is a JSON object that commonly identifies the token type and signing algorithm, such as alg: HS256. The payload is another JSON object containing claims about a subject or event.

The signature covers the encoded header and encoded payload together. Its purpose is to reveal unauthorized changes when it is checked with the correct key. It does not hide the payload. Anyone who obtains the token can usually decode the first two parts, so passwords, private keys, and other secrets do not belong in ordinary JWT claims.

An empty or malformed segment can prevent useful verification even if some text remains readable. Copy the complete token without quotation marks, a Bearer prefix, trailing punctuation, or line breaks introduced by a document.

JWT segments use Base64URL rather than standard Base64. The URL-safe alphabet replaces + with - and / with _; padding = characters are commonly omitted. Those substitutions make a compact token easier to place in HTTP headers, URLs, cookies, and other contexts where standard Base64 punctuation may need special treatment.

Base64URL is an encoding, not encryption. Reversing it requires no password. The decoder restores missing padding, translates the URL-safe alphabet, decodes UTF-8 text, and then requires the header and payload to be JSON objects. Invalid alphabet characters, invalid UTF-8, or non-JSON content produces a focused error.

If you want to examine the encoding separately, the Base64 encoder and decoder has a URL-safe mode. Remember that decoding an individual segment there will not evaluate JWT time claims or check a signature.

Use a test token or a redacted development token whenever possible. Parsing and HMAC checking happen locally, but a bearer token may still grant access if it is exposed through screenshots, clipboard history, browser extensions, shared devices, or logs outside the page.

The exp claim is the expiration time, iat is the issued-at time, and nbf means the token should not be accepted before that time. These numeric dates are seconds from the Unix epoch. The tool converts them to your local date and adds a relative description. Its overall status checks nbf first, then exp; a missing numeric exp appears as No expiry.

The iss claim identifies the issuer, sub identifies the subject, and aud identifies the intended audience. An audience can be a string or a list. The table also recognizes jti, a token identifier. Displaying any of these values is not the same as approving them: your receiving application must require the expected issuer and audience and apply its own subject rules.

Clock values deserve context. A token can be within its date window yet be inappropriate for the current API, tenant, or operation. It can also be revoked or invalidated by server-side state even when its signature and visible dates look acceptable.

Decoding answers what the token says. Verification asks whether this exact token was signed with an approved key and algorithm. The page can verify HMAC signatures for HS256, HS384, and HS512 by applying the entered shared secret to the original encoded header and payload. A successful result means the signature matches that secret; it does not automatically approve every claim.

RSA, ECDSA, and PSS tokens can be decoded here, but this page does not verify those signature families. They require the correct public key and algorithm-specific checks. Production validation should also restrict accepted algorithms rather than trusting whatever alg value the token announces.

A header declaring alg: none says the token is unsigned. The tool displays a warning and does not present that token as verified. Do not accept an unsigned token where authentication or authorization depends on the claims, even if the payload looks plausible.

A production access or session token can function like a temporary credential. Pasting it into a server-side decoder may send it over the network, place it in request logs, expose it to analytics, or leave it in service storage. You often cannot confirm the operator's retention controls from the page itself.

This decoder works in the browser and does not upload the token or secret. That reduces network exposure, but it does not make careless handling safe. Prefer synthetic tokens for debugging, avoid shared computers, inspect installed extensions, and revoke a real token if you believe it was disclosed.

You can read a JWT without its signing key because the header and payload are encoded, not encrypted. You need the proper key to verify its signature. Use the claims as clues, not proof, and reject alg: none for trusted access decisions.

For an HMAC test, paste the token, enter the known Secret, and require Signature verified in addition to suitable exp, nbf, iss, sub, and aud values.