JWT Decoder — Decode JSON Web Tokens Online

What is a JSON Web Token

A JSON Web Token (JWT) is a compact, URL-safe string used to represent claims between two parties. It is defined in RFC 7519 and has become the dominant token format for web authentication, API authorization, and federated identity systems like OAuth 2.0 and OpenID Connect.

Every JWT consists of three parts separated by dots: header.payload.signature.

• Header — a JSON object that declares the token type ("typ": "JWT") and the signing algorithm ("alg": "HS256"). It is Base64URL-encoded, not encrypted.
• Payload — a JSON object containing claims about the user or session. Standard claims like sub, exp, and iss live here, alongside any custom data the issuer chooses to include. Also Base64URL-encoded.
• Signature — produced by signing the encoded header and payload with a secret key (HMAC) or a private key (RSA, ECDSA). This is the only part that provides integrity and authenticity.

A critical point: Base64URL encoding is not encryption. Anyone who has the token can decode the header and payload and read every claim in plain text. JWTs are designed for integrity (detecting tampering), not confidentiality (hiding data). Never put secrets, passwords, or sensitive personal data directly in a JWT payload.

Common JWT claims explained

The JWT specification defines a set of registered claims. None are mandatory, but most production tokens use several of them:

• iss (issuer) — identifies the service that created and signed the token. Typically a URL like https://auth.example.com.
• sub (subject) — the principal the token describes, usually a user ID or account identifier.
• aud (audience) — the intended recipient of the token. A resource server should reject tokens whose aud does not match its own identifier.
• exp (expiration time) — a Unix timestamp after which the token must be rejected. Short-lived tokens (5-15 minutes) limit the window of compromise.
• iat (issued at) — the Unix timestamp when the token was created. Useful for calculating token age and detecting stale tokens.
• nbf (not before) — the Unix timestamp before which the token must not be accepted. Used for tokens issued ahead of time.
• jti (JWT ID) — a unique identifier for the token, typically a UUID. Servers can track jti values to prevent replay attacks.

Beyond these registered claims, tokens often carry custom claims like role, scope, or email. Use the decoder above to inspect the exp and iat timestamps — they are displayed as human-readable dates automatically.

JWT signing algorithms

The alg field in the header determines how the signature is produced. The three most common algorithms fall into two categories:

• HS256 (HMAC + SHA-256) — symmetric. The same secret key is used to sign and to verify. Simple to set up, but every service that needs to verify the token must have the shared secret. Best suited for single-service architectures where the issuer and the verifier are the same application.
• RS256 (RSA + SHA-256) — asymmetric. The issuer signs with a private key; verifiers only need the public key. Widely used in multi-service architectures and identity providers because the public key can be distributed freely (often via a JWKS endpoint) without compromising signing authority.
• ES256 (ECDSA + SHA-256) — asymmetric, using elliptic curve cryptography. Produces much smaller signatures than RS256 (64 bytes vs 256 bytes) with comparable security. Increasingly preferred for mobile and IoT contexts where token size matters.

A token with "alg": "none" has no signature at all. Legitimate use of this is extremely rare. Any server that accepts alg: none tokens without an explicit allowlist is vulnerable to trivial forgery — this is one of the most well-known JWT attack vectors.

Why you should not trust a decoded JWT

This tool decodes JWTs — it does not verify them. That distinction matters. Decoding means splitting the token at the dots and Base64URL-decoding each segment to read the JSON. Anyone can do that; no key is required. Verification means cryptographically confirming that the signature matches the header and payload using the correct key.

A decoded token tells you what the token claims. Only a verified token tells you whether those claims are trustworthy. In practice:

• Client-side decoding is fine for display purposes — showing the user's name, checking if a token is expired before making a network request, or debugging auth flows during development.
• Server-side verification is mandatory for authorization — every API endpoint that reads claims from a JWT to make access-control decisions must verify the signature first. Libraries like jsonwebtoken (Node.js), PyJWT (Python), and golang-jwt (Go) handle this.
• Always validate exp, iss, and aud — signature verification alone is not enough. A validly signed token from a different issuer or intended for a different audience should still be rejected.

Use this decoder to inspect tokens during development, to debug authentication issues, or to quickly check expiration times. Never use a decoded-but-unverified token as proof of identity or authorization in production code.

Related tools on CodeBoxTools

• Base64 Decode/Encode — JWTs use Base64URL encoding. Decode raw Base64 strings or encode data for transport.
• Hash Generator — generate SHA-256, SHA-384, and SHA-512 hashes, the same hash families used in JWT signing algorithms.
• Epoch Converter — JWT timestamps (exp, iat, nbf) are Unix epoch seconds. Convert them to human-readable dates.
• JSON Formatter — format and validate the JSON payloads extracted from your decoded tokens.