JWT Parser Online — Free Client-Side Inspector

What a JWT Parser Actually Does

A JSON Web Token looks intimidating — a long random-looking string that starts with something like eyJhbGciOiJIUzI1NiIs.... But it is not random and not encrypted (unless it is a JWE, which is different). It is three regular JSON documents Base64URL-encoded and joined with dots.

The parser reverses that process. It splits on the dot character, decodes each segment from Base64URL back to raw JSON, and pretty-prints the result. Timestamp claims like exp, iat, and nbf are converted from Unix seconds to human-readable ISO 8601 dates. The signature (third segment) cannot be converted to text — it is a binary hash — so most parsers show its raw Base64URL form and skip verification (which requires the signing key you do not have).

Anatomy of the JWT You Are Parsing

The Header (Before the First Dot)

The header is a small JSON object describing how the token is signed. Typical content:

{
  "alg": "RS256",
  "typ": "JWT",
  "kid": "abcd1234efgh5678"
}

• alg — the signing algorithm. Common values: HS256 (HMAC + SHA-256), RS256 (RSA + SHA-256), ES256 (ECDSA + SHA-256), EdDSA.
• typ — the token type, almost always "JWT". Rarely "JWS" or "at+jwt" for access tokens.
• kid — the key ID. Identity providers with multiple signing keys (rotated for security) include a kid so verifiers know which key to fetch from the JWKS endpoint.

The Payload (Between the Dots)

The payload holds the claims — the actual data the token proves about the user. Standard claims are three-letter abbreviations from RFC 7519:

{
  "iss": "https://auth.example.com",
  "sub": "user_abc123",
  "aud": "https://api.example.com",
  "exp": 1893456000,
  "iat": 1893452400,
  "nbf": 1893452400,
  "jti": "unique-token-id-xyz",
  "scope": "read:profile write:profile",
  "email": "[email protected]",
  "role": "admin"
}

• iss (issuer) — who created this token
• sub (subject) — who this token is about (the user ID)
• aud (audience) — who this token is for (an API URL)
• exp (expiration) — Unix timestamp when this token becomes invalid
• iat (issued at) — Unix timestamp when this token was created
• nbf (not before) — Unix timestamp before which this token is not valid
• jti (JWT ID) — unique identifier for this specific token (used for revocation)

The Signature (After the Second Dot)

The signature is a cryptographic hash of the header and payload, computed using the signing algorithm and either a shared secret (HS256) or a private key (RS256, ES256). It ensures no one has tampered with the token in transit. The parser cannot verify the signature without the key — but it can show you the raw signature bytes so you can pass them to a verify-jwt-signature tool along with the key.

Reading the Alphabet Soup of JWT Claims

Beyond the standard registered claims, most tokens carry app-specific fields. Here is a decoder ring for what you will commonly see:

scope

Space-separated list of OAuth scopes granted (e.g. "read:users write:users"). Your API checks these to authorize specific endpoints.

role / roles

User role(s). Sometimes a string, sometimes an array. Different from scope — a role usually implies a bundle of scopes.

permissions

Auth0 style — an array of granular permissions attached to the token.

email

User's email address. Present in ID tokens; sometimes access tokens.

email_verified

Boolean — whether the email was confirmed via link/code.

azp

Authorized party — the client ID of the app that requested this token.

cid

Client ID (Okta convention). Same idea as azp.

token_use

Cognito — either "access" or "id" depending on which token you decoded.

cognito:groups

Cognito user pool groups the user belongs to.

hd

Google — hosted domain (Google Workspace domain).

When to Use a JWT Parser vs a Verifier

• Use a parser when you want to see what is inside a token — during development, debugging a 401, or explaining an auth flow to a colleague.
• Use a verifier when you need to prove a token is authentic — before making authorization decisions in production code.
• Never trust parsed claims for security. The parser reads whatever the token says without checking who signed it. An attacker can craft a token with any claims they want; only signature verification proves the token came from your trusted issuer.

Privacy: Why Client-Side Matters

Every access token is a bearer credential — whoever holds it can act as the user until it expires. That makes JWTs sensitive data on par with passwords. Sending them to a server-side parsing service means trusting that server not to log, cache, or leak the token.

Our parser runs entirely in your browser using JavaScript's built-in atob() function and standard string manipulation. No fetch, no XHR, no analytics beacon fires when you paste. You can prove this: open browser DevTools → Network tab → paste a token → observe zero requests. For maximum paranoia, disconnect from the internet before pasting a production token.

Comparison to jwt.io and Other Tools

Related JWT Tools

• JWT Decoder Online — decoder overview with quick examples
• JWT Token Decoder — token-focused walkthrough with provider examples
• Verify JWT Signature — signature verification with your key
• JWT Expiration Checker — dedicated exp/iat/nbf inspection
• JWT Generator Online — create signed test tokens in-browser