JWT Decoder (header & payload, no verification)

Understanding the JWT decoder — concept and principle

A JSON Web Token (JWT) is a compact string that carries claims, such as who a user is and when the token expires, between a login server and an application. This decoder shows what is inside a token: the header, the payload and the expiry time. Developers use it to debug sign-in problems, check which claims a service sends and see why a token was rejected. Decoding happens in your browser; the token is not sent anywhere.

How it is calculated

A signed JWT (JWS compact form) has three parts separated by dots: header.payload.signature.

1. Split the string at the dots.
2. Convert base64url to standard Base64 by replacing "-" with "+" and "_" with "/", then add "=" padding until the length is a multiple of 4.
3. Base64-decode the bytes and read them as UTF-8 text. The first part is the header, the second the payload.
4. If the payload has an "exp" claim (seconds since 1970-01-01 UTC), show it as a date and add "(expired)" if it is in the past. Without "exp", the expiry shows "—".

The third part, the signature, is not checked.

The principle

Base64url is an encoding, not encryption: it maps every 3 bytes to 4 URL-safe characters so the JSON can travel in headers and URLs. Anyone holding the token can read the claims. What protects a JWT is the signature, computed over the exact text "header.payload". With HS256 it is an HMAC-SHA256 using a shared secret; with RS256 or ES256 it is a public-key signature. Changing even one character of the payload makes the signature invalid, but only a party that verifies it will notice.

Worked example

1. Input: the sample token beginning "eyJhbGciOiJIUzI1NiIs…".
2. The first part decodes to the header {"alg":"HS256","typ":"JWT"}: an HMAC-SHA256 signed JWT.
3. The second part decodes to the payload {"sub":"1234567890","name":"John Doe","iat":1516239022}.
4. "iat" (issued at) 1516239022 is 2018-01-18 01:30:22 UTC.
5. There is no "exp" claim, so Expiry shows —.

How to read the result

Check "alg" first: it should match what your server expects, and "none" should always be refused. Common registered claims are iss (issuer), sub (subject), aud (audience), exp (expiry), nbf (not before), iat (issued at) and jti (token ID).

Common mistakes

• Trusting decoded claims without verifying the signature on the server.
• Putting secrets or personal data in the payload, believing it is hidden.
• Treating exp as milliseconds; JWT times are in seconds.

Frequently asked questions

Is a JWT encrypted?

A normal signed JWT (JWS) is not. Encrypted tokens use the separate JWE format, which has five parts instead of three.

Why does my token start with "eyJ"?

The opening characters {" of a JSON object, followed by a letter, always become "eyJ" after base64url encoding.

Can I verify the signature here?

No. Verification needs the secret or public key and should happen in your server code with a maintained JWT library.

Sources: IETF RFC 7519, JSON Web Token (JWT) · IETF RFC 7515, JSON Web Signature (JWS) · IETF RFC 4648, The Base16, Base32, and Base64 Data Encodings