JWT Decoder

The Complete Guide to JSON Web Tokens (JWT)

JSON Web Tokens are the backbone of modern web authentication. If you have ever logged into a web app, used an OAuth service like "Sign in with Google," or called a REST API with a Bearer token, you have almost certainly used JWTs. Despite their ubiquity, JWTs are frequently misunderstood — and misimplemented, leading to critical security vulnerabilities. Our free JWT Decoder lets you instantly inspect the contents of any JWT token without sending it to a server.

What is a JWT?

A JSON Web Token is a compact, URL-safe string that represents a set of claims between two parties. A JWT looks like this:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

It has three parts separated by dots (.):

• Header — algorithm and token type (Base64URL-encoded JSON)
• Payload — the claims/data (Base64URL-encoded JSON)
• Signature — cryptographic verification (algorithm-specific)

The Header

The header specifies the algorithm used to sign the token and the token type:

{
"alg": "HS256",
"typ": "JWT"
}

Common algorithms:

• HS256 (HMAC-SHA256) — symmetric signing: same secret key for signing and verification. Fast, but server and client must share the secret.
• RS256 (RSA-SHA256) — asymmetric signing: private key to sign, public key to verify. More secure for multi-service architectures — the verifying service never needs the private key.
• ES256 (ECDSA-SHA256) — like RS256 but with smaller keys and signatures.
• none — NO signature. ⚠️ Danger: Never accept tokens with "alg": "none" — this is a known attack vector.

Standard JWT Claims (Payload)

The payload contains "claims" — statements about an entity (usually the user). Standard registered claims include:

• iss (issuer) — who issued the token (e.g., "https://auth.example.com")
• sub (subject) — who the token is about (e.g., a user ID: "user_12345")
• aud (audience) — intended recipient(s) of the token (e.g., "api.example.com")
• exp (expiration time) — Unix timestamp after which the token is invalid
• iat (issued at) — Unix timestamp when the token was issued
• nbf (not before) — Unix timestamp before which the token is not valid
• jti (JWT ID) — unique identifier for the token (used to prevent replay attacks)

Critical Security Warnings

⚠️ JWTs are encoded, NOT encrypted

The Header and Payload are only Base64URL-encoded, not encrypted. Anyone who intercepts a JWT can decode and read its contents — no key required. Never store sensitive data (passwords, credit card numbers, SSNs) in a JWT payload.

⚠️ The signature verifies integrity, not confidentiality

The signature proves the token hasn't been tampered with and was issued by someone with the signing key. It does not hide the contents. Use JWE (JSON Web Encryption) if you need encrypted payloads.

⚠️ Always verify the signature server-side

Never trust a JWT's claims without verifying the signature with the appropriate key. Client-side JWT decoding (like what our tool does) is useful for inspecting and debugging — but your server must always independently verify the signature before trusting any claim in the payload.

⚠️ Check the expiration (exp) claim

A JWT that has passed its exp time should be rejected. Our tool displays the expiration date in human-readable format so you can instantly see if a token has expired — a common debugging scenario.

Where JWTs are Used

• API authentication: Bearer tokens in the Authorization header: Authorization: Bearer <token>
• Single Sign-On (SSO): Identity providers (Auth0, Firebase, Okta, AWS Cognito) issue JWTs after authentication
• OAuth 2.0 / OpenID Connect: Access tokens and ID tokens are commonly JWTs
• Stateless sessions: Storing session state in a JWT (instead of server-side sessions) allows horizontal scaling without shared session storage

Use our free JWT Decoder to inspect tokens instantly. For cryptographic hash operations, also try our Hash Generator and Base64 Encoder/Decoder.