A JSON Web Token (JWT) is a compact, URL-safe token format used for authentication and data exchange. It consists of three parts: a header (algorithm), a payload (claims/data), and a signature — each Base64-encoded and separated by dots.

Does decoding a JWT verify its signature?

This tool decodes and displays the token contents but does not verify the signature without the secret key. To verify a JWT signature, you need the signing key. Decoding only shows what the token contains.

Is it safe to paste a JWT here?

Yes. Decoding happens entirely in your browser. Your token is never sent to any server. However, treat JWTs like passwords — do not share them in public or log them.

What is the difference between HS256 and RS256?

HS256 is a symmetric algorithm: the same shared secret is used to sign and verify, so the secret must never leave the server. RS256 is asymmetric: a private key signs and a public key verifies, so anyone can check a token's signature without access to the private key. RS256 and ES256 are the safer choice for APIs where many services need to verify tokens.

Why does my JWT show as expired even though I just received it?

The exp claim is a Unix timestamp in seconds, so check that your token was issued in seconds rather than milliseconds. Large clock skew between the issuing server and the checking client can also mark a token as expired early. If you created the token manually, verify that you encoded the exp value correctly as an integer.

Can someone read the data in my JWT without the key?

Yes. The header and payload are only base64url-encoded, not encrypted, so anyone who holds the token can decode and read them. Never put secrets, passwords, or sensitive personal data in a JWT payload. Signatures prove the token was issued by the holder of the key — they do not hide the contents.

🔑 JWT · Header · Payload · Expiry · Browser-Only

JWT Decoder

Paste any JSON Web Token to instantly decode the header, payload, and all claims. Check expiry, algorithm, and issuer at a glance.

Paste your JWT

↖ Paste a JWT token to decode it

🏗️ JWT Structure

A JWT has three Base64URL-encoded parts separated by dots: Header (algorithm & type), Payload (claims), and Signature (verification). This tool decodes all three.

⏱ Expiry Check

The exp claim is a Unix timestamp indicating when the token expires. This tool automatically compares it to current time and highlights expired tokens.

🔒 100% Private

Your JWTs are decoded entirely in your browser. Nothing is sent to any server. Safe to paste real tokens here — they never leave your device.

ection style="max-width:1000px;margin:0 auto 48px;">

JWT Security Best Practices

Decoding a token is easy; securing one is harder. These are the patterns that matter in production:

Prefer asymmetric algorithms (RS256, ES256). With HS256, every service that verifies a token also holds the secret that can forge one. Asymmetric keys let you rotate signing keys without touching verifiers, and you can publish the public key for anyone to verify.
Always verify the algorithm. Never trust the alg claim blindly — an attacker can change "alg":"RS256" to "alg":"HS256" and force your verifier to use the public key as an HMAC secret. Explicitly allowlist the algorithms your application accepts.
Validate aud, iss, and exp on every request. A token issued for service A must be rejected by service B. Check the audience, the issuer, and that the token is within its valid window (with a small leeway for clock skew).
Keep tokens short-lived. Access tokens of 15–30 minutes are standard. Use refresh tokens for long-lived sessions — they can be revoked when needed, unlike stateless JWTs.
Don't put secrets in the payload. The payload is readable by anyone with the token. Put sensitive data in an encrypted claim or reference it by ID.
Use the jti claim for revocation. Include a unique JWT ID in every token. Your verifier can check a revocation list (e.g., Redis set) by jti to invalidate tokens before expiry — essential for logout, password change, or breach response.

Common JWT Vulnerabilities

Attackers exploit JWT misconfigurations in predictable ways. If you're building or auditing an auth system, check for these:

alg: none attack. Some libraries accept "alg":"none" and skip signature verification entirely. The fix: reject any token with alg: none or an unexpected algorithm.
Algorithm confusion. As above — a token signed with RS256 can be forged under HS256 if the public key is used as the HMAC secret. Fix: hardcode the expected algorithm per key, don't read it from the token.
Weak HS256 secrets. Brute-forcing a short HMAC secret is feasible. Use at least 256 bits of entropy for HS256, and prefer RS256 to avoid the problem entirely.
Missing exp or excessive lifetime. Tokens without expiry (or with years-long expiry) are permanent bearer credentials. Fix: require exp and cap lifetime.
Substitution attacks. If a token from service A is accepted by service B because they share a key and don't check aud, an attacker moves laterally. Fix: unique keys or strict audience validation per service.

JWT Decoder — FAQ

Is it safe to paste my JWT here?

Yes — this tool operates entirely in your browser. Your token is never transmitted anywhere. That said, you should still treat JWTs as secrets: they grant access to whatever system issued them, so avoid pasting production tokens into any online tool when possible.

Can this tool verify the JWT signature?

No. Signature verification requires the secret key (for HMAC) or the public key (for RSA/EC), which you should never share. This tool decodes and displays the header and payload — the same data anyone with the token can see.

What do the standard JWT claims mean?

sub (subject) — who the token represents. iss (issuer) — who created the token. aud (audience) — intended recipient. exp — expiry timestamp. iat — issued-at timestamp. nbf — not-before timestamp (token invalid before this time).

What algorithms do JWTs support?

Common algorithms: HS256/HS384/HS512 (HMAC-SHA symmetric), RS256/RS384/RS512 (RSA asymmetric), ES256/ES384/ES512 (ECDSA). Always prefer asymmetric algorithms (RS256, ES256) in production — they allow public verification without exposing the signing key.

How to use the JWT Decoder

Copy the complete token. a JWT always has exactly three dot-separated parts: header, payload, and signature. Copy all three — pasting only the payload will not decode.
Paste it into the input box. The token is decoded instantly as you type. No submit button, no server round-trip, no waiting.
Check the header. The alg field tells you which signing algorithm (HS256, RS256, ES256…) was used, and typ confirms the token type. If the algorithm looks weak or unexpected, treat the token with suspicion.
Read the payload claims. The tool lists common claims such as iss (issuer), sub (subject), aud (audience), iat (issued at), and exp (expiry) with human-readable dates, plus any custom claims your application adds.
Verify the expiry status. The badge next to the token shows whether it is still valid, expires soon, or has already expired — useful before you paste a token into a request or write an integration test.
Copy what you need. Use the copy buttons to grab the header or payload as formatted JSON for logs, bug reports, or comparison between environments.

Decoding is not verifying

Every JWT is built from three base64url-encoded parts joined by dots. Base64url is a straightforward encoding, not encryption — it exists so binary data can travel safely in URLs and headers. That means anybody who gets hold of a token can decode its header and payload instantly. This decoder shows you exactly what the token says, which is usually what you need when debugging an API, inspecting a session, or auditing an authentication flow.

Decoding is not the same as verifying. The signature in the third part exists to prove the token was produced by whoever holds the signing key. To verify it you need the key: the shared secret for HS256, or the public key for RS256/ES256. Because you should never paste a signing secret anywhere, this tool intentionally stops at decoding. If a token arrives with a valid-looking payload but an algorithm like alg: none, or an algorithm mismatch, your application's verification code should reject it — a decoded payload alone is never proof of authenticity.

Two claims deserve special attention. exp (expiry) sets the Unix timestamp after which the token must be refused, and iat (issued at) records when it was created. The two most common integration bugs seen in the wild are expiring tokens in the wrong unit (milliseconds instead of seconds) and servers with clock skew rejecting fresh tokens. When debugging, compare the exp value shown here against the current time in the same unit, and remember that by design tokens cannot be revoked before they expire — keep exp short for sensitive access.