JWT validator, verifier and decoder

Paste a JSON Web Token to inspect its header and payload locally, validate its structure, then verify HMAC signatures when you have the secret.

Verification status

Paste a token and secret to verify.

Decoding only reveals claims. Trust the token only after a valid signature and expiration check.

Header


          

Payload


          

JWT structure at a glance

JSON Web Tokens package authentication claims into a compact string separated by dots. Each segment is Base64URL encoded, which is why you can decode the header and payload without hitting external services.

Segment Contains Example claims Security notes
Header Algorithm (`alg`) and token type (`typ`). {"alg":"HS256","typ":"JWT"} Never accept "alg":"none" in production.
Payload Claims about the subject, issuer, scopes. {"sub":"123","exp":1700000000} Visible to anyone with the token. Do not store secrets here.
Signature HMAC or asymmetric signature over header+payload. HMACSHA256(base64Url(header).base64Url(payload), secret) Required to verify authenticity. Use the verifier above for HMAC-signed tokens.

Best practices when working with JWTs

Decoding claims is only the first step. Use these guidelines to keep tokens safe and your APIs predictable.

Always verify signatures

Decode to inspect, but never trust claims until you validate the signature with the issuer's secret or public key.

Enforce expiry and audiences

Reject expired tokens and ensure aud/iss claims match your application to prevent replay across services.

Avoid sensitive claims

Anyone who obtains the JWT can read payload data. Store secrets server-side or encrypt the token with JWE when necessary.

What a valid JWT signature does and does not prove

Decode inspects public header and payload fields. Verify checks an HMAC signature only when you supply the matching secret.

  1. Use a development token signed with HS256, HS384 or HS512 and its test secret.
  2. Verify it, then change one payload character. Verification must fail.
  3. Check expiry, issuer, audience and application permissions in the receiving application.

A valid signature does not by itself authorize a request. RS256, ES256 and encrypted JWE are outside this verifier. Never treat decoded claims as trusted before verification.

JWT specification: RFC 7519

JWT decoder FAQ

What are the three parts of a JWT?

A JWT contains a header, payload, and signature separated by dots. The header defines the algorithm, the payload carries claims, and the signature proves authenticity when verified with the correct key.

Does decoding a JWT verify its authenticity?

No. Decoding only reveals the Base64URL-encoded JSON. Use the verifier with the issuer secret before you trust any claim in the payload.

What risks exist when handling JWTs?

Tokens can leak sensitive information and be replayed if you skip expiration or revocation checks. Avoid logging JWTs and refuse tokens signed with weak secrets or the none algorithm.

Can I decode encrypted JWTs (JWEs) with this tool?

No. The decoder targets signed JWTs (JWS). Encrypted JWEs require the decryption key and algorithms that are outside the scope of this page.

Does the decoder upload my tokens?

No. HashyTools processes JWTs entirely on your device so your secrets and claims remain private.

Choose a developer tool

More tools for data, text and testing

Run the AES interoperability guide or read how these tools are checked.