JWT Decoder — Complete Guide
A JWT (JSON Web Token) is an open standard (RFC 7519) widely used for authentication and information exchange in web applications. A JWT has three parts — Header, Payload, and Signature — separated by dots (.) and encoded with Base64URL. This tool takes a token, splits these three parts, performs Base64URL decoding, and renders them as human-readable JSON with syntax highlighting.
The Header contains the token type (typ) and the signing algorithm (alg). Common algorithms include HS256 (HMAC SHA-256), RS256 (RSA SHA-256), and ES256 (ECDSA P-256). The Payload holds the claims — the data carried by the token — which are grouped into registered, public, and private claims.
The most important registered claims are: iss (Issuer), sub (Subject), aud (Audience), exp (Expiration Time), nbf (Not Before), iat (Issued At), and jti (JWT ID). This tool recognises these standard claims automatically, explains them, and — when an exp claim is present — calculates the expiry status and remaining time in real time.
The Signature is the Header and Payload signed with a secret key or a public/private key pair, and it is used to verify the token's integrity. This decoder shows the signature in its Base64URL form but does not verify it, because verification requires the secret key. All decoding happens in your browser, and token data is never sent to an external server.
Where JWTs are used
- Authentication: keep a user signed in using a JWT issued after login.
- Information exchange: pass data in a trusted way via the digital signature.
- API authorization: manage access to resources with token-based permissions.
- Single Sign-On (SSO): implement unified authentication across multiple services.
- Microservice communication: exchange data securely between services.
Frequently asked questions
Q. Is decoding a JWT here safe?
A. Yes. Decoding happens 100% in your browser. The token you paste is never sent to a server and is cleared from memory when you close the page. Note that a JWT payload is only Base64URL-encoded, not encrypted, so you should never place sensitive data such as passwords or personal information directly in the payload.
Q. My token shows as expired. What should I do?
A. When the exp (expiration) claim is earlier than the current time, the token is shown as expired. Expired tokens may be rejected by the server, so you need to obtain a new token or use a refresh token to issue a fresh access token.
Q. Can't this tool verify the signature?
A. Signature verification requires the secret key or public key used to sign the token. For security reasons this tool does not provide verification; when verification is needed, perform it server-side with an appropriate library.
Q. What is the difference between HS256 and RS256?
A. HS256 (HMAC SHA-256) is a symmetric algorithm that uses the same secret key to sign and verify. RS256 (RSA SHA-256) is asymmetric — it signs with a private key and verifies with a public key. RS256 is better suited to microservice environments because the public key can be distributed safely, while HS256 is simpler to use within a single service.
Q. What information should go into a JWT?
A. A JWT payload typically carries a user identifier, role or permission data, and token metadata (expiry, issued-at, etc.). Never include sensitive data such as passwords or credit-card numbers, because a JWT is signed, not encrypted — anyone can decode the payload and read its contents.