Security Tools

JWT Decoder

Decode and inspect JWT tokens online. View header, payload, and expiration without any library.

Your data never leaves your browser — nothing is sent to any server.

How to use
  1. 1

    Paste your JWT token

    Copy a JWT from your application, API response, browser cookies, or authorization header, then paste it into the input field. The token is decoded instantly as you type.

  2. 2

    Inspect the header

    The header section shows the signing algorithm (alg) and token type (typ). Common algorithms include HS256 (HMAC-SHA256) for shared secrets and RS256 (RSA-SHA256) for public/private key pairs.

  3. 3

    Review the payload claims

    The payload section displays all claims in the token. Standard claims include sub (subject), iss (issuer), aud (audience), exp (expiration), and iat (issued at). Custom claims from your application also appear here.

  4. 4

    Check token expiration

    Time-based claims (exp, iat, nbf) are automatically converted to human-readable dates. A green 'Valid' badge means the token has not expired; a red 'Expired' badge means the exp time has passed.

  5. 5

    Copy decoded sections

    Use the copy button next to each section header to copy the decoded JSON for the header, payload, or raw signature to your clipboard.

Common errors

Invalid JWT structure: expected 3 parts

A valid JWT has exactly three Base64URL-encoded parts separated by two dots (header.payload.signature). Make sure you copied the entire token — partial tokens, bearer prefixes ('Bearer '), or extra whitespace will cause this error. Remove any 'Bearer ' prefix before pasting.

Invalid JWT header or payload: could not decode as JSON

The header and payload of a JWT must be valid JSON objects encoded in Base64URL format. This error typically means the token is corrupted, truncated, or not actually a JWT. Double-check that you are pasting a real JWT and not another type of token (e.g., opaque session tokens, API keys).

Token appears valid but shows unexpected claims

Some services use nested JWTs (a JWT inside a JWT claim) or encrypted JWTs (JWE). This tool decodes the outer token only. If a claim value looks like another encoded string, try decoding it separately. For JWE tokens, you need the decryption key to access the payload.

FAQ (6)
What is a JSON Web Token (JWT)?

A JWT is a compact, URL-safe token format defined in RFC 7519. It consists of three Base64URL-encoded parts separated by dots: a header (specifying the algorithm and token type), a payload (containing claims like user identity, roles, and expiration), and a signature (used to verify the token has not been tampered with). JWTs are widely used for authentication, authorization, and information exchange between services.

Does this tool verify the JWT signature?

No. This tool decodes and inspects the header and payload — it does not verify the cryptographic signature. Signature verification requires the secret key (for HMAC algorithms like HS256) or the public key (for RSA/ECDSA algorithms like RS256 or ES256). The signature is displayed in its raw Base64URL form for reference.

Is it safe to paste my JWT token here?

Yes. All decoding happens entirely in your browser using JavaScript. The token is never sent to any server, stored in any database, or logged anywhere. You can verify this by checking the network tab in your browser's developer tools — no requests are made when you paste a token.

What do the exp, iat, and nbf claims mean?

These are registered time-based claims defined in the JWT specification. 'exp' (Expiration Time) is the time after which the token must not be accepted. 'iat' (Issued At) is the time the token was created. 'nbf' (Not Before) is the earliest time the token should be accepted. All three are Unix timestamps (seconds since January 1, 1970 UTC). This tool converts them to human-readable dates automatically.

Why does my JWT show as expired?

The red 'Expired' badge appears when the current time exceeds the 'exp' (Expiration Time) claim in the payload. This is compared against your local system clock. If your system clock is significantly off, the expiration check may be inaccurate. Note that a token being expired does not mean it is invalid — it means it should no longer be accepted by servers that enforce expiration.

Can I decode JWTs that use different algorithms?

Yes. The decoder works with any JWT regardless of the signing algorithm — HS256, HS384, HS512, RS256, RS384, RS512, ES256, ES384, ES512, PS256, PS384, PS512, or even 'none'. The algorithm is specified in the header's 'alg' field and is displayed in the decoded header section. Since this tool only decodes (not verifies), the algorithm does not affect the decoding process.

