How to Decode a JWT Token Online for Free (Header, Payload, Claims and Expiry — Without Trusting It)

To decode a JWT token online for free, paste it into the JWT Decoder: it splits the token into its three Base64URL segments, shows the header and payload as formatted JSON with a table explaining each claim, and converts the time claims (exp, iat, nbf) into real dates in your timezone and UTC with a live "expires in / expired" badge. One fact must lead everything else: decoding is not verifying — the signature is not checked, anyone can forge a token that decodes to any payload, and a decoded JWT should never be trusted on its own. This guide explains what you are looking at and how to read it safely.

What a JWT Actually Is

A JSON Web Token is three Base64URL-encoded segments joined by dots: header.payload.signature. Base64URL is ordinary Base64 adapted for URLs — it swaps two characters and drops the padding — and it is an encoding, not an encryption. Anyone holding the token can decode the first two segments with any decoder, including this one, and read every claim in plain text. That openness is by design: the token's protection is supposed to come from the third segment, the signature, which only the issuer can produce — and which a decoder, by design, does not check.

Segment	Contains	What the decoder does with it
Header	JSON describing the token, typically the signing algorithm and type, e.g. {"alg":"HS256","typ":"JWT"}	Decodes and formats it as readable JSON
Payload	JSON of claims — statements about a user or session, such as sub, name, iat, exp	Decodes it, formats it, and explains each claim in a claims table
Signature	The issuer's cryptographic signature over the first two segments	Shows it exists; does NOT verify it — verification belongs server-side, with the issuer's key

How to Decode a JWT, Step by Step

1. Copy the whole token. All three segments, including both dots. A token pasted without its final segment is malformed, and the decoder will tell you so specifically rather than guessing.
2. Paste it into the decoder. Go to the JWT Decoder — it runs on your device only, which matters for the safety rules below.
3. Read the header. Note the algorithm ("alg") — you will want it to match what your server expects, because algorithm confusion is a real attack family, not a trivia point.
4. Read the payload and the claims table. Each registered claim is explained: who the token is about, who issued it, and the three time claims converted from raw seconds into dates you can sanity-check.
5. Check the expiry badge. The tool converts exp into your timezone and UTC and shows a live "expires in" or "expired" state — the fastest way to answer the most common debugging question: is this token simply old?
6. Stop at decoding. Whatever the payload says, treat it as a claim, not a fact, until a server has verified the signature with the issuer's key.

Worked Example: The Classic jwt.io Token

The worked example on the tool page is the classic demonstration token from jwt.io. Its header decodes to {"alg":"HS256","typ":"JWT"} — HMAC-SHA256 signing, token type JWT. Its payload decodes to {"sub":"1234567890","name":"John Doe","iat":1516239022}: a subject identifier, a display name, and an issued-at time. That iat value is seconds since the Unix epoch, and the decoder renders it as a real date — 18 January 2018. Note what the example payload does not carry: no exp claim, which is why the decoder's expiry badge has nothing to count down for this particular token — a useful reminder that the claims present vary by issuer, and the claims table only explains what is actually there.

Reading the Time Claims

Claim	Meaning	Why it matters when debugging
exp	Expiry: the time after which the token must be rejected	The most common cause of "my token stopped working" — compare it with now, in the converted date the tool shows
iat	Issued at: when the issuer created the token	An iat in the future points at clock skew between systems; an old iat with no exp means a token that formally never expires
nbf	Not before: the token is invalid until this time	Explains rejections immediately after issuance when clocks disagree slightly

All three are seconds since the Unix epoch — a raw count, meaningless to a human until converted. The decoder converts them into your local timezone and UTC side by side, because half of all expiry confusion is really timezone confusion: a token that looks expired at 14:00 local may be perfectly valid once both sides are read in UTC.

The Security Rules That Are Not Optional

