Developer Free · no signup

JWT Decoder

Decode JSON Web Tokens to inspect header, payload, and expiration without verification.

Paste a JWT and the decoder instantly shows you the header (with the alg and typ fields), the full payload of claims, and the raw signature segment. It converts Unix timestamps such as exp, iat, and nbf into readable dates so you can see at a glance whether a token is expired. Note that decoding is not the same as verifying — this tool reads what the token says but does not check the signature against a secret.

Updated Krawly Editorial TeamIn-house engineers, writers & reviewers

Explore More Free Tools

Discover 150+ free tools for web scraping, SEO analysis, OSINT, and more. 30 free uses every day — no signup required.

150+ Free Tools No Signup Required JSON / CSV / Excel 30 Uses / Day
Quick answer

Paste a JWT and the decoder instantly shows you the header (with the alg and typ fields), the full payload of claims, and the raw signature segment. It converts Unix timestamps such as exp, iat, and nbf into readable dates so you can see at a glance whether a token is expired. Note that decoding is not the same as verifying — this tool reads what the token says but does not check the signature against a secret.

What is JWT Decoder?

The JWT Decoder is a free online tool that splits a JSON Web Token into its three parts and Base64URL-decodes the header and payload into readable JSON. It reveals the signing algorithm, all standard and custom claims, and human-readable timestamps for fields like exp and iat. Decoding happens entirely in your browser, so tokens are never transmitted or logged.

How to use JWT Decoder

  1. 1

    Copy the token

    Grab the JWT from your browser's storage, a network request's Authorization header, or an API response. A JWT is a single string with three sections separated by dots, like xxxxx.yyyyy.zzzzz.

  2. 2

    Paste it into the decoder

    Drop the full token into the input field. The tool automatically splits it on the two dots and Base64URL-decodes the first two segments.

  3. 3

    Read the header and payload

    The header tells you the signing algorithm and key hints, while the payload lists every claim. Custom claims from your application appear alongside the registered ones like iss, sub, and aud.

  4. 4

    Check the timestamps

    Look at the converted exp and iat dates to judge whether the token is still valid. If exp is in the past, the token is expired and your API should reject it regardless of a valid signature.

Try it when you need to…

  • Your API keeps returning 401 and you need to see whether the token is expired or missing a required claim
  • You need to confirm which algorithm your identity provider signs with before configuring signature verification
  • You want to see the exact scopes or roles embedded in a user's token without adding debug logging

Use cases

  • Inspect the claims inside an auth token while debugging a login or session issue
  • Check whether a token has expired by reading the exp timestamp in human-readable form
  • Confirm which signing algorithm (HS256, RS256, ES256) an identity provider is issuing
  • Compare the payload of two tokens to spot why one is accepted and another rejected
  • Explore the standard OIDC claims (sub, aud, iss, scope) returned by an OAuth provider

Key features

Decodes the header and payload from Base64URL into formatted, readable JSON
Highlights the algorithm (alg) and token type (typ) from the header
Converts exp, iat, and nbf Unix timestamps into local human-readable dates
Separates and displays the raw signature segment without altering it
Runs fully client-side so tokens are never sent to any server

Tips & best practices

Decoding is NOT verifying. This tool reads the token's contents but does not validate the signature, so never trust a decoded payload for authorization decisions — always verify the signature server-side with the correct key.

A JWT payload is only Base64URL-encoded, not encrypted. Anyone who intercepts the token can read every claim, so never put passwords, secrets, or sensitive personal data in it.

Base64URL differs from standard Base64: it replaces + with -, / with _, and omits padding. That is why pasting a JWT segment into a plain Base64 decoder can fail.

A token can have a perfectly valid signature and still be expired. Always check exp and nbf in addition to signature verification when enforcing access.

Frequently asked questions

No. Decoding only reveals the contents of the header and payload; it does not check the signature. To confirm a token is authentic and untampered you must verify the signature server-side using the secret (for HMAC algorithms) or the public key (for RSA and ECDSA algorithms). Treat a decoded payload as informational only.

A standard JWT is signed, not encrypted. The header and payload are merely Base64URL-encoded, which is trivially reversible, so anyone holding the token can read all its claims. If you need the contents to be confidential you must use JWE (JSON Web Encryption) instead of a plain signed JWT.

exp is the expiration time after which the token must be rejected, iat is when the token was issued, and nbf (not before) is the earliest time the token becomes valid. All three are Unix timestamps in seconds, and this tool converts them to readable dates so you can quickly judge a token's validity window.

JWTs use Base64URL encoding, which swaps the + and / characters for - and _ and drops the trailing = padding so the token is URL-safe. A standard Base64 decoder may choke on the missing padding or the substituted characters, which is why a JWT-aware decoder is needed.

They are signing algorithms named in the header's alg field. HS256 uses a shared HMAC secret, RS256 uses an RSA public/private key pair, and ES256 uses elliptic-curve keys. The choice matters for verification: symmetric HS256 uses one secret for both signing and checking, while asymmetric RS256 and ES256 let you verify with a public key you can safely distribute.

The decoding runs entirely in your browser and the token is never sent to a server or stored, so pasting is safe from a transmission standpoint. That said, treat any token you paste as sensitive because it may still grant access until it expires — revoke or rotate it if you suspect it has leaked.

The first part is the header describing the algorithm and token type, the second is the payload carrying the claims, and the third is the signature that binds the first two so tampering can be detected. The header and payload are readable after Base64URL decoding, but the signature is a cryptographic value that only proves integrity when verified with the right key.