A JWT decoder takes a JSON Web Token (the eyJ... string you see in auth headers) and reveals its three parts: the header, the payload, and the signature. JWTs are just Base64URL-encoded JSON joined by dots, so anyone holding the token can read it — decoding is not the same as verifying. Our free online JWT decoder runs locally in your browser: paste a token and instantly inspect the claims, check expiry, and see the signing algorithm. If the token arrives URL-encoded, our URL Encoder/Decoder can clean it first.
alg) and token type (typ), plus any key ID.sub, iss, aud, and exp.exp and iat to your clock and flags expired tokens.For raw token blobs, our Base64 Encoder/Decoder helps you inspect other encoded values in the same flow.
exp/iat/nbf to human dates and warns on expiry.Decoding only reveals contents; it does not prove the token is genuine. Verification needs the issuer's secret (HS256) or public key (RS256/ES256), which this tool never asks for. For a quick structural look during development, decoding is enough — for trust decisions, verify with your auth provider's SDK. If you handle hashed values, our Hash Generator can help you compare digests in the same investigation.
exp/nbf look wrong — check system time.Decoding happens entirely in your browser. The token is never sent to a server, logged, or cached, which makes this safe for production access tokens during debugging. Still, avoid pasting real customer secrets, and rotate any token you paste into a web tool afterward.
Engineers open this decoder the moment a 401 appears or an auth flow misbehaves. Paste the token, read the claims, and confirm expiry in seconds — no extension to install and no account to create. It turns an opaque eyJ... string into something a whole team can reason about during a debugging call.
When a token arrives inside a larger encoded blob, our Base64 Encoder/Decoder unpacks it first; when you are comparing digests during the same investigation, the Hash Generator helps verify values. Decoding is fully local, so you can inspect several tokens during an incident without exposing them to a server or leaving traces in someone else's logs.
A JWT has three Base64URL-encoded parts separated by dots: header, payload, and signature. The tool decodes the first two parts and parses them as JSON, then shows the claims. Decoding happens locally in your browser.
No. Decoding only reveals contents; verification needs the issuer secret (HS256) or public key (RS256/ES256), which this tool never requests. Verify with your auth provider's SDK or a JWKS endpoint.
No. All decoding runs in your browser. The token never leaves your device and is not stored or logged anywhere.
exp is the expiration time, iat is when the token was issued, and nbf is the not-before time. All are Unix timestamps the tool converts to readable dates and compares with your clock.
Usually clock skew between your machine and the auth server, or the app not enforcing exp. Compare exp with the current server time.
No. JWTs are encoded (Base64URL), not encrypted. Anyone with the token can read the payload, so never store passwords or secrets in claims.
Registered claims include iss (issuer), sub (subject), aud (audience), exp (expiry), nbf (not before), iat (issued at), and jti (token ID). The payload may also carry custom claims like roles or email.
Yes. ID tokens are standard JWTs. The tool shows the OpenID Connect claims such as sub, email, aud, and iss.
HS256 uses a shared symmetric secret for signing and verifying. RS256 uses an RSA key pair: the issuer signs with the private key and verifiers use the public key, so no shared secret is needed.
The tool reads the alg field from the decoded header and displays it (for example HS256, RS256, or ES256) so you know which key type verification requires.
Yes. It is free, runs in your browser, requires no signup, and adds no watermark to copied output.