Is my token sent to a server?

No. Decoding happens entirely in your browser using the built-in atob() function and JSON.parse(). Your token never leaves your device.

Can this verify the JWT signature?

No. Signature verification requires the secret key or RSA public key, which is server-side information. This tool decodes the readable parts (header and payload) only — exactly as any recipient does before verifying.

A JSON Web Token (JWT) is a compact, URL-safe token made of three Base64URL-encoded parts separated by dots — header (algorithm), payload (claims like user ID and expiry), and signature (proof of authenticity). They are widely used in OAuth 2.0 and OpenID Connect flows.

No. A standard JWT is signed, not encrypted. The header and payload are only Base64URL-encoded, so anyone holding the token can read them — exactly what this tool does. Never put secrets in a JWT payload. Encryption is a separate spec called JWE.

What do the exp, iat and nbf claims mean?

They are Unix timestamps (seconds since 1970). exp is the expiry time, iat is when the token was issued, and nbf is the "not before" time the token becomes valid. This tool converts them to readable UTC dates and flags an expired exp in red.

What algorithm is in the JWT header?

The header alg field names the signing algorithm — commonly HS256 (HMAC with SHA-256, a shared secret) or RS256 (RSA with SHA-256, a public/private key pair). The typ field is usually JWT. This tool shows both.

Why does my token have only two dots and three parts?

That is correct — a JWT is header.payload.signature, so it has exactly two dots and three parts. If the signature segment is empty (alg "none"), the token may end with a trailing dot.

What is the JWT Decoder?

Free JWT decoder that splits any JSON Web Token into its header, payload, and signature. Timestamps (exp, iat, nbf) are decoded to human-readable UTC dates with expired-token warnings. Runs entirely in your browser — your token is never sent to any server. It runs free in your browser on Gera Tools, with nothing uploaded.

JWT Decoder — Gera Tools

Name: JWT Decoder
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

JWT decoder

This tool splits any JSON Web Token into its header, payload claims, and raw signature, decoding the readable parts so you can inspect exactly what a token contains. It’s for developers debugging auth flows, checking why a token is rejected, or confirming which claims and expiry an identity provider issued — all without a network request.

How it works

A JWT is three Base64URL-encoded segments joined by dots. The tool splits on ., then decodes the first two segments with a Base64URL-safe atob (it first swaps -/_ back to +// and restores padding), and runs JSON.parse on the result to show the header and payload as key-value pairs. The signature is shown raw. When “Decode timestamps” is on, numeric time claims (exp, iat, nbf, auth_time, updated_at) are read as Unix seconds and converted with new Date(value * 1000) to a readable UTC string. An exp earlier than the current time is highlighted in red as expired.

Example

The token below (HS256, demo only):

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjMiLCJleHAiOjE3MDAwMDAwMDB9.sig

decodes to a header of {"alg":"HS256","typ":"JWT"} and a payload of {"sub":"123","exp":1700000000}. With timestamps on, exp: 1700000000 shows as 2023-11-14 22:13:20 UTC and is flagged expired.

What the tool does and does not do

Action	Supported
Decode header (alg, typ)	Yes
Decode payload claims	Yes
Convert exp / iat / nbf to dates	Yes
Flag expired tokens	Yes
Verify the signature	No (needs the server-side secret/public key)

Decoding happens entirely in your browser, so this is safe to use with real tokens — your token never leaves your device.

Common debugging scenarios

“Why is this token being rejected?” Paste it in and turn on timestamp decoding. The most common reasons a token is rejected are: the exp has already passed (highlighted red), the iss or aud claim does not match what your server expects, or the alg in the header does not match what the verifier is configured to accept. Reading the header and payload directly shows you which of these applies before you dig into server logs.

“What claims does my identity provider issue?” Different providers — Auth0, Cognito, Azure AD, Okta, Keycloak — include different sets of claims in their tokens. Decoding a sample token quickly shows you the exact keys and values so you can write your application code against real data rather than documentation that may be out of date.

“Is this token encrypted or just signed?” A signed JWT (JWS) has a human-readable payload that base64url-decodes to JSON. An encrypted JWT (JWE) has five segments rather than three and the payload segment is ciphertext — it will not decode to readable JSON. If you paste a five-segment token and get garbled output, you have a JWE and need to decrypt it with the appropriate private key server-side first.

Reading the header

The header tells you two things: the algorithm (alg) used to sign the token, and the token type (typ, almost always JWT). It may also include a kid (key ID) that tells the verifier which key from the issuer’s JWKS endpoint to use for signature verification.

Common alg values:

Algorithm	Type	Description
`HS256`	Symmetric	HMAC with SHA-256; same secret to sign and verify
`RS256`	Asymmetric	RSA with SHA-256; private key signs, public key verifies
`ES256`	Asymmetric	ECDSA with P-256 and SHA-256
`none`	None	Unsigned; must never be accepted by a secure verifier

If you see alg: none, that is a significant red flag — it means the token is not signed at all. A secure server should reject it outright.

Privacy note

Because decoding is entirely local, this tool is safe to use with tokens from real environments during debugging. Your token bytes never leave your device. That said, avoid pasting tokens into any online tool you cannot inspect, as tokens from a production session grant access until they expire.