JWT Decoder
Paste a JSON Web Token to decode its header and payload, inspect claims like expiration and subject, and verify HMAC signatures — all locally in your browser.
Encoded JWT
Token claims
Header
Payload
Signature
Verify HMAC signature:
Paste a JSON Web Token to decode its header and payload, inspect claims like expiration and subject, and verify HMAC signatures — all locally in your browser.
Encoded JWT
Token claims
Header
Payload
Signature
In short: A JWT decoder takes a JSON Web Token — the long, dot-separated string used for authentication and API access — and converts its base64url-encoded header and payload back into readable JSON, so you can inspect exactly what claims it contains. RealJSON's decoder also flags whether the token is expired and can verify HMAC signatures, all without sending the token anywhere.
A JSON Web Token (JWT, pronounced "jot") is a compact, URL-safe way to represent claims between two parties — most commonly used to prove a user is authenticated after logging in. A JWT looks like three blocks of seemingly random characters separated by dots: header.payload.signature. The header and payload are not encrypted — they're just base64url-encoded JSON — so anyone who has the token can read what's inside. The signature is what makes a JWT trustworthy: it lets the receiving server verify the token was issued by a party that knows the signing secret or private key, and that nobody has tampered with its contents.
Because the header and payload are just encoded JSON, decoding a JWT is purely a matter of base64url-decoding two strings and parsing the result — no cryptography required to read the contents. RealJSON's decoder does exactly that, instantly, in your browser, and additionally offers local HMAC signature verification for the most common signing algorithm.
A small JSON object specifying the token type (typically "typ": "JWT") and the signing algorithm, such as "alg": "HS256" or "alg": "RS256".
The actual data, expressed as "claims" — registered claims like exp (expiration), iat (issued at), sub (subject/user ID), iss (issuer), and aud (audience), plus any custom claims an application adds — roles, permissions, tenant IDs, and so on.
A cryptographic signature computed over the encoded header and payload using a secret (HMAC algorithms like HS256) or a private key (RSA/ECDSA algorithms like RS256, ES256). The receiving server recomputes this signature and compares it — if they match, the token is authentic and unmodified.
Decoding a token turns an opaque string into something you can actually reason about. It's the fastest way to answer questions like: Is this token expired, and when exactly does it expire? Which user ID, roles, or scopes did the identity provider issue? Is the issuer (iss) and audience (aud) what your backend expects? Did a recent change to your auth provider's configuration actually take effect in newly issued tokens?
For HMAC-signed tokens, signature verification adds another layer: you can confirm that a token was genuinely signed with a secret you control, which is useful when debugging "invalid signature" errors between services, testing your own token-issuing code, or confirming a shared secret matches across environments.
Once you've decoded a token's payload, use the JSON Formatter or JSON Viewer to inspect it more closely, or the JSON Validator to confirm the claims structure is well-formed JSON.
Browse all free JSON tools →
Paste the encoded token into the decoder. It splits the token into its header, payload, and signature, base64url-decodes the header and payload into readable JSON, and highlights common claims like exp, iat, and sub — instantly, in your browser.
Three dot-separated, base64url-encoded parts: a header describing the signing algorithm and token type, a payload containing claims (user ID, expiration, issuer, and so on), and a signature used to verify the token hasn't been tampered with.
Yes. If the payload has an exp (expiration) claim, the decoder converts it to a readable date and shows whether the token is still valid or has expired based on your current system time — and does the same for nbf ("not before") and iat ("issued at").
Yes, for HMAC-signed tokens (HS256, HS384, HS512) — enter the signing secret and the tool recomputes and compares the signature locally using your browser's Web Crypto API. RSA/ECDSA tokens (RS256, ES256, etc.) are decoded but can't be verified without a matching public key, which isn't supported yet.
Decoding and verification both run entirely client-side using your browser's Web Crypto API — the token and any secret you enter are never sent to or stored on a server. As general practice, though, prefer a disposable or already-expired token over a live production one wherever possible.
It's the fastest way to see what an identity provider or your own backend is actually putting into a token — useful for debugging "why is this user unauthorized," confirming expiration times, checking issued scopes or roles, or verifying a signing-config change took effect.
Related tools