A JWT is decoded by splitting the token on dots and Base64URL-decoding the header and payload. This tool does that locally in your browser — the token never leaves your device. Signature verification requires a secret and should happen server-side.
Encoded token
Header
{
"alg": "HS256",
"typ": "JWT"
}Payload
expired{
"sub": "1234567890",
"name": "Ada Lovelace",
"iat": 1720000000,
"exp": 1751536000
}iat · 2024-07-03T09:46:40.000Z
exp · 2025-07-03T09:46:40.000Z
Signature
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
Signature verification requires the secret or public key and should be done server-side.
// faq
Frequently asked questions
- Is my JWT sent to a server?
- No. This decoder runs entirely in your browser — the token is split and Base64URL-decoded in JavaScript. Your JWT never leaves the page, so it's safe to inspect production tokens.
- Does this tool verify the JWT signature?
- No. Signature verification requires the secret (HMAC) or public key (RSA/ECDSA) and should always happen on your server. This tool decodes header and payload only, which is the common debugging use case.
- What are the three parts of a JWT?
- Header (algorithm and token type), payload (claims like sub, iat, exp), and signature. They are Base64URL-encoded and joined with dots: header.payload.signature.
- What do the standard claims mean?
- iss = issuer, sub = subject, aud = audience, exp = expiration (Unix seconds), nbf = not before, iat = issued at, jti = JWT ID. Custom claims live alongside these.
- Should I store JWTs in localStorage?
- Prefer httpOnly, Secure, SameSite cookies for session tokens to prevent XSS from exfiltrating them. localStorage is fine for short-lived, low-value tokens if XSS is otherwise mitigated.
// related

