JWT Decoder
Decode compact JSON Web Tokens (JWT) in real time to inspect JOSE headers, payload claims, and signature length in this page's tool workspace. Ordinary site requests, extensions, and managed-device services are separate paths.
About this jwt decoder
Tool operation
Decodes compact JSON Web Tokens (JWT) in the current tool workspace by splitting period-separated Base64URL header, payload, and signature segments, parsing claims JSON structures, and evaluating exp/nbf/iat timestamp validity. Ordinary page requests and browser extensions are separate paths.
Worked example
Scenario: Decode the page sample claims without treating them as verified.
Input:
Processing: Base64URL-decode compact-token display segments; do not verify signature, issuer, audience, expiry or trust.
Output:
Limits
It only Base64URL-decodes display segments of a compact three-segment JWT. It does not verify a signature, fetch JWKS, enforce an algorithm allowlist, validate issuer/audience/time claims, or decrypt JWE. Decoded claims remain untrusted input.
A compact signed JSON Web Token (JWT) comprises three period-separated Base64URL-encoded components: the JOSE header (algorithm and token type), the claims payload (identity, subject, permissions, and timestamps), and the cryptographic signature. This tool decodes the header and payload segments as UTF-8 JSON structures and reports the decoded signature byte length entirely in client-side memory. It makes no trust decision.
JOSE header algorithm identifiers and RFC 7518
The JOSE (JSON Object Signing and Encryption) header's alg claim identifies the cryptographic algorithm used to secure the token. RFC 7518 registers the standard algorithm identifiers: HS256 uses HMAC-SHA-256 with a symmetric shared secret, RS256 uses RSASSA-PKCS1-v1_5 with a 2048-bit RSA key, ES256 uses ECDSA with the P-256 curve and SHA-256, and PS256 uses RSASSA-PSS with MGF1. The algorithm none (unsecured JWT) must never be accepted by production verification code without explicit allowlisting, as it signals the absence of a signature. Libraries that accept algorithm none or allow algorithm confusion attacks (substituting RS256 with HS256 and using the public key as the HMAC secret) represent critical security vulnerabilities.
Standard claims and OpenID Connect
RFC 7519 defines registered claim names shared across JWT implementations: sub (subject identifier), iss (issuer URL), aud (audience), exp (expiration Unix timestamp), nbf (not-before Unix timestamp), iat (issued-at Unix timestamp), and jti (unique JWT identifier for replay prevention). OpenID Connect (OIDC) extends JWT with additional claims including name, email, picture, and preferred_username for identity assertions. Access tokens from OAuth 2.0 authorization servers frequently use JWT format with custom scope and permissions claims. Always validate iss, aud, and exp against your application's configured trusted values before trusting any payload claim. This tool decodes the header and payload segments as UTF-8 JSON structures and reports the decoded signature byte length entirely in client-side memory. It makes no trust decision.
Decoding is not verification
A visible payload can claim any subject, role, issuer, audience, or expiry. Until an application verifies the signature with an allowed algorithm and trusted key, those claims are untrusted input.
Never treat a successful decode as proof that a token is authentic or currently acceptable.
How time claims are displayed
RFC 7519 defines exp, nbf, and iat as NumericDate values measured in seconds from 1970-01-01T00:00:00Z, ignoring leap seconds. The page converts numeric values to ISO UTC for inspection but does not apply clock skew or acceptance policy.
Security limits
- Encrypted JWE tokens cannot be inspected as a plain JSON payload.
- The page does not fetch JWKS, accept keys, or validate issuer and audience.
- A token can contain personal or confidential data even though Base64URL is reversible.
- Use a trusted library and an explicit algorithm allowlist for production verification.
RFC 7519 JSON Web Token · Content owner: CZOA Tools · Review methodology
How to use it
- Paste a compact three-segment JWT into the field.
- Read the decoded header, payload, and signature display as untrusted data.
- Use exp, nbf, and iat only as displayed claim values.
- Verify the original token separately with a trusted key, allowed algorithm, issuer, audience, and application policy.
Frequently asked questions
What does the JWT decoder require before it displays a token?+
It decodes the three compact JWT segments for display. Header and payload must be Base64URL-encoded valid UTF-8 JSON objects; the signature segment must decode as Base64URL bytes, but no signature or trust check occurs.
What local example can I run?+
Load the sample token. Its claims include `sub: "1234567890"`, `name: "John Doe"`, `role: "admin"`, and `iat: 1516239022`; the decoded signature segment has 32 bytes.
What does the interface display?+
It shows the JOSE header and claims payload in separate readonly areas, the decoded signature-segment byte count, and ISO dates for numeric `exp`, `nbf`, and `iat` claims.
Can decoded claims authorize access?+
No. This is decoding only: it does not verify the signature, issuer, audience, expiry policy, or trustworthiness. Tokens longer than 200,000 characters are rejected.