JWT Decoder

Written byOleh Soloninupdated 5 October 2026

JWT token

Result

Header{ "alg": "HS256", "typ": "JWT" }
Payload
{ "sub": "1234567890", "name": "John Doe", "iat": 1516239022 }
AlgorithmHS256
Issued at2018-01-18T01:30:22.000Z
Expires at-
Expiry statusno expiry set

Decoding, which is not the same as verifying

Decode a JSON Web Token to inspect its header, claims and expiry. Runs entirely in your browser, so tokens are never transmitted.

A signed JWT — the JWS form this decoder reads — is three Base64URL segments separated by dots: header, payload and signature. The first two are encoded, not encrypted, so anyone holding the token can read every claim inside it. An encrypted JWT (JWE) is built differently, from five parts, and cannot be read without the key.

This decodes and does not verify. Checking the signature needs the secret or public key, so a decoded token tells you what it claims, never whether those claims are trustworthy.

How to use

Paste the whole token — three parts separated by dots.
The header and payload open immediately, and the time fields are converted to dates.
Check the algorithm in the header against the ones your server allows: reject a token with any other, because accepting it is the vulnerability.

The three parts of the sample token

A JWT is three Base64url strings joined by dots: header, payload and signature. The first two are encoded, not encrypted — anyone holding the token reads them without a key. That is precisely what this page does.

Base64url carries three bytes per four characters, so each JSON part is about a quarter shorter than its written form inside the token. It is also why a token gains weight with every field added to it: it travels on every request.

Counted from the token that ships in the field by default, 155 characters in total. A 43-character signature is exactly 32 bytes, or 256 bits — the output size of HS256.
Part	Characters	Decoded bytes	What is inside
Header	36	27	alg: HS256, typ: JWT
Payload	74	55	sub, name, iat
Signature	43	32	not verified here

The seven registered claims

RFC 7519 fixes seven names; everything else in the payload is free-form and agreed only between the issuer and the recipient. Three of the seven are times, and all three count seconds since 1 January 1970 — not milliseconds.

The decoder reads those three and turns them into dates. The sample token carries no exp at all, which is why the status line says no expiry is set: the token declares no expiry time, and for an access token that is a mistake — though a server may still reject it by its own age limit or revocation list.

In the sample token iat is 1516239022, which is 18 January 2018 — the date the decoder prints on the issued line. A thirteen-digit value in any of these fields means milliseconds, and the token is then out by a factor of a thousand.
Claim	Meaning	Format
iss	who issued it	string
sub	who it is about	string
aud	who it is meant for	string or list
exp	expires at	seconds since 1970
nbf	not valid before	seconds since 1970
iat	issued at	seconds since 1970
jti	unique token id	string

What this calculator shows

Header and payload as formatted JSON
The signing algorithm declared in the header
Issued-at and expiry timestamps as readable dates, with expiry status

What to keep in mind

Decoding only — the signature is not verified, which requires a key.
Runs locally in your browser; the token is not sent anywhere.

FAQs

Is the payload of a JWT encrypted?

No, only Base64url encoded. Anyone with the token reads it without a key — this page shows how little effort that takes. Passwords, full document numbers and health data do not belong in it.

What is the difference between decoding and verifying?

Decoding unpacks the first two parts and needs nothing. Verifying confirms the signature and needs the issuer's key. Only the first happens here: without the key the third part cannot be checked.

What do exp and iat mean?

iat is when the token was issued, exp is the moment after which it is no longer valid. Both are counts of seconds since 1 January 1970 UTC, with no time zone and no daylight saving.

Why does the sample token have no expiry?

Its payload has no exp field, and the decoder reports that no expiry is set. That does not make the token valid forever: the server decides whether and for how long to accept it, and may require exp, cap the age by iat or revoke tokens by its own rules. In an access token a missing exp is a fault; in an example it is a convenience, since it will read the same a year from now.

Can an issued token be revoked?

The token itself, no. The server checks the signature and the token's own claims — expiry, audience, issuer — without looking anything up, so a correctly signed token is accepted until its exp: that is the whole design. Revocation needs a deny list on the server or short lifetimes with a refresh token, and both hand back part of the advantage.

Is it safe to paste a real token here?

The decoding happens in the browser and nothing is sent anywhere. But a live token is a working key: it lingers in the clipboard and in the field's history. For inspection, reach for an expired one or mint a test token.

Worked example

What sits inside a token

Input: A standard three-part JWT

Output: Header with alg and typ, payload with sub, name and iat

Note: Everything in the payload is readable by anyone who intercepts the token — which is why passwords and secrets must never go in there.

Useful links

All tools in Dev Tools

JWT Decoder

Result

Related tools

Base64 Encoder / Decoder

Unix Timestamp Converter

Online Hash Generator

JSON formatter and validator

Useful links