JWT decoder

JWT Decoder splits an entered token into three dot-separated sections, decodes the first two from Base64url, parses each as JSON, and prints an indented header and payload. It labels the third section as present but not verified. No key is loaded, no signature algorithm runs, and no trust decision is made.

Anyone can create a token-shaped string with arbitrary claims. A readable payload saying `admin: true` does not grant a role, and an `alg` header does not prove that algorithm protected the token. Verification must use an authentication library configured with trusted keys and an allowed algorithm list. The application must then validate issuer, audience, time claims, and any business-specific requirements.

Use this page for debugging structure and claim values in development. Never use its output as authorization evidence, proof of identity, or confirmation that a production request should be accepted.

A compact signed JWT commonly has `header.payload.signature`. The header is usually a small JSON object that names a signing algorithm and may include a key identifier or token type. The payload contains claims. The signature section contains encoded signature bytes, not JSON. This workbench requires exactly three sections and does not support five-part encrypted JWE compact objects.

The first two sections use Base64url, which replaces standard Base64 `+` and `/` characters with `-` and `_` and often drops padding. The decoder restores the standard alphabet, pads the value, decodes its bytes as UTF-8, and calls JSON.parse. A section can be valid Base64url yet fail because its decoded bytes are not valid JSON text.

The tool does not inspect the signature section's length or content. Even an empty third section still gives the split operation three parts and receives the fixed `Present (not verified)` label. Do not infer that a cryptographic signature exists from that wording.

Common payload fields include `iss` for issuer, `sub` for subject, `aud` for audience, `exp` for expiration, `nbf` for not-before, `iat` for issued-at, and `jti` for a token identifier. Their presence is optional unless the consuming system's policy requires them. Custom claims such as roles, tenant IDs, or scopes belong to the issuer's contract.

Numeric date claims are normally Unix seconds, not JavaScript milliseconds. An `exp` value such as `1893456000` should be interpreted as seconds from the Unix epoch. This decoder displays the number exactly as JSON and does not convert it to a date or compare it with the current clock. Copy the number into Timestamp Converter and confirm the unit before reasoning about expiration.

Audience can be a string or an array, and scopes can be a space-delimited string or another issuer-defined form. Do not force a claim into the shape used by a different provider. Read the issuer's documentation and validate types in code.

Copy the token value without the `Bearer ` authorization scheme, surrounding quotes, or trailing punctuation. Paste the compact string and run JWT Decoder. Confirm that the header and payload parse. Compare `iss`, `aud`, `sub`, and relevant custom claims with the environment and account you expected.

For a time-related failure, take `iat`, `nbf`, and `exp` values to the timestamp tool and compare them in UTC. Check both the application clock and the issuer clock. A token can decode cleanly yet be rejected because it is expired, not active yet, issued for another audience, or signed by an untrusted key.

Finish debugging in the application's verification path. Capture the library's specific error without logging the full token. Confirm which key and allowed algorithm were selected. The browser display helps you form a hypothesis; only verified server or client code can confirm it.

The `alg` field is a request from the token, not a policy. A verifier must enforce its own allowed algorithms and reject unexpected values. It must not accept `none` for a flow that requires a signature, and it must not let a token switch between symmetric and asymmetric verification in an unsafe way.

A `kid` value can help select a key, but it is also untrusted. Applications should resolve it only within a controlled key set and avoid turning it directly into a file path, database fragment, or remote URL. This workbench prints the field without evaluating it.

Headers may contain `jku`, `x5u`, or embedded key material. Fetching a URL or trusting a key named by the token can create server-side request and trust problems. Use issuer metadata and key-discovery rules approved for the authentication system. Decoding a field never authorizes following it.

The first check is section count. Missing dots, an added `Bearer ` prefix, line wrapping, or copied punctuation can produce fewer or more than three sections. Remove only confirmed wrappers. Do not edit characters inside the compact token in an attempt to make it parse because any change also changes the signed content.

