JWT decoder

{
  "alg": "HS256",
  "typ": "JWT"
}

{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022
}

What this JWT decoder does

Paste a JSON Web Token and the tool splits it on the dots, Base64URL-decodes the first two parts and pretty-prints them as JSON. The header tells you the signing algorithm and token type, the payload holds the claims, and if an exp claim is present you get a human-readable UTC expiry line above them. The signature is not checked — this is a reading tool for debugging auth flows, not a validator. Everything runs locally; the token is never transmitted.

How to use it

1. Paste the token into the Token box. Whitespace around it is ignored; the sample is the well-known HS256 example from jwt.io.
2. The Header and Payload panels update as you type.
3. If the payload has an exp claim, an Expires … line appears with the date in ISO 8601 (UTC). Compare it with now to see whether the token is still valid.
4. Use Copy on either panel to grab the formatted JSON.

If you see “Could not decode token”, the input is not a JWT (many session cookies and API keys are opaque strings, not JWTs) or a character was corrupted in transit.

Anatomy of a JWT

A signed JWT (JWS) is three Base64URL strings joined by dots: header.payload.signature.

Part	Content	Example (decoded)
Header	Algorithm and type, sometimes a key ID	{"alg":"HS256","typ":"JWT","kid":"2024-01"}
Payload	The claims — registered, public and private	{"sub":"1234567890","name":"John Doe","iat":1516239022}
Signature	HMAC or digital signature over header.payload	32 raw bytes for HS256, shown as 43 Base64URL characters

Base64URL is standard Base64 with + and / replaced by - and _ and the trailing = padding removed, so a token survives inside URLs and HTTP headers without further encoding. A five-part token (four dots) is a JWE, an encrypted JWT — its payload cannot be read without the key, and this tool will not decode it.

Standard claims to look for

Claim	Meaning	Format
iss	Issuer — who minted the token	String or URL, e.g. https://accounts.example.com
sub	Subject — the user or principal	String, typically a user ID
aud	Audience — who should accept it	String or array of strings
exp	Expiration time	Unix seconds (not milliseconds)
nbf	Not valid before	Unix seconds
iat	Issued at	Unix seconds
jti	Unique token ID, used for revocation lists	String

Timestamps are seconds, so 1516239022 is 2018-01-18T01:30:22Z. If a value looks ten times too long (13 digits) somebody serialized milliseconds, and most libraries will treat the token as valid for thousands of years. Use the timestamp converter to check any claim beyond exp.

Decoding is not verifying

The payload you see is exactly what a server would see before checking the signature — and that is the point of the signature. Reading "role":"admin" in a token says nothing about whether the token is trusted. A proper check on the server does all of the following:

1. Verify the signature with the expected key and the algorithm you expect, never the one in the header.
2. Reject if exp is in the past or nbf is in the future (allow a small clock skew, usually 30–60 s).
3. Check iss and aud match your service.
4. Optionally check jti against a revocation list.

Skipping step 1 or trusting the header’s alg is how most real-world JWT vulnerabilities happened. Algorithms you will typically meet: HS256 (shared secret, symmetric), RS256 (RSA public/private key), ES256 (ECDSA P-256), EdDSA (Ed25519).

Related tools and snippets

• Base64 encoder / decoder — decode a single token part by hand, or inspect Base64 data elsewhere in an auth flow.
• Timestamp converter — turn iat, nbf and other Unix-second claims into readable dates.
• JSON formatter & validator — format larger claim payloads or validate JSON you plan to put in a token.
• Hash generator — SHA-256 is the hash under HS256 and RS256; see what a digest looks like.
• UUID generator — a common choice for the jti claim.