A JWT is a compact token format used to pass identity and authorization data between systems. You can read the contents of any JWT without a secret key — decoding and verifying are two different operations.
What a JWT is
JWT stands for JSON Web Token. It is a standard (RFC 7519) for encoding claims — pieces of information about a user or session — in a compact, URL-safe string. APIs, OAuth flows, and single-sign-on systems use JWTs to pass identity data without requiring a server-side session lookup on every request.
The token travels as a plain string. It is designed to be read by anyone who holds it, which is why you should never put truly sensitive data — passwords, payment details — inside a JWT payload.
The three parts of a JWT
A JWT is three Base64URL-encoded strings joined by dots: header.payload.signature. Each part is independently decodable with any Base64 decoder, including the Base64 encoder/decoder.
The header names the algorithm used to sign the token — common values are HS256 (HMAC-SHA256) and RS256 (RSA-SHA256) — and the token type, which is always JWT.
The payload holds the claims: sub (subject — usually a user ID), iat (issued-at timestamp), exp (expiry timestamp), aud (intended audience), and any custom fields the application adds.
The signature is a cryptographic hash of the header and payload, created using the secret or private key. It cannot be decoded into a meaningful value — it exists only to be verified.
How to decode a JWT
Open the JWT decoder and paste your token into the input field. The tool splits the string on the two dot separators, Base64URL-decodes each segment, and pretty-prints the JSON. No key required.
If your token has extra whitespace or line breaks from copying out of a log file, paste it anyway — the decoder strips surrounding whitespace before processing.
For the raw JSON output, paste either the header or payload section directly into the JSON formatter to inspect nested structures with syntax highlighting.
Reading the standard claims
The iat and exp claims are Unix timestamps — seconds since 1970-01-01 00:00:00 UTC. A value like 1756000000 is not human-readable on its own. Paste it into a Unix timestamp converter to get the exact date and time.
sub is usually a user ID or account identifier. aud names the service the token is meant for — a server that receives a token with the wrong aud should reject it even if the signature is valid. Custom claims sit alongside these standard ones with whatever field names the issuing application chose.
What decoding does (and doesn't) verify
Decoding only reads the data. It does not check whether the signature is valid, whether the token has expired, or whether the issuer is trustworthy. A forged token decodes just as cleanly as a legitimate one.
Verification requires the secret (for HMAC algorithms) or the public key (for RSA/ECDSA). That check happens on your backend, not in a browser tool. Use a decoder to inspect what a token contains during debugging — never use it as a substitute for server-side signature verification.
Do not paste live production tokens containing user PII or active session credentials into any online tool. Use tokens from a staging environment or redact the payload before sharing.
Using JWT decoder in practice
The most common debugging scenario is checking whether a token has expired: decode it, read the exp claim, convert the Unix timestamp, and compare it to now. The second most common is confirming which claims your auth server is actually issuing — the decoder shows exactly what is in the token, not what your code assumes is there.
For teams working with Base64URL encoding outside of JWTs, the Base64 encoder/decoder handles the URL-safe variant. Use the JWT decoder when you need the full three-part split with labeled sections.