JWT Decoder

A JSON Web Token, commonly abbreviated as JWT (pronounced "jot"), is a compact, URL-safe token format defined by RFC 7519. JWTs are used to securely transmit information between two parties — typically a client and a server — as a self-contained JSON object. Unlike opaque session tokens that require a server-side lookup, a JWT carries all of its data within the token itself, making it a popular choice for stateless authentication in modern web applications, single-page apps, mobile APIs, and microservice architectures.

The Three Parts of a JWT

Every JWT consists of exactly three Base64URL-encoded segments separated by dots (header.payload.signature). The header declares the token type and the signing algorithm (e.g., HS256, RS256). The payload contains the claims — key-value pairs that carry the actual data, such as the user ID, roles, and expiration time. The signature is a cryptographic hash that ensures the token has not been tampered with. The server that created the token signs it with a secret key (HMAC) or a private key (RSA/ECDSA), and any party with the corresponding key can verify the signature.

Standard JWT Claims

The JWT specification defines several registered claim names that have specific meanings:

• iss (Issuer) — Identifies the entity that issued the token, such as your authentication server's URL.
• sub (Subject) — The principal the token represents, usually a user ID or email address.
• aud (Audience) — The intended recipient of the token, typically your API's identifier.
• exp (Expiration Time) — A Unix timestamp after which the token must be rejected. This is the most critical claim for security.
• nbf (Not Before) — A Unix timestamp before which the token must not be accepted.
• iat (Issued At) — The Unix timestamp when the token was created.
• jti (JWT ID) — A unique identifier for the token, useful for preventing replay attacks.

How JWT Authentication Works

In a typical authentication flow, the user logs in with credentials. The server verifies them and returns a signed JWT. The client stores this token (usually in memory or an HTTP-only cookie) and sends it with every subsequent API request in the Authorization: Bearer <token> header. The server verifies the signature, checks the expiration, and extracts the user identity from the payload — all without touching a database. This stateless approach scales horizontally because any server instance can validate the token independently.

Common Use Cases

• Single Sign-On (SSO) — JWTs enable seamless authentication across multiple services under one identity provider.
• API Authorization — Microservices use JWTs to pass identity and permissions between services without centralized session storage.
• OAuth 2.0 / OpenID Connect — ID tokens in OIDC are JWTs that carry user profile information after authentication.
• Password Reset Links — Short-lived JWTs can encode a user ID and expiration for secure one-time-use links.

Security Considerations

JWTs are a powerful tool, but they come with important security caveats. Never trust decoded JWT claims on the client side for authorization decisions — anyone can craft a valid-looking JWT with arbitrary claims. Signature verification must always happen on the server with the correct secret or public key. Keep tokens short-lived (minutes, not days) and use refresh tokens for long sessions. Store tokens in HTTP-only cookies rather than localStorage to mitigate XSS attacks. Avoid putting sensitive data (passwords, credit card numbers) in the payload, because the payload is only Base64-encoded, not encrypted — anyone with the token can decode and read it. For sensitive payloads, use JWE (JSON Web Encryption) instead of plain JWTs.

Frequently Asked Questions

What is a JSON Web Token (JWT)?
A JWT is a compact, URL-safe token format used to securely transmit information between parties as a JSON object. It consists of three Base64URL-encoded parts separated by dots: a header, a payload, and a signature.

Is it safe to decode a JWT in the browser?
Decoding a JWT in the browser is perfectly safe because decoding only reads the token contents — it does not verify the signature or grant any access. The header and payload are simply Base64URL-encoded JSON, not encrypted. However, you should never make authorization decisions based on client-side decoded claims. Always verify the signature on the server.

Can this tool verify JWT signatures?
This tool decodes and displays the JWT header, payload, and signature hex. It does not verify the cryptographic signature because that requires the secret key (HMAC) or public key (RSA/ECDSA), which should never be entered into a browser-based tool. Use a server-side library for signature verification.

What algorithms do JWTs support?
Common algorithms include HS256 (HMAC with SHA-256), RS256 (RSA with SHA-256), ES256 (ECDSA with P-256), and PS256 (RSA-PSS with SHA-256). The algorithm is specified in the token header's alg field.

Why does my JWT say "expired"?
If the exp claim in the payload is a Unix timestamp in the past, the token has expired. This is by design — short-lived tokens limit the damage if a token is leaked. Your server should issue a new token via a refresh token flow.

This tool is completely free and runs entirely in your browser. No data is sent to any server — your JWT never leaves your machine. Use it whenever you need to quickly inspect a token during development or debugging.