JWT Decoder

How to Use the JWT Decoder

Using this JWT decoder is simple and quick. Paste your JSON Web Token into the input area above, and the tool will automatically parse and decode it. You can also click the "Decode" button to trigger decoding manually. Here's what the tool provides:

• Header Tab — Shows the decoded JOSE header with syntax highlighting. This section reveals the signing algorithm (e.g., HS256, RS256, ES256) and token type.
• Payload Tab — Displays the decoded claims with syntax highlighting. Timestamp fields like iat (issued at), exp (expiration), and nbf (not before) are automatically annotated with human-readable dates.
• Signature Tab — Shows the raw signature bytes as a hexadecimal string. This is the cryptographic signature that verifies the token's integrity.
• Stat Badges — At-a-glance information including the algorithm, expiration status (valid or expired), and when the token was issued.
• Copy Decoded — Copies the full decoded JSON (header + payload) to your clipboard with one click.
• Sample JWT — Loads an example token so you can explore the interface without having a real token handy.

What Is a JSON Web Token (JWT)?

A JSON Web Token (JWT, pronounced "jot") is a compact, URL-safe token format defined by RFC 7519 for securely transmitting claims between two parties. A JWT consists of three Base64url-encoded parts separated by dots: a header, a payload, and a signature. The header specifies the signing algorithm and token type. The payload contains the claims — statements about the subject (typically a user) and additional metadata. The signature is computed over the header and payload using the specified algorithm, ensuring that the token hasn't been tampered with. JWTs are widely used for authentication, authorization, and information exchange in modern web applications and APIs.

Anatomy of a JWT

Every JWT follows the structure xxxxx.yyyyy.zzzzz where each section is Base64url-encoded. The first part (header) is a JSON object typically containing "alg" (the signing algorithm such as HS256 or RS256) and "typ" (usually "JWT"). The second part (payload) is a JSON object containing claims — registered claims like iss (issuer), sub (subject), exp (expiration time), and iat (issued at), as well as custom claims defined by your application. The third part (signature) is created by taking the encoded header, the encoded payload, a secret or private key, and the algorithm specified in the header. For HMAC algorithms, the signature is HMAC-SHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret).

Common JWT Use Cases

JWTs are most commonly used in OAuth 2.0 and OpenID Connect flows for authentication and authorization. When a user logs in, the server issues a JWT that the client stores (typically in memory or an HTTP-only cookie) and sends with subsequent API requests via the Authorization header as a Bearer token. The server validates the signature and checks the claims (especially expiration) before granting access. JWTs are also used for single sign-on (SSO) across multiple services, as API keys in service-to-service communication, and for securely passing identity information between microservices. Because JWTs are self-contained, the server doesn't need to query a database to validate the token, which makes them highly scalable.

Security Considerations

While JWTs are powerful, developers must handle them with care. Never store sensitive data in the payload because Base64url encoding is not encryption — anyone can decode the payload (which is exactly what this tool demonstrates). Always validate the signature on the server side before trusting any claims. Check the exp claim to reject expired tokens. Use HTTPS to prevent token interception. Be cautious with the "none" algorithm, which disables signature verification entirely and has been the source of numerous vulnerabilities. For storing JWTs in browsers, HTTP-only secure cookies are generally safer than localStorage, which is vulnerable to XSS attacks. This decoder runs entirely in your browser — your tokens are never sent to any server, making it safe to inspect even production tokens during debugging.