🔑 JWT Token Decoder

Paste any JWT to instantly decode its header, payload, and signature. Inspect claims, expiry, algorithm, and more — entirely in your browser.

QUICK LOAD:
JWT TOKEN
DECODED TOKEN
🔑

Paste a JWT token above to decode it

Header · Payload · Claims · Expiry — all decoded in your browser

About JWT Decoder

JSON Web Tokens (JWT, pronounced "jot") are compact, URL-safe tokens defined by RFC 7519 and widely used for authentication and information exchange in modern web applications. A JWT consists of three Base64URL-encoded sections separated by dots (header.payload.signature). The header identifies the token type and signing algorithm, the payload carries claims about the subject (user ID, roles, expiry), and the signature allows the recipient to verify the token has not been tampered with.

This tool instantly decodes all three sections of any JWT and presents them as formatted JSON. It also parses timestamp claims (exp, iat, nbf) into human-readable dates with relative time — so you can immediately see if a token has expired or when it was issued. Everything runs entirely in your browser; no token is ever transmitted to a server.

How to decode a JWT

  1. Copy your JWT from your application, browser DevTools, Postman, or curl response.
  2. Paste it into the input area above — the three sections decode automatically.
  3. Inspect the Header (algorithm, type, key ID), Payload (all claims), and Signature tabs.
  4. Check the Expiry section to see if the token is still valid, expired, or not yet active (nbf).

JWT sections explained

🔴 Header

Contains the token type (always 'JWT') and the signing algorithm: HS256, RS256, ES256, PS256, and their 384/512 variants. May include a key ID (kid) for key rotation.

🔵 Payload

Contains claims — statements about the user and additional metadata. Registered claims: iss (issuer), sub (subject), aud (audience), exp (expiry), iat (issued at), nbf (not before), jti (JWT ID).

🟢 Signature

A cryptographic signature of header + payload. Verifying it requires the server's secret key (HMAC) or public key (RSA/ECDSA) — this client-side tool can only decode, not verify.

⏰ Expiry Check

exp, iat, and nbf timestamps are converted to local date/time and shown with relative time: 'expires in 2h', 'issued 3d ago', 'not valid for 1m'.

🔒 Privacy

100% client-side. Your token never leaves your browser. Avoid pasting tokens on shared computers or untrusted environments.

🌐 Algorithm support

Decodes any JWT regardless of algorithm — HS256/384/512, RS256/384/512, ES256/384/512, PS256/384/512. The header is decoded as-is.

Frequently Asked Questions

Can this tool verify the JWT signature?

No. Signature verification requires the server's secret key (for HS256/384/512) or the server's public key (for RS256, ES256, PS256). This tool can only decode and display the header and payload. To verify a JWT, use your backend SDK or a tool like jwt.io where you can provide the key.

Is it safe to paste a real JWT into this tool?

All decoding happens in JavaScript running in your browser — no network request is made. However, treat JWTs like passwords: avoid pasting tokens from production systems on shared or public computers. For development and debugging, this tool is completely safe to use.

What is the difference between exp, iat, and nbf?

exp (Expiration Time) is the Unix timestamp after which the token must not be accepted. iat (Issued At) is when the token was created. nbf (Not Before) is the earliest time the token should be accepted — useful for tokens issued slightly ahead of when they will be used.

Why does my JWT have only two parts instead of three?

A standard JWT always has three dot-separated parts. If you see only two parts, the token may be an unsecured JWT (alg: none) with an empty signature, or it may be truncated. It could also be a different token format like an opaque OAuth 2.0 access token, which is not a JWT.

What algorithms does this decoder support?

Any algorithm — the decoder simply Base64URL-decodes the header and payload. HMAC (HS256/384/512), RSA (RS256/384/512), ECDSA (ES256/384/512), and RSA-PSS (PS256/384/512) all produce the same JSON header and payload structure. Only the signature format differs.

Developer guide

JWT decoder guide: read token claims and debug authentication

JSON Web Tokens (JWTs) are the most widely used format for stateless authentication in modern web applications. When a user logs in, the server issues a JWT that the client includes in subsequent requests. The server can validate the token and extract the user's identity and permissions without querying a database on every request.

A JWT consists of three parts separated by dots: a Base64URL-encoded header that describes the token type and signing algorithm, a Base64URL-encoded payload that contains the claims (assertions about the user), and a cryptographic signature that proves the token was issued by a trusted party and has not been tampered with.

Braxik's JWT decoder extracts the header and payload sections so you can read all the claims without writing code. This is most useful when debugging authentication failures: you can check the expiry time (exp), the issuer (iss), the audience (aud), the subject (sub), and any custom role or scope claims that your application relies on.

It is important to understand what the decoder does and does not do. It reads and displays the header and payload, which requires no secret knowledge. It does not verify the signature, which requires the correct signing key. Displaying claims tells you what the token says — it does not tell you whether to trust those claims. Only the server with the correct key can verify trustworthiness.

How it works

JWT decoding is straightforward because the header and payload are just Base64URL-encoded JSON. The decoder splits the token on the '.' delimiter, extracts the first two segments, decodes each from Base64URL to bytes, interprets the bytes as UTF-8 text, and parses the result as JSON. This requires no secret keys or cryptographic operations.

The third segment (the signature) contains binary cryptographic data. The decoder displays it as a hex or Base64URL string but does not attempt to verify it, because verification requires the signing key (HMAC secret or RSA/ECDSA public key) which is kept private by the issuing server.

Timestamp claims (exp, iat, nbf) are stored as Unix epoch seconds. The decoder converts these automatically to human-readable local time and UTC so you can immediately see whether a token is expired or not yet valid without manual epoch conversion.

Common uses

  • Check why an API request is failing because of an expired, not-yet-valid, wrong audience, or wrong issuer token.
  • Inspect role, permission, or scope claims when debugging access control failures in a Spring Security, Keycloak, or Auth0 integration.
  • Decode token timestamps into readable local time to diagnose clock skew issues between services.
  • Verify that a newly issued token contains the expected claims before writing client-side code to read them.
  • Check the algorithm specified in the header to confirm that your server is not accidentally accepting the 'none' algorithm.
  • Inspect multi-tenant claims such as tenant_id or org_id when debugging multi-tenant SaaS authentication.
  • Review token structure when migrating from one identity provider to another to confirm claim names are consistent.

Before you rely on the result

  • Never share production access tokens or refresh tokens in bug reports, screenshots, Slack messages, or public forums — even expired tokens can reveal user identities and claim values.
  • Treat decoded claims as informational only. A token is not trustworthy unless the signature has been verified by the server using the correct signing key.
  • Always check the exp claim value against the current UTC time when diagnosing 401 Unauthorised errors — most auth failures are caused by expired tokens.
  • Verify the alg field in the header — it should be RS256, ES256, or HS256 for most applications. The value 'none' means no signature verification, which is a serious security vulnerability.
  • Check iss (issuer) and aud (audience) against your application's expected values — tokens issued for a different service can pass signature verification but should be rejected.
  • For service-to-service tokens, check the sub claim and any custom service identity claims to confirm the correct caller is identified.
  • Look at nbf (not before) if the token is rejected immediately after issuance — clock skew between the issuing server and the validating server is a common cause.