Decode JWT headers, payloads, and standard claims, inspect expiration, and recognize five-part JWE locally.
⌘/Ctrl + Enter to decode
The token is decoded only in this browser and is never uploaded.
Inspect JWT structure and claims
Paste a JWT to strictly decode Base64URL and UTF-8, format its Header and Payload, and inspect standard claims including iss, sub, aud, iat,nbf, exp, and jti. A common Bearer prefix is accepted.
Three-part JWS tokens show signature details without claiming that the signature is verified. Five-part JWE tokens show the public Header and encrypted-part sizes instead of treating ciphertext as a regular JWT. Formatting works from the original JSON text, preserving 64-bit integers in the Payload.
How to use
Paste a complete token or choose Load sample;
Select Decode JWT or press ⌘/Ctrl + Enter;
Review the algorithm, standard claims, time status, and security warnings;
To establish identity, verify the signature with a trusted key in your actual server.
FAQ
Does successful decoding mean the JWT is trustworthy?
No. Decoding reads the token structure and content but cannot prove who signed it. Trust requires verification with the correct key, an explicit algorithm allowlist, and constraints such as issuer and audience.
Why do some JWTs have three parts and others five?
A common signed JWT uses JWS compact serialization: Header, Payload, and Signature. An encrypted JWT uses JWE compact serialization: Protected Header, Encrypted Key, IV, Ciphertext, and Authentication Tag.
How does the tool decide whether a token is expired?
It treats exp and nbf as Unix-second NumericDate values and compares them with your device time. This is an inspection aid; servers must still verify the signature, allowed clock skew, and application constraints.
Is the token uploaded?
No. Base64URL decoding, JSON validation, and time calculations all run locally in your browser. Production tokens are still sensitive credentials and should not be shared casually.