Decode-only tools are safe to use and dangerous to believe. Four rules cover the whole risk. First: decoding proves nothing — not the issuer, not the integrity, not the identity. Anyone can build a token whose payload says anything; only server-side signature verification with the issuer's key separates a real token from a forgery. Second: never paste production tokens into any tool casually. A live session token pasted into a stranger's website is a credential handed over; this decoder runs on-device only, and that property — not a promise — is what makes pasting here a reasonable act. Verify that property matters to you for any tool you use. Third: never make an authorisation decision from decoded output in a client, a screenshot or a log line; the server verifies, every time. Fourth: treat unexpected claims as a finding, not a curiosity — an alg you did not expect, an issuer you do not recognise, or an exp years in the future are each worth raising with whoever issued the token.

When the Decoder Says the Token Is Malformed

Bad input gets a specific explanation rather than a shrug, and each message points at a different repair. A wrong segment count means the paste was truncated, or the string was never a JWT at all — copy the token again, in full. Invalid Base64URL means a character outside the alphabet crept in, commonly a line break, a space, or a standard-Base64 character pasted from a different encoding. Unparseable JSON means a segment decoded to bytes that are not JSON — the token is corrupt, hand-altered, or not the token you meant to copy. Reading the specific message beats re-pasting blindly: it tells you whether the problem is your clipboard, your source, or the token itself.

Five Mistakes People Make With JWT Decoders

• Trusting a decoded payload. The decoder shows what a token claims. Without signature verification — server-side, with the issuer's key — a payload is an assertion by whoever handed you the token, nothing more.
• Pasting live production tokens into random websites. A session token is a credential. Use tools that run on-device only, and prefer decoding test tokens or expired ones when the question allows it.
• Reading epoch seconds as if they were dates. 1516239022 is not a calendar entry until converted; guessing at it produces expiry "bugs" that are really reading errors. Use the converted local and UTC dates.
• Ignoring the header's algorithm. The alg claim is part of the security story. If your system expects one algorithm and the token names another, that mismatch is a stop-and-investigate, not a detail.
• Debugging expiry in one timezone only. Servers usually think in UTC; laptops think locally. Compare exp against both renderings before concluding a token expired early or late.

Related Tools and Guides

• JWT Decoder — the tool used in this guide: header and payload as JSON, a claims table, converted time claims and a live expiry badge.
• JSON Formatter — format and validate the JSON you meet inside payloads, APIs and config files.
• Base64 Encoder / Decoder — the encoding underneath JWT segments, for text and files, UTF-8 safe.
• How to format and validate JSON online — fix JSON errors with exact line and column positions.
• How to encode and decode Base64 online — the companion guide to the encoding every JWT segment uses.

Frequently Asked Questions

How do I decode a JWT token online for free?

Paste the full token — all three segments — into the JWT Decoder. It shows the header and payload as formatted JSON, explains each claim in a table, and converts exp, iat and nbf into real dates in your timezone and UTC. It runs on your device only.

Does decoding a JWT verify it?

No. The decoder does not check the signature, and decoding proves nothing about who issued the token or whether it was tampered with. Anyone can forge a token that decodes to any payload; only server-side verification with the issuer's key establishes trust.

What are the three parts of a JWT?

Header, payload and signature, each Base64URL-encoded and joined by dots. The header names the signing algorithm and type; the payload carries the claims; the signature is what a server checks — and what a decoder deliberately does not.

How do I check when a JWT expires?

Look at the exp claim: it is seconds since the Unix epoch. The decoder converts it to your local time and UTC and shows a live badge telling you whether the token expires in some amount of time or has already expired.

Is it safe to paste a JWT into an online decoder?

Only into one that runs entirely on your device, like this one — a production token pasted into a tool that uploads it is a credential shared. Even then, prefer test or expired tokens when they answer your question, and never trust decoded output for authorisation.

Why does the decoder say my token is malformed?

It gives a specific reason: the wrong number of segments (a truncated paste), invalid Base64URL characters (often a stray space or line break), or a segment that decodes to something that is not JSON. Each points at a different fix.

What does iat 1516239022 mean in the example token?

It is the issued-at time in seconds since the Unix epoch, and it converts to 18 January 2018. The classic example payload — sub 1234567890, name John Doe — carries iat but no exp, so that token has no expiry for a badge to count down.