JWT Decoder
Paste a JSON Web Token to decode and inspect its header, payload, and signature. Auto-decodes on paste.
Paste a JWT token to instantly see the decoded header, payload, and expiration status.
About JSON Web Tokens (JWT)
A JSON Web Token (JWT) is a compact, self-contained token format defined in RFC 7519. It's widely used for authentication and authorization in web applications. A JWT consists of three parts separated by dots: a header, a payload, and a signature. Each part is Base64URL-encoded, which means you can decode and read the header and payload without any secret key — the signature only proves the token hasn't been tampered with, it doesn't encrypt the contents.
JWT Structure: Header, Payload, Signature
The header typically contains two fields: alg (the signing algorithm, like HS256 or RS256) and typ (usually "JWT"). The payload carries claims — key-value pairs with information about the user or session. The signature is created by signing the encoded header and payload with a secret key (for HMAC algorithms) or a private key (for RSA/ECDSA). When a server receives a JWT, it recomputes the signature to verify the token is authentic and unmodified.
Common Claims
The JWT spec defines several registered claims: sub (subject, usually a user ID), exp (expiration time as a Unix timestamp), iat (issued at), nbf (not before), iss (issuer), and aud (audience). You can also include custom claims for your application, such as roles or permissions. Keep the payload small — every claim increases the token size, and JWTs are sent with every request in the Authorization header.
Security Considerations
The most common JWT mistake is assuming the payload is private. Since it's only Base64URL-encoded, anyone with the token can read every claim — paste any JWT into this decoder and you'll see everything immediately. Never store passwords, credit card numbers, or other secrets in a JWT. Also watch out for the "none" algorithm attack: some libraries accepted tokens with alg set to "none", bypassing signature verification entirely. Always validate the algorithm on the server side.
JWTs vs. Session Cookies
JWTs work well for stateless authentication across multiple services — any service with the public key can verify a token without calling back to an auth server. However, JWTs cannot be revoked before expiration without maintaining a server-side blocklist, which partially defeats the stateless advantage. For simple single-server apps, traditional session cookies stored in a database may be simpler and easier to manage. The right choice depends on your architecture: microservices and APIs often benefit from JWTs, while monolithic apps may not need them.
Frequently Asked Questions
What is a JWT token?
A JWT (JSON Web Token) is a compact, three-part signed token in the format header.payload.signature. The header specifies the signing algorithm, the payload carries claims like user ID and expiration time, and the signature verifies the token hasn't been tampered with. JWTs are widely used for stateless authentication in web APIs.
Can someone read my JWT payload?
Yes, the JWT payload is only Base64URL-encoded, not encrypted. Anyone with access to the token can decode and read every claim in the payload. Never store sensitive information like passwords or credit card numbers in a JWT. The signature only proves the token is authentic and unmodified — it does not hide the contents.
How do I decode a JWT without a library?
Split the token string by the dot (.) delimiter to get three parts. Base64URL-decode the first part to get the header JSON, and decode the second part to get the payload JSON. The third part is the signature. In JavaScript, replace - with + and _ with / in each part, then use atob() to decode.
What happens when a JWT expires?
When a JWT's exp (expiration) claim is in the past, the server rejects it as invalid and returns an authentication error, typically a 401 status. The client must then obtain a new token, either by using a refresh token or by prompting the user to re-authenticate. Short expiration times limit the damage window if a token is compromised.
What is the difference between HS256 and RS256?
HS256 uses symmetric signing — the same secret key both creates and verifies the signature, so every service that validates tokens needs the secret. RS256 uses asymmetric signing with a private key to sign and a public key to verify, allowing services to validate tokens without access to the signing key. RS256 is preferred in distributed architectures.