Why can anyone decode my JWT without the secret?

Because JWTs are signed, not encrypted. The header and payload are plain base64url - a reversible encoding, not cryptography - and the secret is only needed to create or verify the signature in the third segment. This is by design: clients often need to read claims like expiry locally. The rule that follows: never put secrets, passwords, or PII you would not show the user inside a JWT payload.

Can I decode a JWT token online for free without installing anything?

Yes. Paste the token, or the whole Authorization header value, into the JWT Token box and click Decode; it is free, no signup, and runs client-side in the page. You get the header and payload as formatted JSON, each with a Copy button, a banner saying whether the token has expired, and a table converting exp, iat and nbf to UTC dates. Only 3-segment signed tokens decode; a 5-segment encrypted token returns an error.

Why does the claims table say my token expires in thousands of years?

Your token most likely stores exp in milliseconds instead of seconds. RFC 7519 defines exp, iat and nbf as seconds since 1970, so a 13-digit value such as 1767229200000 is read as a date tens of thousands of years away and shown as Valid. Divide by 1000 at the issuer. A claim stored as a string, such as "1767229200", is not a number and is left out of the table entirely. Status is also judged against your own device clock with no leeway, so a token a few seconds from expiry can read differently here than on a server that allows clock skew.

Why does this tool not verify the signature?

Verification requires the signing key - the shared secret for HS256 or the private/public key pair for RS256 - and pasting an HMAC secret into a web page is exactly the habit that leads to leaked keys. Verification belongs on your server using a maintained library (jsonwebtoken, jose, PyJWT). This tool answers "what is in this token and is it expired", which covers most day-to-day debugging.

My token decodes fine but the API returns 401. What should I check?

In rough order of likelihood: the exp claim has passed (check the claims table), the aud or iss claim does not match what the API validates, the signing key was rotated so the kid in the header no longer resolves, or nbf is a few seconds in the future due to clock skew between issuer and verifier. Decoding shows you the first three instantly; skew you diagnose by comparing iat against your own clock.

What is the difference between a JWT and a session token?

A classic session token is an opaque random ID; all the state lives server-side, and revoking a session is deleting a row. A JWT carries its state inside itself and is verified by signature alone, so the server needs no session store - great for horizontal scaling and cross-service auth - but revocation before expiry requires extra machinery like a denylist. That trade-off is why the standard pattern is short-lived JWTs (15 minutes) paired with a revocable refresh token.

What do exp, iat, nbf, sub, iss, and aud mean?

These are the registered claims from RFC 7519. exp/iat/nbf are Unix timestamps: when the token expires, when it was issued, and when it starts being valid. sub is the subject (usually the user ID), iss is the issuer (your auth server), and aud is the intended audience (the API that should accept it). Verifiers should check exp, iss, and aud at minimum - libraries do this when you configure them correctly.

What is the alg:none attack this tool warns about?

The JWT spec technically allows "none" as an algorithm, meaning an unsigned token. Early libraries would accept a token whose header claimed alg:none and skip verification entirely, letting attackers forge arbitrary payloads by just editing the base64. Modern libraries reject it by default, but the decoder flags it anyway - if you ever see alg:none on a real token, something is badly wrong upstream.

Why does my token have 5 segments instead of 3?

That is a JWE - an encrypted JWT - with segments for the protected header, encrypted key, IV, ciphertext, and auth tag. Unlike a plain JWS, the payload genuinely is encrypted, so no decoder can show it without the decryption key. This tool handles the common 3-segment signed variety; a 5-segment token needs to be decrypted by the party holding the key.

Should I store JWTs in localStorage or cookies?

localStorage is readable by any JavaScript on the page, so a single XSS vulnerability hands the attacker your token. An httpOnly, Secure, SameSite cookie is invisible to scripts, which closes the XSS-theft path at the cost of needing CSRF protection. Most security guidance lands on httpOnly cookies for the refresh token, with the short-lived access token kept in memory only.

Can I decode expired tokens?

Yes - expiry does not affect decodability at all, since exp is just a number in the payload. The decoder will flag it red and show how long ago it lapsed, which is often exactly what you need for post-incident debugging: pull a token from old logs, decode it, and confirm whether it was still valid at the time of the request in question.

JWT Decoder

Decode JWT headers and payloads, inspect claims, and check token expiry

JWT Token

Decode only - the signature is NOT verified. No secret required, nothing leaves your browser.

Category:security

Mode:Offline

Version:1.0.0

Access:Free

What is JWT Decoder?

JWT Decoder interface on Toolz.dev - Decode JWT headers and payloads, inspect claims, and check token expiry

JWT Decoder splits a JSON Web Token into its three dot-separated segments, base64url-decodes the header and payload, and renders both as formatted JSON. JWTs are not encrypted - the "encoding" is just base64url, a reversible transform - so anyone holding a token can read every claim inside it. This tool makes that inspection instant: paste a token from a Set-Cookie header, an Authorization header (the Bearer prefix is stripped automatically), or your auth provider's dashboard, and see exactly what your server put in there.

