</>
ProtocolCodes

JWT Decoder

Decode and inspect JSON Web Tokens. View header, payload, and signature details — entirely in your browser, nothing sent to any server.

Your token never leaves your browser

How to Use

  1. 1
    Paste your JWT token

    Copy a JSON Web Token from an Authorization header, cookie, or API response and paste it into the decoder. The tool splits the token at the dots and decodes each part without sending data to a server.

  2. 2
    Inspect header and payload claims

    Review the JOSE header (algorithm, key ID, token type) and all payload claims including iss, sub, aud, exp, iat, nbf, and any custom claims. Expiry times are shown in human-readable local time.

  3. 3
    Verify structure and expiry

    Check whether the token is expired (exp claim), not yet valid (nbf claim), and whether the algorithm in the header matches your expected signing method. Note that signature verification requires your secret or public key.

About

JSON Web Tokens are the dominant format for stateless authentication and authorization in modern web APIs, standardized in RFC 7519 and part of the broader JOSE (JSON Object Signing and Encryption) framework defined across RFC 7515–7518. A JWT encodes identity claims in a compact, URL-safe format that can be verified by any party holding the correct key — eliminating the need for server-side session storage and enabling scalable distributed architectures.

The JWT Decoder performs client-side decoding entirely in the browser, never transmitting your token to a remote server. It parses the Base64URL-encoded header and payload, formats the JSON for readability, and converts Unix timestamps for exp (expiration), iat (issued at), and nbf (not before) into human-readable local time. Custom claims added by your identity provider — roles, permissions, tenant IDs — are surfaced alongside the standard RFC 7519 registered claims.

Critical security note: decoding a JWT is not the same as validating it. Decoding only reads the payload; validation requires checking the cryptographic signature against a trusted key, confirming the algorithm matches your expected scheme, and verifying time-based claims (exp, nbf) and audience (aud). The decoder is a diagnostic tool for inspecting token contents during development and debugging — production token validation must always be performed server-side using a well-maintained JWT library that enforces algorithm restrictions per RFC 8725 (JWT Best Current Practices).

FAQ

What is the structure of a JSON Web Token?
A JWT (RFC 7519) consists of three Base64URL-encoded parts separated by dots: header.payload.signature. The header is a JSON object specifying the algorithm (alg) and token type (typ: JWT). The payload contains claims — registered (iss, sub, aud, exp, iat, nbf, jti), public, or private. The signature is computed over the header and payload using the algorithm specified, binding the data to a key. The decoder shows the raw Base64URL strings and their decoded JSON for each part.
Why should I never use the 'none' algorithm in JWTs?
RFC 7518 §3.6 defines alg: none as an unsecured JWT with no signature. A notorious 2015 vulnerability showed that many JWT libraries accepted tokens where the algorithm was changed from RS256 to none, bypassing signature verification entirely. CVE-2015-9235 and similar CVEs affected Node.js, Java, and Python libraries. Always validate the algorithm in your library configuration — explicitly whitelist allowed algorithms (e.g., only RS256 or HS256) rather than accepting whatever the token header claims.
What is the difference between JWS, JWE, and JWT?
JWT (RFC 7519) is the claim set format. JWS (JSON Web Signature, RFC 7515) defines how JWT payloads are signed — the standard three-part dot-separated format is a compact JWS. JWE (JSON Web Encryption, RFC 7516) defines how JWT payloads are encrypted, producing a five-part token. A signed JWT proves authenticity and integrity; an encrypted JWT (JWE) additionally hides the payload content. Most OAuth 2.0 access tokens are JWS-signed JWTs. OpenID Connect ID tokens are always JWS-signed.
How should I validate the aud (audience) claim?
RFC 7519 §4.1.3 defines aud (audience) as the recipient the JWT is intended for. Your application must reject tokens where its own identifier is not present in aud. Failing to validate audience allows token confusion attacks — a token issued for service A can be replayed against service B if neither validates aud. In OAuth 2.0 (RFC 6749), the audience is typically the resource server's URL. The OIDC specification (OpenID Connect Core 1.0) requires clients to verify that aud contains their client_id.
What is JWT key confusion and how do I prevent it?
Key confusion (also called algorithm confusion) attacks exploit libraries that accept an asymmetric public key (RS256) as an HMAC secret (HS256). An attacker signs a forged token with HS256 using the server's known public key, and a vulnerable server verifies the HMAC signature using that same public key — and accepts the forged token. Prevention: always specify allowed algorithms explicitly in your library (alg_whitelist), never derive the verification key from the token header alone, and use algorithm-specific key types that cannot be confused.