Learn more

JWT Decoder: A Complete Guide to JSON Web Tokens

JSON Web Tokens (JWTs) have become the de facto standard for stateless authentication and authorization in modern web applications. Defined in RFC 7519, a JWT is a compact, URL-safe token that encodes a set of claims as a JSON object. This guide covers everything developers need to know about JWT structure, decoding, security considerations, and common pitfalls.

Anatomy of a JWT

Every JWT consists of three parts separated by dots: the header, the payload, and the signature. The header is a JSON object specifying the signing algorithm (such as HS256, RS256, or ES256) and the token type (typically “JWT”). The payload contains claims — key-value pairs that carry information about the user, session, or authorization context. The signature is a cryptographic hash of the header and payload, created using the specified algorithm and a secret or private key. Each part is independently Base64URL-encoded, making the entire token safe to transmit in HTTP headers, URL parameters, and cookies.

Understanding JWT Claims

The JWT specification defines seven registered claims: iss (issuer) identifies who created the token, sub (subject) identifies the principal, aud (audience) specifies the intended recipients, exp(expiration time) sets the token’s deadline, nbf (not before) defines the earliest valid time, iat (issued at) records creation time, and jti (JWT ID) provides a unique identifier for the token. Beyond these, applications add custom claims like user roles, permissions, tenant IDs, and any domain-specific data needed by the receiving service.

How JWT Decoding Works

Decoding a JWT does not require a secret key — it is simply the reverse of Base64URL encoding. Split the token at the dots, decode each of the first two segments from Base64URL to bytes, then parse the resulting bytes as UTF-8 JSON. The third segment (signature) remains as raw bytes unless you need to verify integrity. This is exactly what this tool does: pure client-side Base64URL decoding and JSON parsing, with no external libraries or server calls. This distinction between decoding and verification is critical — decoding reveals the contents, while verification confirms the token has not been tampered with and was issued by a trusted party.

Token Expiration and Time Claims

Time-based claims use Unix timestamps (seconds since the Unix epoch, January 1, 1970 UTC). The exp claim is the most important — once the current time exceeds this value, the token should be rejected. The iat claim helps track when a token was issued, useful for implementing token rotation or detecting tokens older than a certain threshold. The nbf claim prevents a token from being used before a specific time, which is useful when issuing tokens for future use. This tool automatically converts these timestamps to human-readable dates in your local timezone and shows whether the token is currently expired or valid.

JWT Security Best Practices

While JWTs are widely used, they require careful implementation to avoid security vulnerabilities. Always validate the algorithm in the header on the server side — the infamous “alg: none” attack exploits servers that blindly trust the header’s algorithm claim. Use asymmetric algorithms (RS256, ES256) when the token issuer and verifier are different services, and symmetric algorithms (HS256) only when both sides share a secret. Set short expiration times (minutes, not days) for access tokens and use refresh tokens for longer sessions. Never store sensitive data in the payload without encryption — Base64URL encoding is not encryption, and anyone with the token can read its contents. Always transmit JWTs over HTTPS and store them securely (httpOnly cookies are preferred over localStorage for browser applications).

Common JWT Use Cases

The most common use case is OAuth 2.0 and OpenID Connect, where JWTs serve as access tokens and ID tokens. Single sign-on (SSO) systems use JWTs to propagate authentication across services without requiring each service to call back to the identity provider. API gateways use JWTs to authorize requests before they reach backend services, reducing latency and load. Microservice architectures rely on JWTs to pass user context between services without shared session state. Even webhooks and server-to-server communication use JWTs to authenticate the sender and ensure payload integrity.

When Not to Use JWTs

JWTs are not always the right choice. For simple server-rendered applications with a single backend, traditional server-side sessions (stored in Redis or a database) are often simpler and easier to invalidate. JWTs cannot be revoked before expiration without maintaining a server-side blacklist, which partially defeats their stateless advantage. If your payload is large, JWTs add overhead to every request since the entire token is sent with each API call. For applications that need immediate revocation (e.g., account suspension), consider opaque tokens backed by a token store instead of, or in addition to, JWTs.