JWT Encoder/Decoder
JSON Web Token (JWT) debugging, encoding and decoding tool. Supports signature verification (HS256/RS256), all processing done locally in browser
Decoded JWT
Header
Payload
Signature
JSON Web Tokens (JWT) Practical Guide
What is JWT (JSON Web Token)?
JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way to securely transmit information between parties as a JSON object. The information can be verified and trusted because it is digitally signed. JWTs can be signed using a secret (with the HMAC algorithm) or a public/private key pair (using RSA or ECDSA). Because they are Base64Url encoded, the tokens are small and can be sent through URLs, POST parameters, or HTTP headers.
Structure of a JWT
A technical JWT consists of three parts separated by dots (.):
- Header: Header: typically contains two parts: the token type (JWT) and the signing algorithm, such as HMAC SHA256 or RSA.
- Payload: Payload: contains claims. Claims are statements about an entity (usually the user) and additional data. There are three types of claims: registered, public, and private.
- Signature: Signature: created by taking the encoded header, the encoded payload, a secret, and the algorithm specified in the header, and signing them. The signature is used to verify that the message has not been changed along the way.
Supported Algorithms
This tool supports decoding and verifying all standard algorithms, and generating tokens for symmetric algorithms:
| Algorithm | Type | Description |
|---|---|---|
| HS256 | Symmetric | HMAC SHA-256, requires a shared secret, fast and common in microservices |
| HS384 | Symmetric | HMAC SHA-384, uses 384-bit hash, higher collision resistance |
| HS512 | Symmetric | HMAC SHA-512, uses 512-bit hash, strongest among symmetric signatures |
| RS256 | Asymmetric | RSA SHA-256, sign with private key and verify with public key, ideal for public APIs |
| RS384/RS512 | Asymmetric | RSA SHA-384/512, higher security level |
Understanding JWT Claims
Claims are statements about a subject. Standard registered claims include:
- iss (Issuer): Identifies the principal that issued the JWT.
- sub (Subject): Identifies the principal that is the subject of the JWT.
- aud (Audience): Identifies the recipients that the JWT is intended for.
- exp (Expiration Time): Identifies the expiration time on or after which the JWT must not be accepted for processing.
- nbf (Not Before): Identifies the time before which the JWT must not be accepted for processing.
- iat (Issued At): Identifies the time at which the JWT was issued.
- jti (JWT ID): Provides a unique identifier for the JWT.
When to Use JWT?
- Authorization: The most common scenario. After a user logs in, every subsequent request will include the JWT, allowing the user to access routes, services, and resources that are permitted by that token.
- Information exchange: JWTs are a good way to securely transmit information between parties. Because JWTs can be signed, you can be sure the senders are who they say they are.
- Stateless sessions: Unlike server-side sessions, JWT contains all necessary user data, reducing database lookups for session state.
- Cross-domain Single Sign-On (SSO): Because JWTs are stateless and compact, they are easy to pass between different domains to implement SSO.
- API security: Protect RESTful APIs without maintaining server-side session state.
Key Security Best Practices 1) Do not put sensitive data (such as passwords) in the payload; it is readable by anyone (Base64 decoded). 2) Always verify the signature. 3) Use the 'exp' claim to limit token lifetime. 4) Use HTTPS to prevent tokens from being intercepted. 5) Store tokens securely (prefer HttpOnly cookies over LocalStorage to mitigate XSS).
References
- RFC 7519 - JSON Web Token (JWT) specification
- JWT.io - Official industry resource
- MDN Web Docs: Crypto API
Frequently Asked Questions (FAQ)
Is JWT encrypted or encoded?
Standard JWTs are encoded and signed, not encrypted. The payload is Base64Url encoded, which means anyone can decode and read it. The signature ensures the data has not been tampered with, but does not hide the data. If you need confidentiality, you should use JWE (JSON Web Encryption).
Where should the client store JWT?
For web applications, storing JWT in an HttpOnly cookie is generally considered safer than localStorage, because cookies are immune to XSS-based reads. However, cookies are vulnerable to CSRF attacks, which must be mitigated separately.
What happens if a JWT is leaked?
If a JWT is stolen, the attacker can impersonate the user until the token expires. This is why you must use short expiration times (exp) and implement token revocation strategies (such as blacklisting jti) or use refresh tokens with rotation.
Does this tool send my keys to the server?
No. This tool runs entirely on the client side. Your private keys, secrets, and token data never leave your browser. All cryptographic operations are performed locally using JavaScript libraries.
Can I manually modify the payload?
You can modify the payload locally, but this will invalidate the signature based on the original key. Unless you re-sign with the correct key/private key, the server will reject the token.
What is the difference between HS256 and RS256?
HS256 is a symmetric algorithm (the same shared secret is used for both signing and verification). RS256 is an asymmetric algorithm (private key for signing, public key for verification). RS256 is better suited for distributed systems where many services need to verify tokens but must not be able to generate them.
What is the payload of a JWT?
The payload contains claims, which are statements about an entity (typically the user) and additional data. The payload is Base64Url encoded and can be read by anyone, so do not place sensitive information such as passwords in it. Common claims include user ID (sub), expiration time (exp), issued-at time (iat), and so on.
Why does signature verification fail?
Signature verification can fail for several reasons: 1) an incorrect key or public key is used; 2) the token has been tampered with or modified; 3) the algorithm used by the token does not match the one specified during verification; 4) for RSA/ECDSA algorithms, the public key format is incorrect or does not match the private key used for signing. Make sure you use the same key and algorithm as were used to generate the token.