JWT Decoder & Inspector

JWT Decoder & Inspector: Understand Your Tokens

JSON Web Tokens (JWT) sit at the heart of nearly every modern API and many login flows. They often look like meaningless characters but carry header and payload in plain text. This JWT decoder splits your token into its three parts, decodes header and payload and shows the contained claims as readable JSON, including understandable rendering of timestamps such as exp and iat. Everything runs locally in your browser, your token is not transmitted to our server.

Specification: the anatomy of a JWT (RFC 7519)

A JWT is defined in RFC 7519. It has three dot-separated, base64url-encoded parts in the form header.payload.signature:

• Header: holds the algorithm (alg, e.g. HS256) and the type (typ).
• Payload: holds the actual claims such as sub, name, iat and exp.
• Signature: secures integrity. Note: this decoder does not verify the signature, it only shows the decoded content.

The three parts are base64url-encoded, meaning the JSON is plain text. Anyone who holds the token can read the header and payload; a JWT is not encryption, it is a signed, readable format.

A worked example. This really generated and verifiable token uses HS256:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkphbmUgRG9lIiwiaWF0IjoxNzAwMDAwMDAwLCJleHAiOjE3MDAwODY0MDB9.lH5ouZL2oVqxvPKH6npv5cBimEhFEGSRLmDh3XItZYE

The first part decodes to {"alg":"HS256","typ":"JWT"}, the second to {"sub":"1234567890","name":"Jane Doe","iat":1700000000,"exp":1700086400}. The decoded inspector shows iat (14 Nov 2023 22:13:20 UTC) and exp (15 Nov 2023 22:13:20 UTC) as readable dates plus a status hint about whether the token is still valid or expired.

The algorithm in the header: HS256 vs. RS256

The alg header names the signing method. HS256 is a symmetric scheme (HMAC-SHA-256): issuer and verifier share a single secret password. RS256 is asymmetric (RSA): the issuer signs with its private key and anyone can verify with the public key. The tool shows you the algorithm but verifies nothing itself.

Critical: decoding is not verifying

This is the most important point of all: being able to read a token does not mean it is authentic. Decoding only reads the plaintext of header and payload. Whether the signature actually matches is a completely separate check. That requires the correct key from the issuer: the shared secret for HS256 or the public key for RS256. Without that key there is no reliable verification result. Never trust a token just because it decodes, and never skip the signature check.

• The signature is the proof of integrity: only by checking the signature against the right key do you know the content was not tampered with.
• Never trust blindly: do not trust fields such as kid or alg before verifying the signature against a trusted key source, otherwise a tampered header might try to rewrite the algorithm.
• Local only means local: the fact that this tool decodes locally says nothing about validity, only that your data do not leave for a server.

The standardized claims

RFC 7519 defines several claim names with a fixed meaning that you regularly see when decoding:

• iss the issuer of the token
• sub the subject the token belongs to
• aud the audience it is intended for
• exp the expiry time as Unix seconds
• nbf the earliest time from which it is valid
• iat the time it was issued
• jti a unique ID of the token

Many of these values are timestamps that the inspector converts automatically into readable dates.

When is a JWT considered invalid?

A token is not (no longer) valid when it has expired (exp reached), is not yet active (nbf in the future), the audience does not match, or the signature cannot be verified with the expected key. Time checks anyone can do; the integrity and origin check requires the right key. This decoder shows you the time status but cannot replace the key check.

Frequently asked questions