JWT Decoder Online
Decode JSON Web Tokens (JWT) payload and header values. Fast client-side decoding helps inspect claims and expiration states instantly.
JSON Web Tokens (JWT) have become the industry standard for securing stateless microservices and handling user sessions in web applications. Defined by RFC 7519, a JWT encapsulates user identities, access roles, and metadata in a compact, URL-safe format. This allows client applications to present authorization claims to backend APIs without querying database user tables for each request. Inspecting token parameters is a frequent troubleshooting task for developers trying to diagnose access issues.
The Three Parts of a JWT
A JWT is composed of three parts separated by periods (.):
- Header: Contains metadata about the token, typically specifying the signature algorithm (e.g., HMAC-SHA256, RSA) and the token type (JWT).
- Payload: Contains the actual claims (the user ID, expiration timestamps, scopes) formatted as a JSON object.
- Signature: Computed by hashing the header, the payload, and a cryptographic secret key, verifying that the token was not modified in transit.
Each section is encoded using Base64URL, a variant of Base64 that uses URL-safe symbols (replacing + and / with - and _) and omits the trailing padding equals characters (=).
Security Considerations and Signature Verification
Because Base64URL is a reversible encoding scheme, anyone who intercepts a signed JWT can decode it and read the payload. For this reason, you must never store passwords, database credentials, or sensitive personally identifiable information (PII) inside a JWT payload. The security of the token rests entirely on the signature. While client applications can decode and read the payload to customize user interfaces, backend APIs must always verify the signature against the server key before trusting the claims.
frequently asked questions
A JWT is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is digitally signed using a cryptographic key (HMAC or RSA), allowing receiver validation.
No, standard JWTs are signed but NOT encrypted. The header and payload are simply encoded using Base64URL, meaning anyone who intercepts the token can decode it to view the claims. Secrets or passwords should never be stored in a standard JWT.
No. Signature verification requires passing your cryptographic public/private keys or shared secrets. For security reasons, uploading private keys to a web page is a critical vulnerability. This tool only decodes claims client-side to inspect contents safely.
These are registered claims defined by RFC 7519: "sub" (subject) identifies the user, "exp" (expiration time) is the Unix timestamp after which the token is invalid, "iat" (issued at) is the creation epoch, and "iss" (issuer) identifies the security token service.
Inspect the "exp" claim in the payload. Compare its numeric Unix epoch seconds value to the current epoch time. If the current epoch time is greater than the "exp" value, the token has expired.