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.

Buğra SözeriDeveloper

Updated May 22, 2026 · Published September 1, 2025

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 (typically SHA-256-based). 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.

Signature verification

This decoder deliberately stops at parsing. It does notverify the signature, and it never will. Verification requires the issuer’s signing key — a symmetric secret for HS-family algorithms (HS256, HS384, HS512) or the matching public key for asymmetric ones (RS256, ES256, PS256). Symmetric secrets must never leave the server they were minted on, and even public-key verification belongs next to the code that actually consumes the token, where you can also enforce iss, aud, exp, and nbf checks against your own configuration.

Why we don’t verify in-browser: pasting your signing key into a web tool exposes it to every script and extension running in that tab, and any verification that happens client-side is trivially bypassed by an attacker who controls the page anyway. A signature is only as trustworthy as the environment that checked it.

See RFC 7519 §10 (Security Considerations) for the normative guidance: implementers must validate the signature before trusting any claim, and the validation must occur in a context that controls the keys.

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.

Sources & references

Authoritative references behind the math, constants, and tables on this page. Verified by Buğra Sözeri on the dates shown and re-checked at every deploy.

RFC 7519 — JSON Web Token (JWT) — IETF specification of the JWT format, registered claims (iss, sub, aud, exp, iat, jti), and validation rules(as of 2026-05-21)
RFC 7515 — JSON Web Signature (JWS) — Underlying signature framework JWTs use; defines the header.payload.signature structure parsed by the decoder(as of 2026-05-21)
RFC 7518 — JSON Web Algorithms (JWA) — Registered algorithm identifiers (HS256, RS256, ES256, etc.) recognised in the header(as of 2026-05-21)
OWASP JSON Web Token Cheat Sheet — Security guidance summarising the alg='none' and algorithm-confusion attacks referenced in the pitfalls section(as of 2026-05-21)

Related guide

Want the full story on what each JWT segment means, which claims to validate, and how the signature actually defends the token? The decoding guide walks through it with worked examples.

Read: JWT token decoding guide →