JWT Decoder — Decode Any JSON Web Token Online

What Is a JWT Token?

JWT Token Structure Explained

How to Decode a JWT Token

JWT Security Best Practices

What It Is

A JSON Web Token (JWT) is a compact, URL-safe credential format defined by RFC 7519. It packs three pieces of information — a header describing the signing algorithm, a payload of JSON claims, and a cryptographic signature — into a single string of three Base64URL segments separated by dots. JWTs are how modern OAuth flows, single sign-on systems, microservice meshes, and serverless authorizers move identity around. The DigiMetrics JWT Decoder runs entirely in your browser, so the token you paste never touches our infrastructure — important because a real JWT is, by definition, an unexpired credential.

How It Works

The signing server builds the header and payload as JSON, Base64URL-encodes each, joins them with a dot, then signs that string with the configured algorithm (HMAC-SHA256, RSA-SHA256, ECDSA, EdDSA) using its secret or private key. The signature itself is Base64URL-encoded and appended after another dot. Verification reverses the flow: split on dots, recompute the signature over header+payload using the shared secret or public key, and compare. The decoder skips the cryptographic step because it doesn't have your key — but reading the unverified contents is exactly what you need when debugging integration issues.

Real-World Examples

A backend engineer debugging a 401 decodes the access token to confirm the exp claim is still in the future and the aud matches their API's identifier. A frontend developer integrating a third-party SSO pastes the ID token returned by Google to see exactly which scopes were granted. A mobile developer chasing a sign-out bug decodes a refresh token to check whether the auth provider rotated the sub on the last login. A security reviewer audits a token issued to a partner to confirm no overly broad role or scope claims slipped through. An on-call engineer decodes the token attached to a failing webhook to verify the issuer matches the expected service.

Common Mistakes to Avoid

Treating JWTs as encrypted — they aren't. The payload is Base64URL, fully readable by anyone who intercepts the token. Storing sensitive data (passwords, SSNs, raw credit card numbers) inside the payload is a leak waiting to happen. Trusting an alg: none token, the classic JWT vulnerability where a server accepts an unsigned token if it doesn't enforce the expected algorithm. Forgetting to verify exp, iss, and aud separately — a valid signature alone is not enough. Logging full JWTs in plaintext server logs, which leaks reusable credentials to anyone with log access. And refreshing on every request, defeating the point of stateless tokens.

Security Implications

A JWT is a bearer credential — possession equals authorization until it expires. Always send tokens over HTTPS only. Set short access-token lifetimes (5–15 minutes) and rotate via refresh tokens. Pin the expected algorithm server-side (e.g. RS256) and reject any token whose alg header doesn't match. Validate iss and aud on every request. Use a centralized JWKS endpoint for key rotation. Store tokens in HttpOnly secure cookies for browser flows when feasible; localStorage exposes them to any XSS payload. Treat every decoded JWT you share publicly as a fresh credential that needs revoking.

Best Practices

Keep payloads small — every API call carries the full token in a header, so bloated claims taxes every request. Use standard claim names (iss, sub, aud, exp, iat, nbf, jti) so off-the-shelf libraries validate them automatically. Always set exp; never issue infinite-lifetime tokens. Prefer asymmetric algorithms (RS256, ES256) for any system where the signer and verifier are different services. Maintain a key rotation schedule and publish public keys via JWKS. Use jti and a server-side revocation list when you need true logout. And document which claims your APIs expect, in the same place as your API reference.

Troubleshooting Guide

Token rejected with 'invalid signature'? Either the wrong key was used or the token was modified in transit. 'Token expired' is straightforward — the client clock is skewed or the token sat in a queue too long. 'Audience mismatch' means the token was issued for a different API; check the aud claim. 'Invalid algorithm' is a security red flag — your verifier is enforcing one algorithm but the token claims another. 'Malformed token' usually means the JWT was URL-encoded twice or had whitespace inserted by a middleware. If decoding fails entirely, the token isn't actually a JWT — possibly an opaque session ID or a JWE (encrypted JWT).