Next, one of the first two sections may contain invalid Base64url, bytes that are not UTF-8 text, or text that is not JSON. A token can also be encrypted rather than signed, in which case compact JWE uses five sections and needs decryption with the correct key. This tool does not decrypt tokens.

A clean decode followed by an application rejection usually points to verification or policy, not parsing. Check signature keys, algorithm restrictions, issuer, audience, time tolerance, revocation, session state, and required claims. Do not weaken those checks merely because the visible payload looks correct.

The token is processed in the browser and is not sent to a PWRKIT processing server. A live bearer token can still grant access to whoever obtains it. Clipboard history, browser extensions, screen sharing, session restoration, screenshots, and local monitoring can capture the value or decoded claims.

Prefer a token issued for a disposable development account with narrow scope and short lifetime. Redact the signature and sensitive claims before sharing a screenshot, but remember that changing the string makes it unsuitable for reproducing a signature error. For collaborative debugging, share claim names and masked values plus the verifier error rather than the credential itself.

If a production token was exposed, follow the incident process. Revoke the session or credential when supported, rotate related secrets if needed, and remove copies from tickets and chat. Waiting for `exp` is not always sufficient because the remaining lifetime and access scope may still be material.

Base64 Decode can inspect one header or payload section as text, but it does not require token structure or parse JSON. JSON Formatter can validate a decoded object. Timestamp Converter turns numeric date claims into local, UTC, ISO, seconds, and milliseconds views. These steps explain data; none verifies a signature.

Hash Generator creates unkeyed SHA digests and cannot verify a JWT signature by hashing visible text. JWT algorithms use defined signing or message-authentication constructions with exact encoded input and keys. Do not paste a public key and token into improvised hash steps.

Production verification belongs in a maintained JOSE or authentication library. Test valid tokens, expired tokens, future `nbf`, wrong audience, wrong issuer, unknown keys, altered payloads, unexpected algorithms, and malformed compact strings. The decoder remains a diagnostic view, deliberately separated from the security decision.

Signature verification answers whether the compact header and payload were protected by a key under an allowed algorithm. Claim validation answers whether that verified token is acceptable for this request. Both are required. A correctly signed token for another service must fail an audience check.

Issuer comparison should use the exact trusted identifier configured for the environment. Development, staging, and production issuers may use similar hostnames but different keys and tenants. Do not add all of them to one permissive list to silence a deployment error.

Time checks need a defined clock tolerance. A small allowance can cover ordinary clock skew, but a large allowance extends token validity and hides bad system clocks. Record time in UTC, synchronize hosts, and test boundary behavior immediately before and after `nbf` and `exp`.

Required custom claims should be checked for type and permitted values after verification. A role string, array of scopes, or tenant identifier should not be trusted merely because the JSON parser accepted it. Tie authorization to server-side policy and current account state.

Token revocation and session termination are outside the compact token itself unless the architecture checks additional state. A token that has not expired may still need rejection after logout, credential compromise, account suspension, or permission change. Follow the identity system's session model.

Logging should record a safe correlation value, verification outcome, issuer, and error category where policy permits. Avoid full tokens and unnecessary claims. A `jti` can itself be sensitive or linkable, so mask or hash it under the logging design rather than copying it everywhere.

Frontend decoding is useful for display hints but cannot enforce backend access. A caller can modify browser code and requests. The resource server must verify the token and authorize the operation independently on every protected boundary.

Key rotation creates another diagnostic case. A token may name an older `kid` that is still valid during a transition, or it may arrive after the verifier's key cache became stale. Inspect the header, then check the issuer's trusted key set through the authentication library and its cache rules. Do not paste private signing keys into the browser. Refreshing keys must preserve issuer restrictions, HTTPS validation, cache limits, and failure handling. If verification works only after disabling key checks, the system remains broken. Record which public key ID was selected and why the policy accepted it.