JWT Parser

Introduction

Integrating with OAuth providers means living inside JWT claim structures — nested namespaces, array audiences, custom permissions encoded as strings or JSON blobs. Decoding the raw Base64URL segments is step one; step two is understanding what each claim means, whether timestamps indicate expiry, and whether the token structure matches what your middleware expects. Manual base64 decoding in a terminal works, but parsing claim semantics across providers slows debugging.

Certoflow's JWT Parser goes beyond raw decoding: it ingests a JSON Web Token, extracts header and payload claims, interprets standard registered claims, and surfaces structured fields for inspection. All parsing runs in your browser — bearer tokens from staging environments, customer sessions, and internal service accounts never leave your device.

What this tool does

The parser accepts a compact JWT string and produces an analyzed breakdown:

Section	Parser output
Token structure	Validates three-segment JWS format
Header fields	alg, typ, kid, x5t, custom keys
Registered claims	iss, sub, aud, exp, iat, nbf, jti with human labels
Custom claims	Application-specific keys (roles, tenant, permissions)
Temporal analysis	Expiration relative to current time when supported
Signature segment	Encoded reference (verification not performed)

Copy individual JSON sections, clear fields, or load examples through standard Certoflow toolbar controls.

How it works

Parsing pipeline in the browser:

1. Normalize input — trim whitespace, strip optional Bearer prefix.
2. Segment split — validate exactly three dot-separated parts for JWS.
3. Base64URL decode — convert -/_ alphabet, handle optional padding, decode header and payload bytes.
4. JSON parse — parse decoded UTF-8 into objects.
5. Claim classification — map known registered claim names to descriptions; list unknown keys as custom claims.
6. Time interpretation — convert NumericDate claims (exp, iat, nbf) to readable UTC/local strings.

// Conceptual flow (simplified)
const [headerB64, payloadB64, signatureB64] = token.split('.');
const header = JSON.parse(base64UrlDecode(headerB64));
const payload = JSON.parse(base64UrlDecode(payloadB64));

Registered claims from RFC 7519:

Claim	Name	Purpose
iss	Issuer	Who created the token
sub	Subject	User or entity identifier
aud	Audience	Intended recipient(s)
exp	Expiration	Valid until (NumericDate)
nbf	Not Before	Valid after
iat	Issued At	Creation time
jti	JWT ID	Unique token identifier

No server-side key fetch, no JWKS download, no signature verification — purely local structural and semantic parsing.

Real-world examples

Middleware claim path debugging

Your Express middleware reads req.user.roles from payload['https://api.example.com/roles']. Parser output confirms exact key spelling — a trailing slash in namespace URI breaks lookup silently.

Multi-audience token inspection

Azure AD tokens sometimes emit "aud": ["api://app1", "api://app2"] or a single string. Parser shows type (string vs array) so your validation library config matches reality.

Service account token lifetime audit

Kubernetes projected service account tokens include "exp" far in the future or bound to pod lifetime. Parse tokens from staging pods before tightening cluster security policies.

Auth0 Action custom claims

Post-login Actions add claims like "permissions": ["read:reports"]. Parser verifies Action deployment added claims before blaming API authorization.

Identifying algorithm downgrade risks

Header shows "alg": "HS256" when you expect "RS256". Parser highlights header first — algorithm confusion attacks start with unexpected alg values.

Workshop: mapping OIDC ID token to user profile

Students parse ID tokens from authorization code flow, locate email, email_verified, and preferred_username, and relate them to database user records.

Common mistakes

Confusing parsing with trust. Parsed claims are readable; they are not verified. Attackers craft plausible payloads. Always verify signatures server-side.

Ignoring audience type. Code expecting string aud fails when provider sends array. Parser reveals type; fix validation accordingly.

Misinterpreting string-encoded JSON claims. Some providers set "user_metadata": "{\"plan\":\"pro\"}" as a string. Parser shows string type — application must JSON.parse again.

Assuming all time claims exist. Missing exp means no expiration in token — your verifier must reject or apply default TTL policy.

Parsing encrypted JWE as JWS. Five-part tokens fail JWS parsing. Identify encryption via header "enc" field and use appropriate tooling.

Logging parsed tokens in production. Parser aids local debug; production apps should never log full tokens or claims containing PII.

Using parser output for authorization decisions client-side. Browser-parsed roles are attacker-controlled without verification. Authorization belongs on the server after signature check.

Use cases

Backend developers mapping issuer-specific claim layouts during SSO integration sprints.

Frontend engineers confirming access token scopes before attaching Authorization headers in SPA API clients.

Security engineers reviewing token lifetime policies, sensitive claim exposure, and algorithm choices during penetration test remediation.

Platform teams validating Istio, Kong, or AWS ALB JWT formats at gateway boundaries.

QA automation authors extracting expected claim values to assert against parser output in manual test checklists.

Identity architects documenting claim contracts between authorization server and resource servers for cross-team alignment.

FAQ

Is my JWT uploaded to a server?

No. Parsing executes entirely in your browser.

What's the difference between JWT Parser and JWT Decoder?

Both decode Base64URL segments. The Parser emphasizes structured claim analysis, registered claim labeling, and temporal interpretation — optimized for integration debugging rather than raw JSON display alone.

Does the parser verify signatures?

No. Use your authorization server's JWKS endpoint and a verification library (jsonwebtoken, jose, PyJWT) in application code.

Can it parse nested objects in claims?

Yes. JSON objects and arrays in payload display with structure. String values that contain JSON show as strings until you parse them separately.

How are expiration warnings calculated?

When exp is present, the tool compares NumericDate to current Unix time and indicates expired or time-remaining when implemented.

What about opaque refresh tokens?

Non-JWT refresh tokens have no segments to parse. If it looks like eyJ... with two dots, try parsing.

Can I parse tokens from Apple Sign In or Google?

Yes, for JWT-formatted identity tokens. Strip prefixes and paste the compact serialization.

Does parser support JWE (encrypted JWT)?

JWE uses five segments and different processing. Standard three-part JWS is the primary target.

Why do I see unicode escape sequences in claim values?

Some issuers encode international names as \uXXXX in JSON. Parsed output preserves decoded Unicode when possible.

Can I use this offline?

Yes, after the page loads.