Strict local JWT inspection
Decode a compact JWT header and payload into readable, lossless JSON. Inspect exp, nbf, and iat while the page keeps the essential boundary visible: decoded data is not a verified identity.
header.alg "RS256" payload.sub "user-123" payload.exp 1893456000 decode complete signature "not verified"
Readable claimsUntrusted until verified
Three-part compact JWS
Paste a compact JWT or a copied Bearer value. The decoder validates unpadded Base64URL, fatal UTF-8, JSON object structure, duplicate names, and NumericDate types entirely in this browser tab.
Loading the local JWT decoder…
Your token stays in this page.
What this tool actually does
A JSON Web Token is commonly represented as three dot-separated text segments. For a signed JWS compact token, the first segment contains the JOSE protected header, the second contains the JWT Claims Set, and the third contains signature or MAC bytes. The first two segments use Base64URL encoding without padding. Decoding reverses that encoding, validates UTF-8, and parses the resulting JSON objects.
No secret is needed for this step because Base64URL is an encoding, not encryption. Anyone who receives a normal signed JWT can read its header and payload. That makes a decoder useful for debugging an integration, checking claim names, understanding a token issued in a test environment, or comparing timestamps. It does not make the claims authentic.
LiveParse separates the result into three independent ideas. “Decoded” means the segments could be interpreted under strict syntax rules. “Signature not verified” means no cryptographic decision was made. The time result evaluates only the untrusted values of exp and nbf against your browser clock. Keeping those states separate prevents a readable or unexpired token from being labeled “valid.”
The parser preserves JSON number text instead of converting every number to a JavaScript Number. That matters for identifiers beyond 253 and fractional NumericDate values. Duplicate decoded property names—including equivalent escaped spellings—remain visible and are reported as ambiguous rather than silently applying last-value-wins behavior.
Header.payload.signature
A compact signed JWT usually travels as one string, but every segment has a different job and a different trust implication.
The header often declares alg, typ, and possibly kid. These values are attacker-controlled until verification. An application must not accept whatever algorithm or key location a token asks for; it needs a configured allowlist and trusted key selection rules.
The payload is a JSON object containing registered claims such as iss, sub, aud, exp, nbf, iat, and jti, plus private claims defined by the application. Decoding reveals assertions, not facts.
The final bytes bind the exact encoded header and payload to a cryptographic key when verified correctly. This decoder reports their length and a short hex preview but never calls them valid, never asks for a key, and never tries a remote JWKS URL.
Compact JWE uses five segments, so a five-part value may contain encrypted claims rather than a readable signed JWT payload. Segment count alone does not validate JWE. The tool stops without decrypting it; authenticated decryption requires the expected algorithms, recipient key, and complete format checks.
Security boundary
Header and payload JSONWhether those exact bytes were protected by an expected signer using a trusted key.The untrusted alg labelWhether that algorithm is explicitly allowed and used with the correct kind and strength of key.A local time comparisonWhether the verified issuer asserted the value and the application accepts its clock-skew policy.Decoded aud or scope textExact issuer, audience, subject, tenant, nonce, replay, scope, and authorization requirements.Registered claim names
iss identifies the issuer that says it created the token. sub identifies the subject in that issuer’s namespace. aud names the intended recipient and can be one string or an array of strings. A decoder can display all three, but only a verifier configured for the expected issuer and audience can decide whether they are acceptable.
exp is the expiration time: the current time must be before it. At the exact boundary where current time equals exp, the time window has expired. nbf is the not-before time: the current time must be at or after it. Implementations may allow a small, explicit leeway for clock differences. This page defaults that leeway to zero so a relaxation never happens invisibly.
iat records when the token was issued. It is useful for age, rotation, or replay policy, but RFC 7519 does not turn it into a universal pass/fail rule. A future iat may be suspicious or may reflect clock drift; the consuming application decides. jti is a token identifier that can participate in replay prevention when the application stores and checks it.
NumericDate counts seconds from the Unix epoch and may include a fractional part. The decoder compares supported values with exact nanosecond arithmetic rather than rounding through floating point. Wrong JSON types, duplicate claim names, excessive fractional precision, and dates outside the supported calendar range produce an indeterminate time result instead of a guess.
Protocol-aware parsing
JWT compact segments use the URL-safe - and _ alphabet without = padding. The decoder rejects standard + and /, embedded whitespace, impossible lengths, misplaced padding, and non-zero unused pad bits instead of repairing unknown input silently.
The decoded JSON must be valid UTF-8. Invalid byte sequences are not replaced with a placeholder character because that could change property names or values. A byte-level error stops the affected segment with a clear diagnostic.
Both the JOSE header and the JWT Claims Set must be JSON objects. Arrays, primitives, trailing content, excessive nesting, and syntax errors are rejected. Duplicate names stay visible and are marked as security issues rather than collapsed.
RFC 7797 defines a JWS option named b64:false, but it explicitly must not be used with JWTs. The decoder refuses this option instead of treating an unencoded payload as an ordinary JWT Claims Set.
Sensitive data handling
The decoding operation runs in JavaScript in the current tab. LiveParse does not post the token to a decoder service, append it to a query string or URL fragment, save it in local or session storage, or include it in the downloaded report. Remote key references such as jku and x5u are displayed only and never fetched.
JWTs can contain names, email addresses, account identifiers, tenant IDs, roles, permissions, internal infrastructure details, or bearer credentials. Use a redacted development token when possible. If a real access token is exposed to a shared screen, clipboard history, extension, chat, issue tracker, or untrusted device, treat it according to your incident and revocation policy.
Local processing narrows one risk but cannot control everything on the device. Browser extensions, accessibility software, clipboard managers, screenshots, downloaded files, operating-system telemetry, and malware have their own permissions. Clear the input when finished and avoid production credentials on a device you do not control.
The sample token on this page is synthetic and its signature text is deliberately fake. It is safe for learning how the interface works, but it is not an example of successful cryptographic verification. See the privacy page for the site-wide distinction between conversion input and ordinary page requests.
Useful failure modes
Not three partsConfirm the complete value was copied. Five parts match compact JWE shape but still require validation and decryption; two, four, or more than five usually mean truncation or a different format.+, /, =, whitespaceDo not paste a standard Base64 conversion or percent-encoded URL. Preserve the original compact JWT and its two dots.Bad decoded bytesThe segment may be corrupted, compressed by a custom profile, or not a JWT. Do not delete bytes until it becomes readable.Two decoded namesReject the token for policy evaluation. Different parsers may select different values, creating security ambiguity.Questions answered
Yes. The header and payload of an ordinary signed JWT are Base64URL-encoded, not encrypted, so no secret is needed to read them. The secret or public key is needed for signature verification. Never treat readability as authentication.
No. It intentionally performs decoding and structural inspection only. A secure verifier must use an allowed algorithm and trusted key, verify the original compact signing input, and then enforce issuer, audience, time, replay, and application authorization rules. Read decode vs verify.
That message is always present because the page neither asks for a key nor contacts a JWKS endpoint. Even an apparently well-formed signature segment can be random bytes. The label prevents the common mistake of equating syntax with cryptographic trust.
Yes. Paste either the compact value itself or a value beginning with Bearer followed by whitespace. The tool removes that scheme prefix locally and reports the normalization. Do not include the full HTTP request or unrelated headers.
A common signed JWT/JWS has three compact segments and a readable claims payload. Compact JWE has five segments and encrypts its content. This decoder recognizes the five-part JWE shape but does not validate or decrypt it; real decryption needs the correct key, algorithm context, and authenticated format checks.
It proves only that the decoded payload asserts a time boundary that has passed. Until the signature and trusted issuer are verified, the claim may be forged. Even after verification, the application must still check audience, token type, replay, revocation, and authorization policy.
exp passes only while the check time is strictly earlier than expiration plus explicit leeway. nbf passes when the check time reaches the not-before value minus leeway. The result still describes unverified payload assertions. Use the expiration checker for a focused view.
The decoder runs in this browser tab and does not send input to a conversion API, store it in local or session storage, or put it in the URL. Device software and any clipboard or downloaded copy remain outside the tool’s control; see privacy.
JSON processors can disagree about whether the first or last duplicate wins. RFC 7519 requires unique claim names. LiveParse preserves duplicates, reports ambiguity, and refuses to produce a definite time result from a duplicated time claim.