JWT Decoder

Paste any JSON Web Token and see exactly what is inside — header, payload, and signature — decoded instantly. This free JWT decoder translates standard claims like exp, iat, and nbf into readable dates, warns you when a token is expired, and runs 100% client-side: your token never leaves your browser.

Decode a JWT

How to Use the JWT Decoder

Debugging a token takes seconds:

  1. Paste the token into the box above. It decodes automatically as you type — no need to press anything — or hit Decode Token to force a fresh decode.
  2. Check the badges first. The blue badge shows the signing algorithm (alg), and the green or red badge tells you at a glance whether the token is still valid or EXPIRED, with the remaining lifetime spelled out.
  3. Read the claims table. exp, iat, and nbf are translated from Unix timestamps into both UTC and your local time, so "is this token supposed to work right now?" is answered immediately.
  4. Inspect the header and payload JSON. The pretty-printed output shows every claim — user id, roles, issuer, audience — exactly as your backend will see it. Spot a missing exp? That is a token that never expires, which is worth knowing.
  5. Remember the privacy guarantee. Everything happens in this page. You can even disconnect your network and keep decoding — the ultimate proof that your token never leaves your device.

Copying tokens out of terminal output is the usual source of "invalid token" errors: terminals love to add line breaks and trailing spaces. The decoder trims whitespace automatically, but a token split across two lines will still need to be joined first.

How JWT Decoding Works

A JWT is not encrypted — it is merely encoded. Decoding reverses three simple steps:

token = base64url(header) + "." + base64url(payload) + "." + signature

Each of the first two parts is JSON text run through base64url encoding — standard base64 with + and / swapped for - and _ and the = padding stripped, so the token survives inside URLs and HTTP headers. The decoder splits on the dots, reverses the base64url step, and parses the JSON. The third part, the signature, is left untouched: it is a cryptographic checksum that only the issuer's key can verify, and a decoder has no business touching it.

The timestamp claims are Unix times — seconds since January 1, 1970. The decoder multiplies by 1,000 to get JavaScript milliseconds and formats the result twice: once in UTC (the lingua franca of servers and logs) and once in your local timezone (the time on your wrist). Comparing exp against the current time produces the validity badge: red EXPIRED if the moment has passed, green with a countdown like "expires in 2d 4h 12m" if it has not.

Worked Example

Here is the classic example token, decoded step by step. Paste it into the tool above to follow along:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

StepWhat the decoder doesResult
1. Split on dotsThree parts: header, payload, signatureAll three present ✓
2. Decode the headerbase64url → JSON{"alg":"HS256","typ":"JWT"}
3. Decode the payloadbase64url → JSON{"sub":"1234567890","name":"John Doe","iat":1516239022}
4. Translate iat1516239022 → dateJan 18, 2018 (UTC)
5. Check expNo exp claim presentNo expiry badge — this token never expires

Two lessons hide in this example. First, everything about "John Doe" is readable by anyone holding the token — which is why you never put passwords or other secrets in a payload. Second, the absence of exp means the token is valid forever unless the server keeps a revocation list; in production, always issue short-lived access tokens.

Standard Claims Reference

The JWT specification reserves seven registered claim names. You will meet them in every token worth debugging:

ClaimNameMeaning
issIssuerWho created the token — e.g. your auth server's URL
subSubjectWho the token is about — usually the user id
audAudienceWho the token is intended for — your API's identifier
expExpirationUnix time after which the token must be rejected
nbfNot beforeUnix time before which the token must be rejected
iatIssued atUnix time when the token was created
jtiJWT IDA unique id for this token — used for revocation lists

Anything else in the payload is a private claim — role, email, plan, whatever your application needs. Namespacing private claims (e.g. https://myapp.com/role) avoids collisions with future registered names.

Limitations

A decoder is a magnifying glass, not a judge. It cannot verify the signature — a token that decodes cleanly may still be forged, expired, or issued by an attacker; only your backend, holding the secret or public key, can decide trust. The payload is not secret. Base64 is an encoding, not encryption: anyone who intercepts the token reads every claim, so keep sensitive data out of payloads and always transmit tokens over HTTPS. Encrypted (JWE) tokens will not decode — their payload is ciphertext, and without the decryption key this tool (correctly) shows you nothing. Clock skew matters: the EXPIRED badge uses your device's clock, so a token can look expired on a machine with the wrong time. And a practical warning that applies to every decoder on the internet, including server-side competitors: never paste a live production token into a tool you do not trust, because whoever runs the server can log it. That is precisely why this page does all of its work locally — paste with confidence, or better yet, debug with a throwaway test token.

A decoded JWT payload is JSON — usually minified into one dense line. Our guide on how to format JSON covers pretty-printing it, validating it, and the mistakes that break parsers.

Guides for This Tool

Frequently Asked Questions

What is a JWT?
A JWT (JSON Web Token) is a compact, URL-safe way to carry claims — statements like who you are and when the token expires — between two parties. It has three parts separated by dots: a header (the algorithm used), a payload (the claims, as JSON), and a signature. Servers issue JWTs at login so that later requests can prove who you are without a database lookup on every call.
Is it safe to decode a JWT online?
Decoding itself is harmless — it is just base64 decoding, the same as unzipping a file. The risk with some online decoders is that they send your token to their server, where it could be logged. This decoder runs 100% in your browser: your token is never transmitted anywhere, which you can verify by decoding with your network disconnected.
What do exp, iat, and nbf mean in a JWT?
These are the standard registered claims, all measured in seconds since the Unix epoch (January 1, 1970). exp is when the token expires and must no longer be accepted; iat is when it was issued; nbf (not before) is the earliest moment it becomes valid. This decoder converts all three into readable UTC and local dates and warns you when a token is expired.
Can this tool verify a JWT signature?
No — and that is by design. Verifying a signature requires the secret key (for HS256) or the public key (for RS256/ES256), and a simple decoder never asks for those. This tool shows you the algorithm and the claims so you can debug tokens; actual verification belongs in your backend code with a proper JWT library.
My token shows an error — what went wrong?
Almost always one of three things: the token does not have exactly three dot-separated parts (check for stray whitespace or line breaks when copying), one part is not valid base64url (JWTs use - and _ instead of + and /), or the decoded header or payload is not valid JSON. Paste the token again carefully — copying from terminal output often grabs an extra newline.
What is the difference between JWS and JWE?
JWS (JSON Web Signature) is a signed token: the payload is readable by anyone but tamper-evident, which is what almost everyone means by a JWT. JWE (JSON Web Encryption) is an encrypted token: the payload is opaque ciphertext that only the key holder can read. This decoder handles signed JWS tokens; encrypted JWE tokens cannot be decoded without the decryption key.

Related Tools