JWT Decoder

How JWT Decoder Works

What is a JWT?

A JSON Web Token (JWT, pronounced “jot”) is a compact, URL-safe format for transmitting claims between two parties — most commonly used to represent an authenticated user in web APIs. A JWT is a single string made of three Base64URL-encoded segments separated by dots: header.payload.signature. Once issued, the header and payload are easy to read by anyone — they are encoded for transport, not encrypted for secrecy.

Security Warning: Decoding Is Not Verification

This tool ONLY decodes JWTs. It DOES NOT verify signatures. It DOES NOT validate authenticity. Decoding a JWT tells you what a token claims — it tells you nothing about whether those claims are genuine. Anyone can construct a JWT with any header and payload they like; it will decode perfectly here and look completely legitimate. The only way to know a JWT can be trusted is to verify its signature against the issuer’s secret or public key, performed server-side with a proper JWT library. Never use the output of this tool, or any JWT decoder, to make a trust or authorization decision.

JWT Structure

Header

A minimal header looks like {"alg": "HS256", "typ": "JWT"}. The alg field names the signing algorithm — commonly HS256 (a shared secret) or RS256/ES256 (public/private key pairs). A well-known attack sets alg to none, effectively removing the signature — this is why every JWT library must be configured with an explicit allow-list of accepted algorithms, never trusting the algorithm the token itself claims to use.

Payload

The payload holds claims — key/value statements about the token. Use the JSON Formatter if you want to reformat a raw payload you’ve copied out, or the JSON Validator to check hand-edited JSON claims before re-encoding them.

Signature

The signature is computed over the header and payload using the algorithm named in the header and a key only the issuer holds. It exists so a verifier can detect any change to the header or payload — but computing or checking that signature is a cryptographic operation this decoder deliberately does not perform, because doing so safely requires the issuer’s key, which this browser-only tool never has and should never be given.

Registered Claims (RFC 7519)

Everything else in the payload is a custom (private) claim — application-specific data like role, tenant_id, or permissions. This tool decodes and displays both registered and custom claims, and converts iat/nbf/exp into readable UTC dates with plain-language remaining time or elapsed-since-expiry.

Common JWT Mistakes

• Storing sensitive data in the payload. The payload is readable by anyone with the token — never put passwords, secrets, or sensitive PII in a JWT claim.
• Trusting a decoded token without verifying the signature. The single most dangerous JWT mistake — see the Security Warning above.
• Accepting the alg the token claims. Always configure your verifier with an explicit allowed-algorithms list; never let the token dictate how it should be checked.
• No expiration claim. A JWT without exp is valid forever once issued — set a reasonably short expiry and use refresh tokens for longer sessions.
• Confusing encoding with encryption. Base64URL is trivially reversible, not a security mechanism — anyone can decode a JWT's header and payload instantly, exactly as this tool does.

Signature Verification vs. Decoding

Use this decoder to debug why a token looks wrong, inspect what an API is sending, or learn JWT structure. Use a proper server-side JWT library (with signature verification enabled and an explicit algorithm allow-list) for every decision that depends on whether a token can be trusted.