Paste a JSON Web Token to decode and inspect its header, payload, and signature.
JWT (JSON Web Token) is a standardized, compact, and URL-safe method for securely transmitting claims and data between two parties over HTTP. A JWT encodes information into a self-contained token that can be verified and trusted because it's digitally signed. JWTs have become the standard for stateless authentication and authorization in modern web applications, microservices, and APIs. Unlike traditional session-based authentication where the server maintains session state in a database, JWTs allow stateless authentication—the server doesn't need to store session information because all necessary information is encoded in the token itself and verified using cryptographic signatures. This makes JWTs particularly useful for distributed systems, mobile applications, and single-page applications where server-side session management becomes complicated or impossible.
A JWT consists of three parts separated by periods: Header.Payload.Signature, visible as a string like `eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIn0.dozjgNryP4J3jVmNHl0w5N_XgL0n3I9PlFUP0THsR8U`.
Header: The first section, base64url-encoded, contains metadata about the token. Typically it includes `"alg"` (the cryptographic algorithm used to sign the token, like HS256, RS256, or ES256) and `"typ"` (usually "JWT"). For example: `{"alg":"HS256","typ":"JWT"}`.
Payload: The second section contains the claims—statements about an entity and additional metadata. This is where user information, permissions, and other application-specific data live. For example: `{"sub":"1234567890","name":"John Doe","iat":1516239022,"exp":1516242622}`. The payload is base64url-encoded but NOT encrypted, so never put sensitive data like passwords in JWTs.
Signature: The third section is the cryptographic signature created by signing the encoded header and payload with a secret key (for HMAC algorithms) or private key (for RSA/ECDSA algorithms). The signature verifies that the token hasn't been tampered with and that it was issued by a trusted authority. The signature is what makes JWTs secure and trustworthy.
iss (issuer): Who created and signed the token. Usually a URL or service name, e.g., "https://auth.example.com". Verifying this claim ensures the token came from a trusted authority.
sub (subject): The entity the token represents, typically the user ID. For example, "user-12345" or "admin@example.com". This identifies who the token is about.
aud (audience): Who the token is intended for. Typically the API or service that should accept the token, e.g., "api.example.com". This prevents a token issued for one service from being used with another.
exp (expiration time): When the token expires, as a Unix timestamp in seconds. For example, 1735689600 (January 1, 2025). Tokens past this time are invalid and rejected. Essential for security—tokens are temporary credentials.
iat (issued at): When the token was created, as a Unix timestamp. For example, 1735603200. Useful for tracking token age and refresh strategies.
nbf (not before): The token is not valid before this time. Allows scheduling tokens to become active in the future. Expressed as Unix timestamp.
jti (JWT ID): Unique identifier for this specific token instance. Useful for token revocation lists—if a JWT is compromised, its jti can be added to a blacklist.
Custom claims: Applications add their own claims for application-specific data. Examples: "role": "admin", "permissions": ["read", "write"], "organization_id": 42. Custom claims should be namespaced to avoid collisions.
API Authentication: A client application exchanges credentials (username/password or OAuth 2.0) with an authentication server. The server returns a JWT. The client includes this JWT in the Authorization header (`Authorization: Bearer
Single Sign-On (SSO): When a user logs into a central authentication provider, they receive a JWT. This token works across multiple applications and services without re-authenticating. Each application independently verifies the token signature using the provider's public key, enabling distributed authentication.
Microservices Authorization: In microservices architectures, a frontend service receives a JWT after user login. When the frontend needs to call backend microservices, it forwards the same JWT. Each microservice independently verifies the token without consulting a central session store, enabling true horizontal scaling.
Mobile App Authentication: Mobile applications store JWTs securely (in secure storage, not localStorage). The JWT allows the app to call backend APIs without maintaining server-side sessions. The JWT persists across app restarts, and refreshing the token is handled automatically on the client side.
Third-Party API Access: Services issue JWTs to third-party developers. The JWT grants scoped access (claims limit what actions are allowed) without exposing credentials. The issuer can revoke access by invalidating the JWT without the third party needing to change their code.
OAuth 2.0 Integration: OAuth 2.0 authorization servers issue JWTs as access tokens. The JWT encodes authorization information allowing resource servers to make independent authorization decisions without consulting the authorization server for every request.
Payload is not encrypted: Base64url encoding is NOT encryption. Anyone can decode a JWT and read the payload. Never put passwords, API keys, credit card numbers, or PII in JWT payloads. If you need encryption, apply it before creating the JWT or use JWE (JSON Web Encryption).
Verify the signature: A JWT is only as trustworthy as its signature. Always verify the signature using the issuer's public key or secret key. Don't blindly trust the header's claimed algorithm—an attacker might claim HS256 when the key is meant for RS256. Use libraries that verify signatures correctly.
Check expiration: Always verify the exp claim. Accepting expired tokens defeats the purpose of token expiration. Set reasonable expiration times—typically 15 minutes for access tokens and longer for refresh tokens.
Use HTTPS always: JWTs in headers are visible to network monitors. Always use HTTPS to prevent interception. Sending JWTs over HTTP exposes them to man-in-the-middle attacks.
Secure token storage: On the client side, store tokens securely. In browsers, HttpOnly, Secure, SameSite cookies are safer than localStorage (which is vulnerable to XSS). In mobile apps, use secure storage provided by the platform.
Token rotation and refresh: Don't use the same JWT forever. Implement refresh token flows: short-lived access tokens (15 minutes) and longer-lived refresh tokens (days or weeks). When an access token expires, use the refresh token to get a new access token.
Implement token revocation: Maintain a blacklist of revoked jti values for compromised or invalidated tokens. This prevents an attacker from using a stolen token for its full expiration period.
Algorithm security: Use strong algorithms. HS256 (HMAC-SHA256) is simpler for symmetric scenarios. RS256, ES256, or PS256 are better for distributed systems where different parties verify tokens. Avoid the "none" algorithm—it's insecure.
Q: Is JWT the same as OAuth 2.0? A: No. OAuth 2.0 is an authorization framework. JWT is a token format. OAuth 2.0 can use JWTs as access tokens, but doesn't require them. They work well together but serve different purposes.
Q: Can I trust a JWT without verifying the signature? A: No. An attacker can modify the payload and re-sign the JWT with their own key, creating a fake token. You must verify the signature using the issuer's secret or public key to confirm the token is genuine.
Q: What's the difference between access tokens and refresh tokens? A: Access tokens are short-lived (15 minutes) and grant access to resources. Refresh tokens are long-lived (days/weeks) and only refresh access tokens. If an access token is stolen, it's valid for only 15 minutes. Refresh tokens are stored more securely.
Q: Can I manually create a valid JWT? A: You can create the header and payload, but you cannot create a valid signature without knowing the secret or private key. If you're testing, you can sign JWTs using jwt.io or libraries, but in production the issuer must sign them.
Q: What happens when a JWT expires? A: The token becomes invalid. Any service verifying the token will reject it based on the exp claim. The client must use a refresh token to obtain a new access token, or re-authenticate.
Q: Can JWT be used for sessions instead of cookies? A: Conceptually yes, but with tradeoffs. JWTs avoid server-side session storage (scalability benefit), but the client must handle token storage securely. Cookies with HttpOnly flag are often safer. It depends on your architecture.
A JWT has three parts: Header.Payload.Signature. The header specifies the algorithm used (e.g., HS256). The payload contains the claims (standard claims include iss, sub, aud, exp, iat). The signature ensures the token hasn't been tampered with and can only be verified by the issuer.
exp (expiration time) – When the token expires. iat (issued at) – When the token was created. sub (subject) – Who the token is about. aud (audience) – Who the token is intended for.