Toolypet
DEVELOPER TOOL

JWT Decoder

Decode JSON Web Tokens to inspect their header, payload, and signature. All processing happens locally in your browser for maximum security.

Token Structure

header.payload.signature
Decoded JWT sections will appear here...

JSON Web Tokens In Depth

Anatomy of a JWT

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.SflKxwRJSMeKKF2QT4fw

HEADER . PAYLOAD . SIGNATURE

A JWT consists of three Base64URL-encoded segments separated by dots. The header declares the signing algorithm (HS256, RS256, ES256). The payloadcontains claims — key-value pairs carrying data like user ID, roles, and expiration time. The signature is computed over the header and payload using a secret key, preventing tampering. Decoding reveals the first two parts; only the server with the key can verify the third.

Registered Claims and Timestamps

RFC 7519 defines seven registered claims. iss (issuer) identifies who created the token. sub (subject) identifies the user. aud (audience) specifies the intended recipient. exp(expiration) is a Unix timestamp after which the token must be rejected — a token with exp=1735689600 expires on January 1, 2025 at 00:00 UTC. iat (issued at) records creation time. nbf (not before) prevents early use. jti (JWT ID) provides a unique identifier for one-time-use tokens.

Signing Algorithms: HS256 vs RS256

HS256 (HMAC-SHA256) uses a single shared secret. Both the issuer and verifier need the same key. Simple and fast, but the secret must be securely distributed to every service that verifies tokens. RS256(RSA-SHA256) uses a public/private key pair. The issuer signs with the private key; any service can verify using the public key (published via JWKS endpoints). RS256 is the standard for OAuth 2.0 and OpenID Connect because it eliminates shared secrets. ES256 (ECDSA) offers the same asymmetric benefits with smaller keys — a 256-bit EC key provides security equivalent to a 3072-bit RSA key.

Common JWT Security Pitfalls

The “alg: none” attack:Some libraries accept tokens with the algorithm set to “none,” bypassing signature verification entirely. Always validate the algorithm server-side. Storing secrets in payloads: JWT payloads are Base64URL-encoded, not encrypted. Anyone with the token can read the claims. Never include passwords, credit card numbers, or PII. Long-lived tokens: A JWT with a 30-day expiration is a 30-day window of risk if stolen. Use short-lived access tokens (5-15 minutes) paired with refresh tokens for long sessions.

Frequently Asked Questions

Does this tool verify the JWT signature?

No. This tool only decodes and displays the header and payload. Signature verification requires the signing key (shared secret for HS256, public key for RS256/ES256), which should never be exposed to client-side tools. Always verify signatures on your backend before trusting any JWT claims.

How can I check if my token is expired?

Look for the “exp” claim in the decoded payload. It contains a Unix timestamp (seconds since January 1, 1970). Compare it to the current time: if exp < now, the token is expired. The “iat” (issued at) claim tells you when the token was created, and “nbf” (not before) indicates the earliest time it should be accepted.

Is it safe to paste production tokens into this tool?

Yes. All decoding happens entirely in your browser using JavaScript's atob() function. Your token never leaves your device — no network requests are made. This makes it safe for inspecting production tokens during debugging. However, be cautious about pasting tokens in shared screens or browser extensions that may capture clipboard data.