Is my JWT token sent to a server?

No. The decoder runs entirely in your browser. The base64url decoding, JSON parsing, timestamp conversion, and optional signature verification all happen in JavaScript on your device. There is no network request. Verify this with your browser's DevTools Network tab. This matters because JWTs often contain authentication credentials, user identifiers, and role assignments.

Does decoding a JWT verify its signature?

No, not by default. Decoding reads the header and payload without checking the signature. Anyone can decode any JWT without the secret key. Signature verification requires the secret (HMAC) or public key (RSA/EC) and confirms the token was issued by a trusted party and was not modified. Enable the signature verification mode and paste your key to verify.

Is the payload inside a JWT encrypted?

No. The payload is base64url-encoded, which is an encoding scheme, not encryption. Anyone with the token can decode it and read the payload. For confidential claims, use JWE (JSON Web Encryption, RFC 7516) instead of JWT. Most standard JWTs (JWS, signed tokens) are readable by anyone who holds them.

What does \\\"exp\\\" mean and what happens when a JWT expires?

exp is the expiration time claim. It holds a Unix timestamp (seconds since 1970-01-01 00:00:00 UTC) after which the token is no longer valid. Your server should reject tokens where the current time is past the exp value. The decoder shows the exp value as a human-readable date and computes how much time is left or how long ago the token expired.

What is the difference between HS256 and RS256?

Both are signing algorithms. HS256 (HMAC-SHA256) uses a single shared secret: the same key signs and verifies tokens. RS256 (RSA-SHA256) uses a key pair: a private key signs tokens and a public key verifies them. RS256 is more common for multi-service architectures because you can share the public key widely without exposing signing capability. The algorithm is listed in the JWT header under alg.

Why do some JWTs have three parts and some seem to have more?

A standard JWT always has exactly three parts separated by dots: header, payload, signature. If you see a string with five parts (like xxxxx.xxxxx.xxxxx.xxxxx.xxxxx), it is a JWE (JSON Web Encryption) token, not a standard signed JWT. JWE has a different structure. The current tool decodes signed JWTs (JWS) only.

JWT Decoder

This tool decodes JSON Web Tokens (JWTs) directly in your browser. Paste a JWT and the tool splits it into its three parts, base64url-decodes the header and payload, and displays the claims in a readable JSON format with human-readable timestamps. No token data is sent to a server. Your authentication tokens, API keys, and session credentials stay on your device. The tool is free, requires no account, and works offline after the page loads.

Decoded client-side only. Your token is never sent to any server.

CountryJWT tokenSecret (optional, for HMAC verify)Show raw base64 segments

Paste a JWT token.

RSA and ECDSA verification require a public key and are not supported yet.

How this tool works

The JWT decoder splits a JSON Web Token into its three dot-separated components (header, payload, and signature) and base64url-decodes the first two into readable JSON. JWTs are signed, not encrypted by default; anyone with the token can read the header and payload without any key. The header identifies the signing algorithm (HS256, RS256, ES256, etc.). The payload contains the claims: registered claims like iss (issuer), sub (subject), exp (expiration as a Unix timestamp), and iat (issued-at), plus any custom application claims. The tool converts exp and iat Unix timestamps to human-readable UTC dates and flags expired tokens by comparing exp to the current time. The signature is displayed as-is and labeled with whether the algorithm is symmetric (HMAC, where both signing and verification require the shared secret) or asymmetric (RSA/ECDSA, where verification uses the public key). Key assumption: the tool accepts only the standard three-part dot-separated JWS format; JWE (JSON Web Encryption) tokens have five parts and cannot be decoded without the private key. Edge case: tokens with no exp claim never expire and represent a security risk in production systems. The tool flags a missing exp field as a warning so you can identify tokens issued with unbounded lifetimes.

Worked example

An API returns 401 and you suspect an expired access token. Paste the JWT, check the expiry badge, and read exp in the claim list before you refresh the token.

Frequently asked questions

Is my JWT token sent to a server?
No. The decoder runs entirely in your browser. The base64url decoding, JSON parsing, timestamp conversion, and optional signature verification all happen in JavaScript on your device. There is no network request. Verify this with your browser's DevTools Network tab. This matters because JWTs often contain authentication credentials, user identifiers, and role assignments.
Does decoding a JWT verify its signature?
No, not by default. Decoding reads the header and payload without checking the signature. Anyone can decode any JWT without the secret key. Signature verification requires the secret (HMAC) or public key (RSA/EC) and confirms the token was issued by a trusted party and was not modified. Enable the signature verification mode and paste your key to verify.
Is the payload inside a JWT encrypted?
No. The payload is base64url-encoded, which is an encoding scheme, not encryption. Anyone with the token can decode it and read the payload. For confidential claims, use JWE (JSON Web Encryption, RFC 7516) instead of JWT. Most standard JWTs (JWS, signed tokens) are readable by anyone who holds them.
What does \\\"exp\\\" mean and what happens when a JWT expires?
exp is the expiration time claim. It holds a Unix timestamp (seconds since 1970-01-01 00:00:00 UTC) after which the token is no longer valid. Your server should reject tokens where the current time is past the exp value. The decoder shows the exp value as a human-readable date and computes how much time is left or how long ago the token expired.
What is the difference between HS256 and RS256?
Both are signing algorithms. HS256 (HMAC-SHA256) uses a single shared secret: the same key signs and verifies tokens. RS256 (RSA-SHA256) uses a key pair: a private key signs tokens and a public key verifies them. RS256 is more common for multi-service architectures because you can share the public key widely without exposing signing capability. The algorithm is listed in the JWT header under alg.
Why do some JWTs have three parts and some seem to have more?
A standard JWT always has exactly three parts separated by dots: header, payload, signature. If you see a string with five parts (like xxxxx.xxxxx.xxxxx.xxxxx.xxxxx), it is a JWE (JSON Web Encryption) token, not a standard signed JWT. JWE has a different structure. The current tool decodes signed JWTs (JWS) only.