Free JWT Decoder Online — Verify & Inspect JWT Tokens

Frequently Asked Questions

• What's the difference between decoding and verifying a JWT?

  Decoding a JWT simply base64-decodes the three segments (header, payload, signature) so you can read the contents: no secret key is needed. Verifying a JWT cryptographically validates that the signature matches the header and payload, ensuring the token wasn't tampered with. Verification requires the correct secret (for HMAC algorithms like HS256) or public key (for RSA/ECDSA algorithms like RS256). You can decode any JWT without verifying it, but you should never trust a decoded token until you've verified its signature.

• Is it safe to decode a JWT? Will my secret key be exposed?

  Yes, it is safe to decode a JWT in a browser-only tool like this one. Decoding only reads the base64-encoded JSON: no secret key is involved, so nothing can be exposed. Your secret key is only required during verification, and this tool never sends your secret or token data to any server. Everything runs locally using the Web Crypto API. However, never paste a JWT containing sensitive data you wouldn't want visible on your screen, since the decoded payload is displayed in plain text.

• What's the difference between RS256 and HS256?

  RS256 is an asymmetric algorithm (RSA) that uses a private key to sign and a public key to verify: the public key can be shared freely. HS256 is a symmetric algorithm (HMAC) that uses the same shared secret for both signing and verification. RS256 is preferred for server-to-server communication because the signing key stays private and tokens can be verified by any service holding the public key. HS256 is simpler but requires every verifier to share the same secret, making key distribution a security risk.

• How do I check if a JWT has expired?

  Look at the exp (expiration time) claim in the decoded payload: it's a UNIX timestamp in seconds. Compare it to the current time; if the current UNIX timestamp exceeds the exp value, the token is expired. This tool automatically detects expiration and displays a visual timeline showing when the token was issued, when it becomes valid (nbf), and when it expires. If no exp claim is present, the token never expires, which this tool flags as a security concern.

• What's the difference between an access token and an ID token?

  An access token is used to authorize API requests: it tells a server what permissions the bearer has. An ID token (typically a JWT) authenticates the user's identity and contains claims like name, email, and profile information. Access tokens are opaque to clients and should not be read for user data; ID tokens are meant to be decoded client-side. In OAuth 2.0 and OpenID Connect flows, you typically receive both: the ID token proves who the user is, and the access token grants access to resources.

• Why am I getting an 'invalid signature' error?

  An 'invalid signature' error means the JWT's cryptographic signature doesn't match the one computed from the header and payload. This usually happens when you're using the wrong secret or public key for verification. For HMAC algorithms (HS256/HS384/HS512), ensure the secret string is exactly what the issuer used. For asymmetric algorithms (RS256/ES256), verify you're using the correct public key from the issuer's JWKS endpoint. It can also occur if the JWT was modified or truncated in transit, or if the signing algorithm in the header doesn't match the one used to produce the signature.

• Can I decode a JWT without the secret key?

  Yes, you can always decode a JWT without the secret key. JWTs are not encrypted by default: they are only signed. The header and payload are base64url-encoded, which is a reversible encoding, not encryption. Any base64 decoder can read them. The secret key is only needed to verify the signature, not to read the contents. This is by design: the payload is meant to be readable by any party that receives the token. If you need confidentiality, use JWE (JSON Web Encryption) or transmit tokens over a secure channel.

• What is a JWT token?

  A JWT (JSON Web Token) is a compact, self-contained credential: a signed JSON object encoded as three base64url strings separated by dots: header.payload.signature. The header identifies the signing algorithm, the payload carries claims (statements like who the user is and when the token expires), and the signature proves the token was issued by a trusted party and has not been modified. JWTs are used for stateless authentication: the server verifies the signature and reads the user's identity directly from the token, with no database lookup required. JWT is pronounced 'jot' and is defined in RFC 7519.

• What does JWT stand for? What is the JWT full form?

  JWT stands for JSON Web Token. The full form is defined in RFC 7519. JSON because the token's contents are a JSON object, Web because it is designed for HTTP-based exchange (typically the Authorization header or a cookie), and Token because it is a self-contained credential string. It is pronounced 'jot'.

• What is JWT authentication?

  JWT authentication is a stateless authentication pattern. After a user logs in, the server issues a signed JWT containing the user's identity (sub) and claims (role, permissions, iss, aud, exp). The client stores the token and attaches it to every subsequent request via the Authorization: Bearer header. The server verifies the signature (proving the token was issued by the trusted auth server and not modified) and validates the claims (exp not passed, iss matches, aud matches this service), then reads the user identity directly from the token: no database or session lookup required. This is stateless: any service instance can verify any token without shared session state, which is why JWT auth scales horizontally in microservice and API-first architectures.

• How do I generate a JWT secret?

  For HS256, generate at least 32 bytes of cryptographically random data: never a password, UUID, or memorable phrase. Use openssl rand -base64 32, crypto.randomBytes(32) in Node.js, secrets.token_urlsafe(32) in Python, or the dedicated JWT secret generator on /jwt-secret-generator/ which runs entirely in your browser via the Web Crypto API. A weak secret can be brute-forced offline with hashcat once an attacker obtains any valid token, so the secret's entropy is the single most important HS256 security control.

• What is the structure of a JWT?

  A JWT is three base64url-encoded strings joined by dots: header.payload.signature. The header (JOSE header) is a JSON object identifying the token type (typ: JWT) and the signing algorithm (alg: HS256, RS256, ES256, etc.), optionally with a key ID (kid) for key rotation. The payload is a JSON object of claims: registered claims like iss (issuer), sub (subject), aud (audience), exp (expiration), iat (issued at), and any custom claims your app needs. The signature is the cryptographic output of signing the base64url(header) + '.' + base64url(payload) with the chosen algorithm and key. Paste any token into the decoder above to see all three parts decoded live.

• Is this a free alternative to jwt.io?

  Yes. JWT Toolkit is a free, open-source alternative to jwt.io with one critical difference: every operation runs entirely in your browser using the Web Crypto API. Your token and secret never leave your machine: there are no server requests during decode or verify (the only network call is the optional JWKS public-key fetch you explicitly initiate). jwt.io sends tokens to its servers. If you ever paste a production token into an online tool, a browser-only tool like this one is the only safe choice. You can verify the zero-egress claim yourself by opening DevTools Network panel while using the tool.

• Can I use this to verify a JWT with a JWKS endpoint?

  Yes. JWKS (JSON Web Key Set) is the standard for publishing the public keys an issuer uses to sign JWTs, used by Auth0, Okta, AWS Cognito, Google, Microsoft Entra ID, and Firebase. In the verification section above, paste your token, pick the asymmetric algorithm (RS256, PS256, ES256, or EdDSA), and provide the issuer's JWKS URL. The tool fetches only the public keys (never your token) and verifies the signature against the key matching the token's kid header. The JWKS URL is stored in sessionStorage only: never localStorage or a URL fragment: and the fetch is the one network request the tool will make, which is why it requires your explicit action.