JWT Decoder

What Is a JWT Decoder?

A JWT decoder is a tool that reads and displays the contents of a JSON Web Token (JWT) without requiring the secret key used to sign it. JWTs are compact, URL-safe tokens defined by RFC 7519 that encode claims as a JSON object. They are the most widely used token format for authentication and authorization in modern web applications, mobile apps, and APIs.

Every JWT consists of three Base64URL-encoded parts separated by dots: a header, a payload, and a signature. The header specifies the signing algorithm (such as HS256 or RS256) and the token type. The payload contains claims, which are key-value pairs carrying information about the user, session, or permissions. The signature is a cryptographic hash that allows the server to verify the token has not been tampered with.

Decoding a JWT simply means Base64URL-decoding the header and payload sections to read their JSON contents. This does not require any secret key because the payload is encoded, not encrypted. Anyone with access to a JWT can read its contents. This is by design: JWTs are meant to be self-contained tokens that carry verifiable claims, not secret data.

How JWT Decoding Works

A JWT like eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.dozjgNryP4J3jVmNHl0w5N_XgL0n3I9PlFUP0THsR8U is split on the two dot characters to yield three segments. The first segment (header) and second segment (payload) are each Base64URL-decoded: the characters - and _ are replaced with + and /, padding is added, and the result is passed through atob() to produce a UTF-8 string that is then parsed as JSON.

The third segment is the signature, which is a binary value produced by hashing the header and payload with a secret key (for HMAC algorithms) or signing them with a private key (for RSA or ECDSA algorithms). A decoder displays the signature as a hexadecimal string for inspection, but cannot verify it without the corresponding key. Verification is a separate step that happens server-side.

Common Use Cases

• Debugging authentication flows: When a user reports they cannot access a resource, decoding their JWT reveals their roles, permissions, and whether the token has expired. This is often the first step in troubleshooting auth issues.
• Inspecting API tokens: OAuth 2.0 access tokens and OpenID Connect ID tokens are often JWTs. Decoding them shows which scopes were granted, who issued the token, and the intended audience.
• Checking token expiration: The exp (expiration) claim tells you exactly when a token becomes invalid. This decoder automatically compares the exp timestamp against the current time and shows whether the token is still valid.
• Verifying token structure during development: When building authentication systems, you need to confirm that your server is generating tokens with the correct claims, algorithm, and structure before deploying to production.
• Security auditing:Reviewing JWTs helps identify overly permissive tokens, tokens without expiration dates, or tokens using weak algorithms like "none" (the infamous "alg: none" vulnerability).
• Understanding third-party integrations: When integrating with services like Auth0, Firebase, AWS Cognito, or Okta, decoding the tokens they issue helps you understand what data is available in the payload.
• Comparing tokens across environments: Decoding tokens from staging and production environments side by side helps catch configuration differences in your identity provider.

Standard JWT Claims Explained

The JWT specification defines several registered claims that have standardized meanings:

• iss (Issuer):Identifies who created and signed the token. Typically a URL like "https://auth.example.com".
• sub (Subject): The principal the token represents, usually a user ID or email address.
• aud (Audience):The intended recipient of the token. A token meant for "https://api.example.com" should be rejected by other services.
• exp (Expiration Time): A Unix timestamp after which the token must not be accepted. Tokens without exp never expire, which is a security risk.
• iat (Issued At): The Unix timestamp when the token was created. Useful for determining token age.
• nbf (Not Before): A Unix timestamp before which the token must not be accepted. Used for tokens that should activate in the future.
• jti (JWT ID): A unique identifier for the token, used to prevent replay attacks.

Tips and Best Practices

• Never put sensitive data in a JWT payload: Since anyone can decode a JWT, never include passwords, credit card numbers, or other secrets in the payload. Use encryption (JWE) if you need confidential claims.
• Always set an expiration (exp) claim: Tokens without expiration are valid forever if compromised. Short-lived tokens (15-60 minutes for access tokens) limit the damage window.
• Check the algorithm in the header: Make sure the token uses a strong algorithm like RS256 or ES256 for production systems. HS256 is simpler but requires sharing a secret key between issuer and verifier.
• Validate tokens server-side: Decoding is not verification. Always verify the signature, expiration, issuer, and audience on your server before trusting the claims in a JWT.
• Use this tool for debugging, not production: Browser-based decoders are for inspection during development. Production token validation should happen in your backend with a proper JWT library.

JWT Decoder vs JWT Verifier

A JWT decoder reads the contents of a token by Base64-decoding the header and payload. It works without any keys and shows you what the token contains. A JWT verifier goes further: it checks the cryptographic signature to confirm the token was issued by a trusted party and has not been modified. Verification requires the secret key (for HMAC) or the public key (for RSA/ECDSA).

This tool is a decoder, not a verifier. It is intentionally designed this way because sharing your signing keys with a web tool would be a security risk. For signature verification, use server-side libraries like jsonwebtoken (Node.js), PyJWT (Python), or java-jwt (Java) with your keys stored securely.