How do I verify the signature?

The tool can verify an ID Token signed with RS256, RS384, or RS512 in two ways: JWKS URL (recommended) — paste the provider's .well-known/jwks.json URL and the keys are fetched and cached automatically. The tool matches the key whose kid matches the token header, so key rotation is handled for you. Manual JWK — paste a single JWK, a keys array, or a full JWKS document into the JWK field. RS256, RS384, and RS512 are supported. The signature is verified locally with the Web Crypto API — the only network request is the JWKS fetch from the URL you enter.

How do I tell an ID Token from an Access Token?

Both can look like JWTs, but they prove different things. This tool detects the difference automatically from the claims: at_hash present — this is an ID Token issued by the Authorization Code flow . at_hash is the hash of the access token that was issued alongside it. azp present — an ID Token marker. azp (authorized party) is the client the ID Token was issued for. scope claim present — typical of access tokens , not ID Tokens. Access tokens rarely carry user identity. The tool shows these markers as badges and gives a verdict — ID Token, access token, or ambiguous.

What does the validation checklist show?

The checklist turns the tool's status line into a documented, per-claim report: Which checks passed (green ✓), failed (red), are pending/incomplete (amber), or are absent/informational (grey –, e.g. when no expected value is configured). Live exp and nbf countdowns that update every second. Issuer/audience mismatches shown with the actual vs expected values. Signature validity once a JWK or JWKS URL is provided. The overall banner summarizes the result: All checks passed , One or more checks failed , or Checks incomplete .

What claims are in an OIDC ID Token?

A standard OIDC ID Token contains these required claims: sub — your user's unique identifier at the identity provider iss — the issuer URL aud — the intended client application ID exp — expiration time as Unix timestamp iat — issued-at time Optional but common claims include email , name , picture , locale , and nonce (a random value to prevent replay attacks). The tool formats the decoded header and payload as readable JSON for easy inspection.

OIDC ID Token Decoder & Verifier

Decode an OIDC ID Token (or a URL-encoded id_token_hint), auto-fetch the provider's JWKS to verify the RSA signature (RS256/384/512), and run a documented aud → iss → exp → nbf → nonce → sig validation checklist — all in your browser.

Decode / Verify

Paste a token to decode; add a JWKS URL or JWK to verify the signature.

ID Token (JWT)

This is an id_token_hint (URL-encoded ID Token). Percent-encoded hints are also auto-detected when pasted directly.

Signing key

