JWT Decoder & Validator

What is a JWT (JSON Web Token)?

A JSON Web Token (JWT, pronounced “jot”) is a compact, URL-safe way to represent claims — pieces of information — that are transferred between two parties. Defined in RFC 7519, a JWT packages a JSON payload together with a header and a cryptographic signature so the receiver can verify that the data is authentic and has not been tampered with.

In its most common form, a signed JWT (technically a JWS) is three base64url-encoded segments joined by dots: header.payload.signature. The header says which algorithm secured the token, the payload carries the claims, and the signature lets anyone with the right key confirm the token’s integrity. Because the result is a short, text-only string, a JWT travels comfortably in an HTTP Authorization header, a cookie or a URL.

JWTs are the backbone of modern stateless authentication and authorization. They are issued by identity providers such as Auth0, Okta, Microsoft Entra ID, Google and Keycloak, and consumed by APIs, single-page apps and microservices the world over as part of OAuth 2.0 and OpenID Connect.

How a JWT works: header, payload and signature

The header is a small JSON object that declares the token type ("typ":"JWT") and the signing algorithm ("alg", e.g. RS256 or HS256). It may also carry a key ID ("kid") so the verifier knows which key to use.

The payload (also called the claims set) is a JSON object of statements about the subject — for example who they are (sub), who issued the token (iss), who it is for (aud) and when it expires (exp). Crucially, in a signed JWT the payload is only base64url-encoded, not encrypted: anyone holding the token can read it. Never put secrets or sensitive personal data in a JWS payload.

The signature is created by signing the string header.payload with a key, using the algorithm named in the header. For HMAC algorithms the same secret signs and verifies; for RSA, ECDSA and EdDSA a private key signs and the matching public key verifies. If even a single byte of the header or payload changes, the signature no longer matches and the token is rejected.

JWT vs. server-side sessions

Traditional session authentication stores a session record on the server and gives the client an opaque session ID in a cookie. Every request, the server looks up that ID to find the user. This is simple and easy to revoke, but it requires shared session storage and a lookup on every request.

JWTs are self-contained: the user’s identity and permissions live inside the signed token, so an API can authenticate a request just by verifying the signature — no database lookup, no shared session store. That statelessness is what makes JWTs scale so well across microservices and serverless functions.

The trade-off is revocation. Because a JWT is valid until it expires, you cannot instantly “log out” a leaked token without extra machinery (short lifetimes, a token blocklist keyed on jti, or rotating signing keys). The usual pattern is short-lived access tokens plus a longer-lived refresh token managed server-side.

JWT for authentication and authorization (OAuth2 & OIDC)

In OpenID Connect, an ID token is a JWT that proves a user authenticated and carries profile claims such as name and email. In OAuth 2.0, an access token (often a JWT) authorizes a client to call an API on the user’s behalf, with permissions expressed as scopes (scope/scp) or roles.

A typical flow: the user signs in at an identity provider, which issues a signed JWT; the client sends it on each API call as Authorization: Bearer <token>; the API verifies the signature against the provider’s published public keys (a JWKS), checks the issuer, audience and expiry, and then reads the claims to make an access decision.

Because verification only needs the public key, asymmetric algorithms (RS256, ES256, EdDSA) are the standard choice for public APIs — the API never holds a secret that could mint tokens.

JWT signatures explained

The signature is what makes a JWT trustworthy. It is a Message Authentication Code (for HMAC) or a digital signature (for RSA/ECDSA/EdDSA) over the exact bytes of header.payload. Verifying it tells the recipient two things: the token was produced by someone holding the signing key, and it has not been altered in transit.

Symmetric (HMAC) signatures use a single shared secret for both signing and verifying — fast and simple, but every verifier can also forge tokens, so they suit closed, internal systems. Asymmetric signatures split the key in two: the issuer keeps a private signing key, and verifiers only ever see the public key, which cannot create tokens.

This tool performs real verification using the Web Crypto API. Paste the matching secret or public key and the toolkit will tell you definitively whether the signature is valid — the same check your server should perform on every request.

JWT security best practices (RFC 8725)

Always pin the algorithm. Decide server-side which algorithms you accept and reject everything else — never trust the token’s own "alg" header. This blocks the classic “alg:none” forgery and RS256→HS256 algorithm-confusion attacks.

Verify the signature, then the claims. Confirm the signature with a key from a trusted, pinned source (your JWKS), then validate iss, aud, exp and nbf. Reject tokens whose audience or issuer you do not recognise.

Keep payloads minimal and non-secret. A JWS payload is readable by anyone holding the token, so never include passwords, card numbers, private keys or sensitive PII. Use strong, random secrets (≥256-bit) for HMAC and rotate keys regularly.

Use short lifetimes and plan for revocation. Short exp values limit the damage of a leak; pair them with refresh tokens and, where needed, a jti blocklist so individual tokens can be revoked.

JWT expiration best practices

Set an exp on every token. A token without an expiration is valid forever and is one of the most common and dangerous JWT mistakes. Encode exp as a NumericDate — seconds since the Unix epoch, not milliseconds and not a string.

Right-size the lifetime. Access tokens are typically valid for 5–60 minutes; longer-lived sessions are handled with refresh tokens rather than long-lived access tokens. Include iat so consumers can enforce a maximum age, and use nbf if a token should only become valid in the future.

Allow a small clock-skew tolerance (a minute or two) when validating exp and nbf to absorb differences between server clocks, but no more — large tolerances weaken the guarantees that expiry is meant to provide.

# Send a JWT as a Bearer token
curl https://api.example.com/me \
  -H "Authorization: Bearer $JWT"