What Is a JWT?
A JWT is a compact, signed, Base64URL-encoded token defined in RFC 7519 used to represent claims between two parties. This JWT decoder, also called a JWT viewer or JSON Web Token decoder, lets you decode JWT token contents entirely in the browser. Paste a token to JWT decode online, with nothing installed and nothing sent to a server. JWTs are the standard bearer-token format for OAuth 2.0 and OpenID Connect, and show up constantly in API authentication headers as Authorization: Bearer <token>.
Header, Payload, and Signature, and Common Claims
A JWT has three parts, a header, a payload, and a signature, separated by dots as header.payload.signature, with each segment Base64URL-encoded per RFC 4648 §5. The header names the signing algorithm (alg) and token type (typ: JWT), and may carry a kid (key ID) for key rotation. The payload holds the claims. The signature is computed over the header and payload using the algorithm and a secret or private key, so any tampering with the first two segments invalidates it. RFC 7519 §4.1 defines a small set of registered jwt claims you'll see in almost every token, anything beyond these is a private/custom claim defined by the API you're working with.
| Claim | Meaning | Example |
|---|---|---|
| iss | Issuer, the party that created and signed the token | "iss": "https://auth.example.com" |
| sub | Subject, usually the user or entity ID | "sub": "user_8f2a1" |
| aud | Audience, the intended recipient of the token | "aud": "api.example.com" |
| exp | Expiration time (Unix timestamp, seconds) | "exp": 1735689600 |
| nbf | Not valid before (Unix timestamp) | "nbf": 1735686000 |
| iat | Issued at (Unix timestamp) | "iat": 1735686000 |
| jti | JWT ID, a unique identifier for this token | "jti": "a1b2c3d4" |
Signing Algorithm Families (HS vs RS vs PS vs ES), and JWT vs. Opaque Tokens
RS256 vs HS256 is the comparison developers hit most often: RS256 uses an asymmetric RSA key pair, while HS256 uses a single shared secret for both signing and verifying. The full alg value space is defined in RFC 7518 (JWA). This tool supports generating examples and verifying signatures across all four families below. Not every bearer token is a JWT, either: an opaque (reference) token is a random string that means nothing on its own, the server looks it up in a database to find the session, while a JWT carries its claims directly inside the token itself, so any party with the public key (or shared secret) can read and verify it without a database lookup. If a "JWT decoder" tool tells you a token is malformed, it may simply be an opaque token that only looks similar.
| Family | Type | Common use | Notes |
|---|---|---|---|
| HS256 / HS384 / HS512 | Symmetric (HMAC) | Single-service auth, simple setups | Same secret signs and verifies; it must stay private on both ends |
| RS256 / RS384 / RS512 | Asymmetric (RSA, PKCS#1 v1.5) | Multi-service / OIDC, public key distributed openly | Larger signatures, widely supported |
| PS256 / PS384 / PS512 | Asymmetric (RSA-PSS) | Same as RS, more modern padding (RFC 8017) | Recommended over RS by newer guidance |
| ES256 / ES384 / ES512 | Asymmetric (ECDSA) | Same as RS, smaller signatures | Requires curve-matched key generation |
Decoding vs. Verifying a JWT
As a JWT parser online, this tool separates two distinct operations. Decoding a JWT reads its contents; verifying a JWT proves those contents haven't been tampered with. Decoding just Base64URL-decodes the header and payload back into readable JSON, with no cryptography and no secret required. Verifying recomputes the signature using the secret or public key and confirms it matches. This tool supports both: decode any token instantly with no key, or use the JWT verify signature panel to check it against the HMAC secret or the issuer's public key.
| Decoding | Verifying | |
|---|---|---|
| Requires a secret/key? | No | Yes |
| Proves authenticity? | No | Yes |
| What it checks | Structural validity, reads claims | Cryptographic signature match |
| Typical use | Debugging, inspecting claims | Production auth middleware |
Common JWT Errors and What They Mean
Most JWT problems fall into a handful of categories. "Invalid JWT" / malformed token means the string you pasted doesn't have the three dot-separated Base64URL segments a JWT requires, or one of those segments isn't valid Base64URL, usually caused by copy-paste truncation, a leading "Bearer " prefix left in by mistake, or accidentally pasting something that isn't a JWT at all. A JWT expired warning appears when its exp claim, a Unix timestamp, is earlier than the current time; this tool flags expired tokens automatically so you don't have to convert the timestamp by hand, though clock skew between your machine and the issuing server can occasionally make a still-valid token look expired. alg: none means the token has no signature at all and should never be trusted, since some JWT libraries historically accepted it as a valid header, letting an attacker hand-craft a token with any claims they want, a real, exploited vulnerability class. A JWT algorithm confusion attack tricks a server into treating an RSA public key as an HMAC secret by changing the token's alg header from RS256 to HS256, documented as a named risk in the OWASP JSON Web Token Cheat Sheet and RFC 8725. This tool is for inspection and debugging, not a replacement for server-side auth logic: it doesn't revoke, refresh, or re-issue tokens, and your backend still needs to independently check exp, nbf, aud, and the expected algorithm on every request, treat this as a read-only window into a token's contents, not a security boundary.