Why isn't the signature verified?

Verification requires the issuer's public key (for asymmetric algs like RS256/ES256) or symmetric secret (HS256). Both belong on your backend, not in a browser tool. Anyone running JavaScript on your machine would otherwise have to handle that secret, which is exactly what a JWT design tries to avoid.

Can I decode any JWT without the secret?

Yes — the header and payload are base64url-encoded, not encrypted. Anyone who has the token can read what's in it. That's why you should never put secrets (passwords, raw credit-card numbers) inside a JWT payload.

What algorithms does the decoder support?

All of them, for inspection. The tool reads the algorithm name from the header but doesn't apply it. Common values: HS256 (HMAC-SHA-256, symmetric), RS256 (RSA-SHA-256, asymmetric), ES256 (ECDSA-P256-SHA-256). The dangerous 'none' algorithm — which means 'this token has no signature' — should always be rejected by your verification code.

Is the expiry calculated in my time zone?

It's calculated in seconds against your computer's current time, then displayed as a human-readable duration (e.g. 'in 3h'). The exp claim itself is always Unix seconds (UTC).

What if the payload isn't JSON?

The tool reports an error. Standards-compliant JWTs always carry JSON payloads, but some implementations stuff binary or text data into the segment — those are technically JWS, not JWT, and need a different parser.

What's the difference between JWT and JWS?

JWT is a JWS (JSON Web Signature) whose payload is required to be a JSON object. Every JWT is a JWS, but a JWS can carry any byte string as payload.

JWT Decoder

Paste a JWT — see header, payload, algorithm, and expiry in one view.

A JSON Web Token (JWT) carries claims about an authenticated user in three dot-separated parts: a base64url-encoded header, a base64url-encoded payload, and a signature. The decoder below splits the token, parses each segment as JSON, surfaces the algorithm and time-to-expiry, and shows the signature for reference. It does not verify the signature— that requires the issuer’s key and should happen on your backend, not in a browser tool.

All decoding happens locally. Convertitive never logs, stores, or transmits the token you paste.

JWT (header.payload.signature)

Header

{
  "alg": "HS256",
  "typ": "JWT"
}

Payload

{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022
}

Algorithm

HS256

Expires

no exp claim

Signature is shown for reference but not verified. Verifying a JWT requires the issuer’s public or symmetric key — that step happens on your backend, not in a browser tool.

SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

How to use

Paste your JWT
Three base64url segments joined by dots. The encoded token is usually one long line — line breaks are tolerated.
Inspect header and payload
Each segment is shown as pretty-printed JSON. The algorithm card pulls 'alg' from the header for quick reference.
Check expiry
If the payload contains 'exp' (Unix timestamp in seconds), the tool computes how far away it is from your machine's current time.

Standard claims

Claim	Meaning
iss	Issuer — who created the token.
sub	Subject — the user or entity the token is about.
aud	Audience — for whom the token is intended.
exp	Expiry time (Unix seconds). After this, the token must be rejected.
iat	Issued-at time (Unix seconds).
nbf	Not-before — the token is invalid before this time.
jti	JWT ID — unique token identifier, useful for revocation lists.

Frequently asked questions

Why isn't the signature verified?: Verification requires the issuer's public key (for asymmetric algs like RS256/ES256) or symmetric secret (HS256). Both belong on your backend, not in a browser tool. Anyone running JavaScript on your machine would otherwise have to handle that secret, which is exactly what a JWT design tries to avoid.
Can I decode any JWT without the secret?: Yes — the header and payload are base64url-encoded, not encrypted. Anyone who has the token can read what's in it. That's why you should never put secrets (passwords, raw credit-card numbers) inside a JWT payload.
What algorithms does the decoder support?: All of them, for inspection. The tool reads the algorithm name from the header but doesn't apply it. Common values: HS256 (HMAC-SHA-256, symmetric), RS256 (RSA-SHA-256, asymmetric), ES256 (ECDSA-P256-SHA-256). The dangerous 'none' algorithm — which means 'this token has no signature' — should always be rejected by your verification code.
Is the expiry calculated in my time zone?: It's calculated in seconds against your computer's current time, then displayed as a human-readable duration (e.g. 'in 3h'). The exp claim itself is always Unix seconds (UTC).
What if the payload isn't JSON?: The tool reports an error. Standards-compliant JWTs always carry JSON payloads, but some implementations stuff binary or text data into the segment — those are technically JWS, not JWT, and need a different parser.
What's the difference between JWT and JWS?: JWT is a JWS (JSON Web Signature) whose payload is required to be a JSON object. Every JWT is a JWS, but a JWS can carry any byte string as payload.

About

Token anatomy

A JWT looks like header.payload.signature. Each part is base64url-encoded (no padding). The header is a small JSON object with at least an 'alg' field. The payload is a JSON object of claims — standard ones like 'iss', 'sub', 'exp' and any custom fields the issuer chose. The signature is computed over the dot-joined header and payload using the algorithm declared in the header.

Common pitfalls

Three things bite JWT users repeatedly: (1) accepting alg='none', which means 'unsigned' — always reject this server-side. (2) Trusting the 'iss' field without also checking the signature, which is trivially forgeable. (3) Putting reversible secrets in the payload because it 'looks encoded' — base64url is not encryption.