JWT Decoder
Decode and inspect JSON Web Tokens (JWT). View the header, payload, and signature in a readable format.
Paste a JWT token to decode its header, payload, and signature. JWTs are Base64URL-encoded
JSON objects separated by dots (.).
Table of Contents
What is a JWT?
JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed.
JWTs are commonly used for authentication and authorization in web applications. They allow stateless authentication, meaning the server doesn't need to store session information.
JWT Structure
A JWT consists of three parts separated by dots (.):
- Header: Contains metadata about the token (algorithm, type)
- Payload: Contains the claims (data) about the user or entity
- Signature: Used to verify the token hasn't been tampered with
Each part is Base64URL-encoded JSON. The format is: header.payload.signature
Header
The header typically contains two fields:
alg: The signing algorithm (e.g., HS256, RS256, ES256)typ: The type of token, usually "JWT"
Example header:
{
"alg": "HS256",
"typ": "JWT"
}Payload
The payload contains the claims. There are three types of claims:
- Registered claims: Predefined claims like
iss(issuer),exp(expiration),sub(subject) - Public claims: Claims defined in the JWT registry or as URI/URL that contain collision resistant names
- Private claims: Custom claims created to share information between parties
Example payload:
{
"sub": "1234567890",
"name": "John Doe",
"iat": 1516239022,
"exp": 1516242622
}Signature
The signature is created by encoding the header and payload using Base64URL, then signing them with a secret (for HMAC) or a private key (for RSA/ECDSA) using the algorithm specified in the header.
The signature ensures that:
- The token hasn't been tampered with
- The sender is who they claim to be
- The message hasn't changed along the way
Important: This tool only decodes the JWT structure. It does not verify the signature. To verify a JWT, you need the secret key or public key used to sign it.
Common Use Cases
- Authentication: After login, a JWT is issued and used for subsequent requests
- Authorization: JWTs can contain permissions and roles
- Information Exchange: Secure way to transmit information between parties
- Single Sign-On (SSO): Share authentication state across multiple domains
- API Authentication: Stateless authentication for REST APIs
Security Considerations
Token Storage
Never store JWTs in localStorage if your application is vulnerable to XSS attacks. Consider using httpOnly cookies instead. However, localStorage is acceptable if you have proper XSS protection in place.
Token Expiration
Always set reasonable expiration times for tokens. Use short-lived access tokens and longer-lived refresh tokens for better security.
Signature Verification
Always verify the signature on the server side before trusting the token. Never trust client-side validation alone.
Sensitive Data
Avoid storing sensitive information in the payload. Remember that JWTs are encoded, not encrypted—anyone can decode and read the contents.
Algorithm Confusion
Always specify the algorithm when verifying tokens. Don't allow the token to specify which algorithm to use, as this can lead to algorithm confusion attacks.
Frequently Asked Questions
No. This tool only decodes the JWT structure to show the header, payload, and signature. Signature verification requires the secret key or public key, which should never be exposed in client-side tools.
No. JWTs are encoded (Base64URL), not encrypted. Anyone can decode a JWT and read its contents. The signature only ensures the token hasn't been tampered with, but it doesn't hide the data. For sensitive data, use JWE (JSON Web Encryption).
exp is the expiration time claim. It represents the time after
which the JWT must not be accepted for processing. It's a Unix timestamp (seconds since epoch).
This tool will show the expiration date and whether the token has expired.
HS256 (HMAC with SHA-256) uses a symmetric secret key that must be shared between the issuer and verifier. RS256 (RSA with SHA-256) uses an asymmetric key pair (private key to sign, public key to verify), which is more secure for distributed systems.
JWTs must have exactly three parts separated by dots. Make sure you're pasting the complete token, including all three parts (header.payload.signature). Also ensure there are no extra spaces or line breaks in the token.
No, this tool only decodes existing JWTs. To create JWTs, you need to use a library or service that can sign tokens with a secret key or private key. Creating tokens requires cryptographic operations that should be done server-side.