JWT Decoder - Decode JWT Online (Free, Private, Browser-Based)

Paste the token. The decoder splits it by dots, Base64URL-decodes the header and payload, and shows formatted JSON.

The decoder runs in your browser. Still, avoid pasting live production tokens unless you are comfortable with the environment.

No. It decodes and inspects the token. Signature verification requires the correct secret or public key.

A JWT parser reads the token parts and turns the encoded header and payload into readable JSON.

For access tokens, shorter is usually safer. Many production systems use lifetimes between 5 and 15 minutes, then rely on a refresh token or session flow to get a new access token. The right number depends on risk, user experience, and how quickly you can revoke compromised credentials. For admin panels, payments, or sensitive APIs, keep it short. For low-risk internal tools, you may allow a little longer. Do not make access tokens last for days unless you have a strong reason and a revocation strategy.

A JWT normally has three Base64URL-encoded parts separated by dots. The header describes the token type and signing algorithm. The payload contains claims, such as user ID, issuer, audience, and expiry time. The signature is created from the header and payload using a secret or private key, depending on the algorithm. Decoding the first two parts only reads the data; it does not prove the token is trusted. For security decisions, your server must verify the signature and validate important claims.

These are common registered JWT claims. iat means "issued at" and tells when the token was created. exp is the expiration time. nbf means "not before", so the token should not be accepted too early. sub is the subject, often the user ID. iss is the issuer, such as your auth server. aud is the audience, meaning who the token is intended for. A decoder can show these values, but your API should also validate them, especially exp, iss, and aud.

Decode the JWT payload and look for the exp claim. It is usually a Unix timestamp in seconds, not milliseconds. Convert it to your local time or UTC, then compare it with the current time. If exp is earlier than now, the token is expired and should not be accepted. Be careful with clock differences between servers; many systems allow a small clock skew, such as 30 to 60 seconds. Also remember that reading exp is not enough for security; verify the token signature too.

If a symmetric JWT secret is leaked, an attacker may be able to create fake tokens that your server will accept. Treat it like a password breach for your authentication system. Rotate the secret immediately, invalidate tokens signed with the old secret, review logs, and check whether any admin or customer data was accessed. For future safety, store secrets in a secure secret manager, restrict who can read them, and avoid putting them in frontend code, Git repositories, screenshots, or support tickets.

It depends on the tool and the token. Decoding a JWT only reveals the header and payload, and those parts are not encrypted by default. Still, payloads often contain user IDs, emails, roles, tenant IDs, or internal system names. On BulkCalculator, the JWT decoder is designed to run locally in the browser, which is better for privacy. Even so, avoid pasting live production tokens into any website unless you trust the environment. Never share tokens that still grant access to real systems.

Split the token by dots into header, payload, and signature. Take the first two parts, convert Base64URL to regular Base64 by replacing - with + and _ with /, add padding if needed, then Base64-decode and parse the result as JSON. That will let you read the header and claims. This does not verify the signature. For real authentication, use a trusted JWT library because verification includes algorithm checks, key handling, claim validation, clock skew, and security edge cases that are easy to get wrong manually.

Yes, for simple inspection you can decode the header and payload in JavaScript using atob after converting Base64URL characters. For Unicode-safe payloads, decode the bytes properly with TextDecoder rather than assuming plain ASCII. This is fine for debugging or showing token contents in a developer tool. It is not enough for login security. Browser-side decoding cannot safely prove a token is valid, because the server must verify the signature with the correct secret or public key and validate claims like exp and aud.

You can decode the payload part and parse it as JSON, which shows claims such as sub, email, roles, iss, aud, iat, and exp. This is useful for debugging, checking expiry, or understanding what an identity provider sent. But treat the result as untrusted until the signature is verified. Anyone can edit the payload and re-encode it. Your UI may read claims for display, but your backend should always verify the signature and important claims before granting access or making authorization decisions.

A decoder usually says invalid token when the string is not in the expected JWT shape: three dot-separated parts for a signed JWS token. Common causes include copying only part of the token, adding "Bearer " at the beginning, missing dots, broken Base64URL characters, line breaks, or extra spaces. Another cause is an encrypted JWT, which has a different structure and cannot be read like a normal signed token. Start by trimming spaces, removing the Bearer prefix, and confirming the token has the correct number of sections.