JWKS URL (e.g. https://accounts.google.com/.well-known/jwks.json)

Keys load automatically when a URL is entered.

Expected Issuer (iss, optional)

Expected Audience (aud, optional)

Expected Nonce (optional)

What is OIDC ID Token?

An OIDC ID Token is a signed JWT issued by an OpenID Connect provider (like Google, Auth0, or Keycloak) that contains claims about an authenticated user. It is the core artifact of the OIDC protocol — your app receives it after a user successfully logs in.

Standard claims include sub (subject/user ID), iss (issuer), aud (audience), exp (expiration), iat (issued at), and optionally nonce (replay protection).

Always signed — typically RS256 (RSA + SHA-256); RS384 and RS512 are also supported. You verify it with the provider's public key.

Not an access token — ID Tokens prove who the user is; access tokens grant API access. A token carrying at_hash or azp is an ID Token; a token carrying a scope claim is likely an access token. Don't confuse them.

Zero-Server Tool Data Guarantee

All decoding, JWKS fetching, and signature verification happens entirely in your browser using the Web Crypto API. Your tokens and keys are never sent to any server — the only network request is the JWKS fetch from the URL you choose to enter.

How to Use

Paste Your ID Token

Input the OIDC ID Token (JWT) you want to inspect. Decoding is debounced, so it runs a moment after you stop typing.

Decode a URL-Encoded id_token_hint

Enable the 'id_token_hint' checkbox for URL-encoded tokens from logout requests. Percent-encoded hints are also auto-detected when pasted directly.

Add the Signing Key

Paste a JWKS URL and the keys load automatically, or switch to Manual and paste a JWK. The key matching the token's kid is used for RS256/384/512 verification.

Set Expected Values

Fill in the expected issuer, audience, and nonce to activate those checks in the validation checklist.

Review the Checklist

The documented validation order (aud → iss → exp → nbf → nonce → sig) is shown as a live checklist, with at_hash/azp/scope detection for ID vs access token identification.

Common Use Cases

Post-Login Debugging

Paste an ID Token right after login to inspect claims, confirm the issuer/audience, validate the nonce, and verify the signature before trusting it in your app.

Token Validation Debugging

Diagnose why a token is being rejected — check audience mismatch, issuer mismatch, expiration, or a nonce failure in seconds.

Integration Testing

Quickly verify that your OIDC provider is issuing correctly structured tokens with the expected claims.

Logout / id_token_hint Debugging

Decode a URL-encoded id_token_hint from your logout redirect to confirm which session the provider should terminate.

ID vs Access Token Auditing

Spot at_hash, azp, and scope claims to determine whether a captured token is an ID Token or an access token during a security review.

Security Auditing

Manually inspect tokens from production logs (redacted) to confirm claim values during a security review.

Implementation Examples

JavaScriptFetch JWKS & Verify (jose)

// Install: npm install jose
import * as jose from 'jose';

const issuer = 'https://accounts.google.com';
const audience = 'your-client-id';
const nonce = 'f47ac10b-58cc-4372-a567-0e02b2c3d479'; // what you sent in auth request

const { keys } = await fetch(issuer + '/.well-known/jwks.json')
    .then(r => r.json());

const { payload } = await jose.jwtVerify(
    token,
    await jose.createLocalJWKSet({ keys }),
    { issuer, audience }
);

// Nonce validation — replay protection
if (payload.nonce !== nonce) throw new Error('Nonce mismatch');

console.log(payload.sub); // user ID

ID Token vs Access Token vs Refresh Token

Property	ID Token	Access Token	Refresh Token
Purpose	Prove user identity	Access protected APIs	Get new access tokens
Format	JWT (always)	JWT or opaque	JWT or opaque
Contains user info	Yes (claims)	Rarely	No
Lifespan	Minutes (5-15 min)	Minutes to hours	Days to months
Stored where?	Secure memory / httpOnly cookie	Memory / httpOnly cookie	httpOnly cookie only
Sent to APIs?	No	Yes (Authorization header)	No

Production Best Practices & Security

Always verify the signature — a decoded token without signature verification is just untrusted data. Why:Without verification, an attacker could forge their own "ID Token" with fake user details and gain access to your application.

Fetch JWKS dynamically — use the provider's /.well-known/jwks.json endpoint and cache keys with proper rotation handling. Why:Providers rotate their signing keys periodically for security; this tool fetches and matches keys by kid automatically.

Validate the issuer (iss) — ensure the token was issued by the provider you expect, not a malicious actor. Why:This prevents "Issuer Confusion" attacks where a malicious OIDC provider issues a valid token that your app mistakenly accepts.

Check the audience (aud) — confirm your client_id is in the audience to prevent token misuse across apps. Why:If an attacker gets an ID token intended for another app, audience validation prevents them from using it to log into your app.

Validate the nonce — compare the token's nonce to the value you sent in the authorization request. Why:A mismatched or absent nonce means a replay attack is possible.

Enforce expiration (exp) and not-before (nbf) — reject expired or early tokens server-side. Why:Expired tokens are a security risk; once a token expires, the user must re-authenticate to prove they still have access.

Follow the documented validation order — aud, iss, exp, nbf, nonce, then signature (the final gate). Why:Ordering makes failures diagnosable and covers the same claims compliant libraries validate, with the signature as the final gate.

Don't store ID Tokens in localStorage — use httpOnly cookies or secure in-memory storage to prevent XSS theft. Why:LocalStorage is accessible by any JavaScript running on your page. If your site has an XSS vulnerability, attackers can steal your users' tokens instantly.

How the OIDC Authorization Code Flow Works

User opens your app and clicks Sign in.
Your app redirects the browser to the provider's login page.
After the user signs in, the provider redirects back with an authorization code.
Your app exchanges the code (with its client secret) and receives an ID Token — the JWT this tool decodes.

Frequently Asked Questions

An OpenID Connect (OIDC) ID Token is a signed JWT that your identity provider issues after authenticating a user.

It contains claims defined by the OpenID Connect specification: sub (the user's unique identifier), iss (the issuer URL), aud (the intended client application), exp (expiration time), and optionally nonce, email, name, and picture.

Unlike an access token (which authorizes API access), the ID Token is specifically for your client application to authenticate the user. You must verify it by validating the signature using the issuer's public keys from the JWKS endpoint.

The tool can verify an ID Token signed with RS256, RS384, or RS512 in two ways:

JWKS URL (recommended) — paste the provider's .well-known/jwks.json URL and the keys are fetched and cached automatically. The tool matches the key whose kid matches the token header, so key rotation is handled for you.
Manual JWK — paste a single JWK, a keys array, or a full JWKS document into the JWK field.

RS256, RS384, and RS512 are supported. The signature is verified locally with the Web Crypto API — the only network request is the JWKS fetch from the URL you enter.

This tool documents the validation as a checklist in the order aud, iss, exp, nbf, nonce, then signature:

1. aud — confirm your client_id is in the audience so the token was issued for your app, not someone else's.
2. iss — confirm the issuer is the provider you expect, which prevents issuer confusion attacks.
3. exp / nbf — reject expired tokens and accept tokens only inside their validity window.
4. nonce — compare the token's nonce to the value you sent in the authorization request to block replay attacks.
5. sig — the final gate. The signature proves the token really was issued by the provider that holds the corresponding private key.

In practice the signature is the foundation of everything else — verify it before acting on any claim. The checklist covers the same claims that production OIDC libraries validate — with the signature as the final gate — so failures are easy to diagnose.

The nonce is a random, single-use value your app generates and sends with the authorization request; the provider echoes it back in the ID Token.

To validate it, enter the exact nonce your app used in the Expected Nonce field. The checklist then reports whether the token's nonce claim matches, mismatches, or is missing entirely.

A mismatch or an absent nonce means the token may be a replay — reject it. OIDC recommends a minimum of 128 bits of entropy for the nonce so it cannot be guessed.

Both can look like JWTs, but they prove different things. This tool detects the difference automatically from the claims:

at_hash present — this is an ID Token issued by the Authorization Code flow. at_hash is the hash of the access token that was issued alongside it.
azp present — an ID Token marker. azp (authorized party) is the client the ID Token was issued for.
scope claim present — typical of access tokens, not ID Tokens. Access tokens rarely carry user identity.

The tool shows these markers as badges and gives a verdict — ID Token, access token, or ambiguous.

An id_token_hint is a full ID Token passed, usually URL-encoded, as a query parameter to a provider endpoint — most commonly the logout (end_session) endpoint, where it tells the provider which session to terminate.

Because it travels in a URL, the token is percent-encoded. This tool decodes it automatically when pasted directly, or you can enable the 'id_token_hint (URL-encoded)' checkbox. The decoded header, payload, and validation checklist behave exactly like a normal ID Token.

The checklist turns the tool's status line into a documented, per-claim report:

Which checks passed (green ✓), failed (red), are pending/incomplete (amber), or are absent/informational (grey –, e.g. when no expected value is configured).
Live exp and nbf countdowns that update every second.
Issuer/audience mismatches shown with the actual vs expected values.
Signature validity once a JWK or JWKS URL is provided.

The overall banner summarizes the result: All checks passed, One or more checks failed, or Checks incomplete.

A standard OIDC ID Token contains these required claims:

sub — your user's unique identifier at the identity provider
iss — the issuer URL
aud — the intended client application ID
exp — expiration time as Unix timestamp
iat — issued-at time

Optional but common claims include email, name, picture, locale, and nonce (a random value to prevent replay attacks).

The tool formats the decoded header and payload as readable JSON for easy inspection.

Use an identity provider's test mode or sandbox environment. Google provides test tokens at accounts.google.com, Auth0 has a test application in every tenant, and Keycloak offers a built-in test flow.

For local development, use the OIDC playground (oidc-debugger.com) or libraries like oidc-client-js that handle the full authentication flow.

Paste the resulting ID Token into BetterPass's OIDC tool to decode its claims and verify the signature.

Yes. ID Token decoding and RSA signature verification happen entirely in your browser with the Web Crypto API. Your token, the JWK you paste, and your expected issuer/audience/nonce are never sent to any server.

The only network request is the JWKS URL you choose to enter — it is fetched directly from your browser so the public signing keys can be matched to the token's kid. Nothing is stored or logged.

Point this decoder at Google and let it do the heavy lifting: enter https://www.googleapis.com/oauth2/v3/certs in the JWKS URL field and set the Expected Issuer to https://accounts.google.com. The keys are fetched and the one matching your token's kid is picked automatically.

Google signs ID Tokens with RS256 and rotates keys regularly, so always fetch fresh keys rather than pinning an old one. One thing to keep in mind: Google's sub is a stable, provider-wide identifier — build your user identity on it instead of the email address, which a user can change.

Microsoft Entra ID uses one issuer and one key set per tenant. For a tenant ID of {tenant}, the issuer takes the form https://login.microsoftonline.com/{tenant}/v2.0.

Drop the matching keys endpoint — https://login.microsoftonline.com/{tenant}/discovery/v2.0/keys — into the JWKS URL field, set the expected issuer above, and the tool verifies the signature against the key that matches the token's kid. Because Microsoft rotates signing keys roughly every six weeks, fetching them live (as this tool does) beats copying a stale key.

Auth0's issuer and keys depend on your tenant domain. For a tenant at example, the issuer is https://example.auth0.com and the JWKS endpoint is https://example.auth0.com/.well-known/jwks.json.

Paste the keys URL into the JWKS URL field and set the expected issuer to https://example.auth0.com. The tool fetches the key set, selects the key by kid, and verifies the RSA signature locally. The discovery document at https://example.auth0.com/.well-known/openid-configuration lists the JWKS URI and supported algorithms.

Keycloak uses a realm-based URL structure. For a realm named myrealm on a host https://sso.example.com, the issuer is https://sso.example.com/realms/myrealm.

Paste the keys endpoint — https://sso.example.com/realms/myrealm/protocol/openid-connect/certs — into the JWKS URL field and set the expected issuer above. The tool fetches the key set, selects the key by kid, and verifies the RSA signature locally. The discovery document at https://sso.example.com/realms/myrealm/.well-known/openid-configuration points to the same JWKS URI.