Parse a three-segment JSON Web Token into UTF-8 JSON header and payload objects, inspect registered/custom claims and timing, and view signature bytes without verifying trust. Essential for developers debugging authentication flows, inspecting token contents, and diagnosing expiry or audience mismatches locally.
JWT tools
JWT Token
Drag & drop supported
Awaiting input. Select a demo token to instantly populate the interface.
A standard JWT consists of three Dot-separated . chunks: the Header defining the cryptographic operations, the Payload storing entity properties, and the Signature verifying trust.
Decoded OAuth Payload Claims (${count})
Paste a JWT token on the left to decode.
Decode compact three-part JWTs for inspection only: readable claims are not proof of signature, issuer, audience, key, or authorization validity.
Follow this implementation-specific workflow for JWT Decoder; each step reflects the controls and limits in the current browser workspace.
Step 1
Paste or import the complete compact token, including both dots; do not paste a Bearer prefix, surrounding quotes, or a five-segment JWE.
Step 2
Choose a sample only for learning, or retain the exact production token needed for diagnosis; decoding never requires a key.
Step 3
Run Decode JWT and let the parser Base64URL-decode both JSON sections as UTF-8 objects.
Step 4
Review the alg header, exp/nbf/iat status, issuer, audience, subject, and custom claims while treating the signature display as bytes, not validation.
Step 5
Copy only the needed diagnostic data, then pass the unchanged token and correct key material to JWT Verifier or the issuing service’s full validation path.
Consequence: Anyone can Base64URL-encode a new payload; this decoder does not verify the signature or bind the token to an issuer and audience.
Fix: Use JWT Verifier for supported HMAC tokens and enforce issuer, audience, algorithm, lifetime, and authorization policy in the receiving system.
Consequence: A JWE has five sections and “Bearer …” contains spaces, so the three-section/Base64URL validator rejects it.
Fix: Remove the authorization scheme prefix and use this tool only for a compact three-segment JWT/JWS with JSON header and payload.
Consequence: RFC 7519 NumericDate values are seconds since the Unix epoch; millisecond values display dates far outside the intended range.
Fix: Confirm the issuer uses seconds and compare the raw numeric claim with an epoch converter before drawing a timing conclusion.
Decode the unchanged token for claim diagnosis, inspect nested data, then verify supported HMAC signatures with the correct secret.
The first two Base64URL sections decode to UTF-8 JSON objects. The third section is visualized, but no secret or public key is used by this decoder.
No. The iss claim is merely decoded text until a trusted verifier checks the signature and applies an issuer allowlist.
The structural validator allows an empty third section and records a warning so malformed or alg=none samples can be inspected; it does not make them trustworthy.
No. Compact JWE uses five segments and encrypted content; this implementation accepts exactly three segments containing JSON header and payload.
Numeric exp and nbf are compared with the browser clock in whole Unix seconds; iat in the future becomes a warning in the shared validator.
No. Whitespace, property order, Base64URL bytes, and especially the signature are part of the compact token; any payload change requires a new valid signature.
The compact token and decoded claims remain in browser memory and are not uploaded. The decoder works offline after assets are cached, but copied output, downloaded files, screenshots, browser extensions, and optional local features remain under your control.
