JWT Decoder
Decode and inspect any JSON Web Token — including Keycloak, Phase Two, OAuth 2.0, and OpenID Connect tokens. See the header, payload, claims, and roles in plain English, then verify the signature — all in your browser.
What is a JWT?
A JSON Web Token (JWT) is a compact, URL-safe way to represent claims between two parties. It is the backbone of modern authentication and authorization — OAuth 2.0 and OpenID Connect use JWTs for access tokens, ID tokens, and refresh tokens. A signed JWT (a JWS) is made of three parts — header.payload.signature — each base64url-encoded and joined with dots.
The header and payload are encoded, not encrypted, so anyone holding the token can read them. This tool splits the token, base64url-decodes the header and payload, and shows you the JSON inside along with friendly explanations of each claim.
How to get a JWT from your browser
If you need the token your app is actually using, you can grab it from your browser's developer tools (open them with F12, or Cmd+Option+I on macOS):
- Network tab — reload the page, click an API request, and look at the request headers for
Authorization: Bearer <token>. Copy everything afterBearer. You can also inspect the response of the token endpoint (for Keycloak,/protocol/openid-connect/token) to findaccess_tokenandid_token.
A JWT is three base64url chunks joined by dots (xxxxx.yyyyy.zzzzz). Copy the whole string — including both dots — and paste it above. Because everything is decoded locally, it is safe to do this even with a real production token.
Decode Keycloak & Phase Two access tokens
Keycloak and Phase Two issue access tokens packed with authorization data. This decoder recognizes them automatically and breaks out the parts that matter for debugging:
realm_access.roles— realm-level roles that apply across the whole realm.resource_access— client (resource) roles, grouped by the client they apply to.scope,azp,typ, andsession_state— the OAuth scopes, authorized party, token type, and session it belongs to.
That makes it fast to answer questions like “why doesn’t this user have the role my app expects?” without spelunking through raw JSON. For setup and configuration, see the Keycloak overview and our SSO docs.
Decode OAuth 2.0 & OpenID Connect tokens
Access tokens and ID tokens issued as JWTs decode the same way. The decoder highlights standard OAuth/OIDC claims — scope, aud, azp, nonce, email_verified — and converts the time claims (exp, iat, nbf, auth_time) into readable dates with a live expiry badge.
Decode vs. verify
Reading a token's contents (decoding) is not the same as proving it is genuine (verifying). Verification checks the cryptographic signature against the issuer's key and validates time-based and audience claims. Use the verification panel with a shared secret (HMAC), a PEM public key, or a JWKS URL — for Keycloak realms the JWKS endpoint is prefilled from the token's issuer. For the security model and common pitfalls, see our guide on JWT security best practices.
Learn more about JWTs
- Decoding JWT structure — a deep dive into each segment.
- JWT benefits and drawbacks — when to use them, and when not to.
- JWT security best practices — algorithms, expiry, revocation, and storage.
- Keycloak overview — how Phase Two and Keycloak issue and use tokens.
Frequently asked questions
Is it safe to paste my JWT here?
Yes. Decoding and verification happen entirely in your browser using client-side JavaScript. Your token, secrets, and keys are never transmitted to Phase Two or any other server, logged, or stored. You can confirm this by opening your browser's network tab while you decode.
What does a JWT contain?
A signed JWT has three base64url-encoded segments separated by dots: a header (algorithm and key metadata), a payload (the claims — data about the subject and token), and a signature (cryptographic proof the token wasn't tampered with). Decoding reveals the header and payload.
Does decoding a JWT verify it?
No. Anyone can read the contents of a JWT — the header and payload are only base64-encoded, not encrypted. Verifying a token means checking its signature against the issuer's key and validating claims like exp, nbf, iss, and aud. This tool can do both: decoding shows what's inside, and the signature verification panel proves it is authentic.
How do I decode a Keycloak access token?
Paste the access token into the decoder. It automatically recognizes Keycloak and Phase Two tokens and renders realm roles (realm_access), client/resource roles (resource_access), scopes, the authorized party (azp), and session info as readable lists — ideal for debugging role mappings and authorization issues.
What is the difference between realm_access and resource_access?
In a Keycloak token, realm_access.roles holds realm-level roles that apply across the whole realm, while resource_access maps each client (resource) to the roles the subject holds on that specific client. The decoder separates and labels both so you can see exactly which roles a token carries and where.
Can I decode an OAuth 2.0 access token or an OpenID Connect ID token?
Yes. OAuth 2.0 access tokens and OIDC ID tokens issued as JWTs decode the same way. The decoder highlights standard OAuth/OIDC claims such as scope, aud, azp, nonce, and email_verified, and converts time claims (exp, iat, nbf, auth_time) into human-readable dates.
How do I verify a Keycloak JWT signature?
Use the signature verification panel and choose JWKS URL. For a Keycloak realm the decoder prefills the certs endpoint from the token's issuer (for example https://host/realms/your-realm/protocol/openid-connect/certs). It fetches the public keys, matches by key id (kid), and checks the signature. HMAC secrets and PEM public keys are also supported.
Why does my token show as expired?
The decoder compares the exp (and nbf) claims against your current time and shows the result. An expired badge means the token's lifetime has passed — the signature may still be valid, which is why verification and expiry are reported separately.