Skip to main content

JWT Decoder

Decoded entirely in your browser — the token is never uploaded.

Share on Social Media:

JWT decoder: read the contents of any JSON Web Token instantly

A JWT decoder takes a JSON Web Token, that long dotted string your API hands out after login, and shows you the human-readable claims hidden inside. Paste the token and this online JWT decoder splits it into its three parts, Base64Url-decodes the header and payload, and prints clean JSON so you can see the issuer, expiry, subject, and any custom claims at a glance. It runs entirely in your browser, so the token never leaves your machine and there is no signup.

Tokens are everywhere in modern auth: OAuth 2.0, OpenID Connect, single sign-on, and stateless session cookies all lean on JWTs. When something breaks, like a 401 that should be a 200 or a session that expires too soon, the fastest fix is to decode the token and read it. A JWT decoder turns an opaque blob into the exact data your backend received.

How to use the JWT decoder

  1. Copy the token. Grab it from a response header (Authorization: Bearer ...), a cookie, or your network tab.
  2. Paste it in. Drop the full token into the input; the decoder splits it on the dots automatically.
  3. Read the header. See the signing algorithm (alg) and key id (kid).
  4. Read the payload. Inspect standard claims like exp, iss, and sub, plus your app's custom claims.
  5. Check the timestamps. Convert exp and iat from Unix seconds to confirm whether the token is expired.

How a JWT is structured

A JWT is three Base64Url-encoded segments joined by dots: header.payload.signature. The header and payload are JSON objects, merely encoded, not encrypted, which is why a decoder can read them with no secret. The signature is a cryptographic check that proves the token was not altered. A real token looks like eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0In0.SflKxw..., where each part before a dot decodes to readable content.

PartContainsEncoded?Example fields
HeaderToken metadataBase64Url, not encryptedalg, typ, kid
PayloadClaims about the userBase64Url, not encryptedsub, exp, iss, roles
SignatureIntegrity checkBinary, keyed hashHMAC or RSA over header+payload

The single most important point: a decoder reveals the payload but does not prove the token is valid. Anyone can read a JWT. Only your server, holding the secret or public key, can verify the signature. Never trust decoded claims for authorization without verifying the signature first.

Standard claims and what they mean

ClaimNameMeaning
issIssuerWho created and signed the token
subSubjectThe user or entity the token represents
audAudienceThe intended recipient API
expExpirationUnix time after which the token is invalid
nbfNot beforeUnix time before which the token is invalid
iatIssued atUnix time the token was created
jtiJWT IDUnique identifier to prevent replay

The alg field in the header tells you how the token was signed. Common values are HS256 (HMAC with a shared secret), RS256 (RSA with a public/private key pair), and ES256 (elliptic curve). An alg of none is a red flag and should never be accepted by a production verifier.

Signing algorithms compared

Choosing between symmetric and asymmetric signing changes how you distribute keys. HMAC algorithms use one shared secret for both signing and verifying, which is simple but means every service that checks a token also holds the power to mint one. RSA and ECDSA split that into a private signing key and a public verification key, so you can publish the public key (often via a JWKS endpoint) and let many services verify without being able to forge tokens.

AlgorithmTypeKeyingGood for
HS256Symmetric (HMAC-SHA256)One shared secretSingle service, simple setups
RS256Asymmetric (RSA)Private signs, public verifiesMulti-service, public verification
ES256Asymmetric (ECDSA)Smaller keys than RSAMobile, bandwidth-sensitive APIs
PS256Asymmetric (RSA-PSS)Private signs, public verifiesStronger RSA padding scheme
noneUnsignedNo keyNever in production

Debugging auth problems with a decoder

Most token bugs fall into a few buckets, and decoding the token tells you which one you are in within seconds. The decode itself answers "what does the server actually see," which is usually different from what you assumed. Work through the claims in this order before you touch your code.

SymptomClaim to checkLikely cause
401 on a valid loginaud, issToken issued for a different audience or issuer
Session expires too fastexp minus iatToken lifetime configured too short
"Token not yet valid"nbfClock skew between issuer and verifier
Missing permissionsroles / scopes claimAuthorization server not adding the claim
Signature verification failskid, algWrong key selected or algorithm mismatch

A practical example: a user reports being logged out after a minute. Decode the token, read iat and exp, subtract them, and if the difference is 60 you have found your misconfigured lifetime without reading a line of backend code. Likewise, a 401 that "makes no sense" often comes down to an aud value pointing at the wrong API.

Common mistakes

  • Treating the payload as private. JWT claims are only encoded, not encrypted, so never put passwords or secrets in a token.
  • Trusting a decoded token without verifying. Decoding proves nothing about authenticity; always check the signature server-side.
  • Misreading exp. It is in Unix seconds, not milliseconds, so a value like 1719230400 is a date, not the year 1719.
  • Copying a partial token. Leaving off a segment or trailing characters yields a decode error; copy the whole dotted string.
  • Accepting alg: none. A token claiming no signature must be rejected by any secure backend.

Tips and related tools

When debugging auth, decode both the access token and the refresh token, and compare the exp values to understand the session lifecycle. Since payloads are JSON, you can pretty-print them with the JSON Formatter, confirm structure with the JSON Validator, explore nested claims in the JSON Viewer, or convert a claims set with JSON to XML for legacy systems. Find more developer utilities in the development tools hub.

Frequently asked questions

What is a JWT decoder? It is a tool that splits a JSON Web Token into its header, payload, and signature, then Base64Url-decodes the readable parts so you can inspect the claims as formatted JSON.

Is a JWT encrypted? No. The header and payload are only Base64Url-encoded, which means anyone can read them. Only the signature is cryptographic, and it proves integrity rather than hiding the contents.

Can a decoder verify the signature? Reading the token does not require a key, so a browser decoder shows the claims but cannot prove authenticity. Signature verification must happen on your server with the secret or public key.

How do I check if a JWT is expired? Read the exp claim, which is a Unix timestamp in seconds, and compare it to the current time. If the current time is greater, the token has expired.

Is it safe to paste my token here? Yes. This JWT decoder runs entirely in your browser and never uploads the token, though you should still avoid sharing production tokens publicly.

What does the alg field mean? It names the signing algorithm, such as HS256, RS256, or ES256. A value of none means the token is unsigned and should be rejected.

Why does my token fail to decode? The usual cause is a truncated or malformed token; make sure you copied all three dot-separated segments without extra spaces or line breaks.

Can I decode a token from a cookie? Yes. Copy the JWT value out of the cookie and paste it in; the decoder handles it the same way as a bearer token.

🔗 Relevant Tools

Leave a comment

Comments go straight to our team — they are not published on the site.

ads

Please disable your ad blocker!

We understand that ads can be annoying, but please bear with us. We rely on advertisements to keep our website online. Could you please consider whitelisting our website? Thank you!