redzilla
All tools
Security

JWT Decoder

Paste a JWT and I show its decoded header and payload, the signing algorithm and claims (iss, sub, aud, exp, iat, nbf) with readable dates and expiry status. The token never leaves your browser.

Structure header.payload.signature in Base64URL. Decoded locally.

Only HS* (HMAC) signatures. Checked in your browser with Web Crypto. RS*/ES* signatures are not verified here.

redzilla.cl — jwt
 
Status
paste a token to decode
Algorithm
signature not verified
alg
typ
sub
exp

Header

Payload

Registered claims

ClaimValueMeaning
No claims to show yet.
How it works · anatomy of a JWT

1. A JWT has three parts separated by dots: header.payload.signature. Header and payload are JSON encoded in Base64URL (URL-safe variant: +-, /_, no = padding).

2. The header declares the signing algorithm (alg) and type (typ). The payload carries the claims: data such as sub (subject), iss (issuer) or exp (expiry).

3. The exp, iat and nbf dates are epoch seconds (Unix). Here I convert them to readable date and time and compare exp against the current time to flag the token as valid or expired.

4. Decoding is not verifying. Anyone can read the payload; the signature is what guarantees it was not tampered with. It is only checked if you paste the HS* secret. Never trust a token without verifying its signature on the server.

Decoded locally in your browser · no sign-up · the token is never sent to any server.

How it works

The decoder takes a JSON Web Token (RFC 7519) with its three-part structure header.payload.signature and locally decodes the first two, which are JSON encoded in Base64URL (the URL-safe Base64 variant: +-, /_, no = padding). It shows the signing algorithm (alg) and type (typ) from the header, the pretty-printed payload, and the registered claims (iss, sub, aud, exp, iat, nbf) with their epoch timestamps converted to readable dates.

It also compares exp against the current time to mark the token as valid or expired. Important: decoding is not verifying; anyone can read a JWT payload. If the token is signed with HMAC (HS256/384/512) you can paste the secret and the tool checks the signature in your browser using Web Crypto; asymmetric signatures (RS*/ES*) are not verified here and must always be validated server-side.

Example: reading the classic test token

  1. Paste a token such as eyJhbGciOiJIUzI1NiIs… (the Load sample button provides one).
  2. The decoded header shows { alg: HS256, typ: JWT } and the payload { sub: 1234567890, name: John Doe, iat: 1516239022 }.
  3. The iat (issued at) claim is translated from epoch 1516239022 to January 18, 2018 (UTC); since there is no exp, no expiration is flagged.
  4. If you paste the correct HS256 secret, the signature is validated locally and the status changes to signature verified.

Frequently asked questions

Is it safe to paste a production JWT into an online decoder?
In this tool yes, because the token is decoded entirely in your browser and is never sent to any server. Even so, a valid JWT is effectively a credential: avoid sharing it over chat or email, and prefer decoding already-expired tokens when you only need to inspect the structure.
What is the difference between decoding and verifying a JWT?
Decoding just undoes the Base64URL: anyone can do it, because the payload is not encrypted. Verifying means checking the cryptographic signature with the secret (HS*) or the public key (RS*/ES*), and it is the only thing that guarantees the token was not tampered with. A backend must never trust claims without verifying the signature.
How do I know if my JWT is expired?
The exp claim states the expiration moment as a Unix epoch in seconds. The tool converts it to a readable date and compares it with your machine current time: if exp has already passed, the token is marked as expired. It also shows nbf (not before) and iat (issued at) when present.
Why does the tool not verify RS256 or ES256 signatures?
Because asymmetric signatures are validated with the issuer public key, which is normally fetched from the identity provider JWKS endpoint, and that flow belongs on the server. Here only HMAC (HS256/384/512) is verified locally with Web Crypto, which is useful for debugging your own development tokens.
Was this tool useful?
Disclaimer We take great care to keep every tool accurate and review it thoroughly; even so, we can't guarantee it is free of errors or take responsibility for how the results are used. We recommend double-checking anything critical.
Found an error? Let us know →