The claims table is where debugging happens. Registered time claims - exp (expiration), iat (issued at), and nbf (not before) - are Unix timestamps, useless to read raw. The decoder converts each to a UTC date and a relative time, shown as "Expired (3 hours ago)" or "Valid (expires in 14 minutes)", and flags expired tokens in red. Most "401 Unauthorized, but the token looks fine" incidents come down to an expired exp, a clock-skewed nbf, or an aud claim that does not match what the API validates - all visible here in two seconds.

One thing this tool deliberately does not do: verify signatures. Verification requires the signing secret (HS256) or public key (RS256/ES256), and a client-side tool asking you to paste an HMAC secret would be teaching bad habits. Decoding is 100% client-side - the token never leaves your browser, hits no server, and appears in no request log, which matters because a live production JWT is a bearer credential. Anyone who has it, is you.

Decoding is not verifying, and the distinction is the whole security model of a JWT. The header and payload are Base64url, not encrypted, so anyone holding a token can read every claim in it without any key at all. What the signature provides is proof that the contents have not been altered, and checking it requires the secret or public key, which is a server-side operation. Treat the payload as public information: never put anything sensitive in it.

A quick way to decode a JWT token online and check the result: paste Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiI0MiIsImlhdCI6MTc2NzIyNTYwMCwiZXhwIjoxNzY3MjI5MjAwfQ.sig and click Decode. The Bearer prefix is dropped, the Header panel shows {"alg": "HS256", "typ": "JWT"}, and the Payload panel, which works as a JWT payload viewer with its own Copy button, shows sub "42", iat 1767225600 and exp 1767229200. The claims table turns those into 2026-01-01T00:00:00.000Z and 2026-01-01T01:00:00.000Z, and marks exp as Expired. The signature segment here is the placeholder text sig, and the tool still decodes the token, because it never checks the signature.

How to use JWT Decoder?

Paste your token

Drop the JWT into the input area. Grab it from the Authorization header in your browser DevTools Network tab, a cookie, localStorage, or a curl response. A leading "Bearer " prefix and surrounding whitespace are stripped automatically, so you can paste the full header value without cleanup.

Read the decoded header and payload

Both segments render as formatted JSON side by side. The header tells you the signing algorithm (alg: RS256, HS256, etc.) and key ID (kid) - useful when your JWKS rotation is misbehaving. The payload holds the claims: sub, iss, aud, scopes, roles, and whatever custom data your auth layer added.

Check the claims table for expiry

Time claims (exp, iat, nbf) are decoded from Unix seconds into readable dates with relative times. An expired exp shows in red with exactly how long ago it lapsed; a valid one shows in green with time remaining. If nbf is in the future - usually clock skew between your servers - the token will be rejected even though it "looks" fine.

Remember: decoded, not verified

This tool never checks the signature - that requires the secret or public key and belongs on your server, not in a browser tool. Never treat decoded claims as trusted input: an attacker can mint a token with any payload they want. Only a verified signature proves the claims came from your issuer unmodified.

Key Features

Instant Header + Payload Decode

Base64url decoding in pure TypeScript - both JSON segments formatted and readable immediately

Expiry Detection

exp claim flagged red when expired, green when valid, with exact relative time either way

Humanized Time Claims

exp, iat, and nbf converted from raw Unix seconds to ISO dates and "3 hours ago" style phrasing

Bearer-Prefix Tolerant

Paste the whole Authorization header - "Bearer " and stray whitespace are stripped automatically

Frequently Asked Questions

The decoding itself is safe: it happens entirely in your browser, and the token is never sent over the network - verify that in the DevTools Network tab if you like. The broader caution is that a live production JWT is a bearer credential, so treat it like a password anywhere you paste it. For untrusted third-party tools, prefer expired tokens or ones from a staging environment.

Related Tools

security

Bcrypt Generator

Generate and verify bcrypt password hashes in the browser with an adjustable cost factor

security

JWT Generator

Generate and sign JSON Web Tokens with HS256, HS384, or HS512, add standard claims, and copy the token. Runs client-side.

security

Password Generator

Generate strong, random passwords with custom character sets and strength analysis

security

Password Strength Checker

Test how strong a password is with an entropy-based strength meter, estimated crack times, and specific suggestions to make it harder to guess - all processed privately in your browser.

Comments

0 comments

No comments yet. Be the first to share your thoughts!

jwtjwt decoderjson web tokendecode jwtjwt debuggertoken decoderjwt claimsexp claimbearer tokendecode jwt token onlinejwt token decode onlinejwt payload viewerinspect jwt claims

Learn more

Read the full JWT Decoder guide

Command Palette

JWT Decoder

What is JWT Decoder?

How to use JWT Decoder?

Paste your token

Read the decoded header and payload

Check the claims table for expiry

Remember: decoded, not verified

Key Features

Instant Header + Payload Decode

Expiry Detection

Humanized Time Claims

Bearer-Prefix Tolerant

Frequently Asked Questions

Related Tools

Bcrypt Generator

JWT Generator

Password Generator

Password Strength Checker

Comments

Learn more