Free JWT Decoder, Encoder & Verifier

A JSON Web Token (JWT) is a compact, URL-safe way to represent a set of claims between two parties. Defined by RFC 7519, JWTs are signed (and optionally encrypted) so receivers can verify the data hasn't been tampered with.

Modern web stacks use JWTs as session tokens, API access tokens, ID tokens (in OpenID Connect), one-time email verification links, password-reset links, webhook payloads, and inter-service authentication tokens. They're popular because they're self-contained — the server can validate a JWT without a database lookup.

A JWT is three Base64URL-encoded segments joined by dots:

HEADER.PAYLOAD.SIGNATURE

Each segment encodes a JSON object (or, for the signature, a cryptographic MAC/signature over the first two segments). The dots are literal — they aren't Base64-encoded and they aren't URL-escaped.

Header

Describes how the token was signed. Two fields are typical:alg(the signing algorithm, e.g. HS256, RS256, ES256) andtyp(almost always "JWT").

Payload

The actual claims about the user or session. The IANA registers seven standard short names (see the Registered Claim Names panel in the encoder), and you can add any custom keys you need — though smaller is better, since the entire payload travels on every request.

Signature

Computed over the first two segments using the secret (HMAC) or private key (RSA / ECDSA / EdDSA). Anyone with the matching secret or public key can verify the signature is intact — proving the token came from a trusted issuer and hasn't been modified in transit.

JWTs can be signed with several algorithm families. The encoder on this page supports all of them; the verifier accepts any you select. Pick based on your trust model and key distribution constraints.

HMAC (HS256, HS384, HS512)

Symmetric — the same shared secret signs and verifies. Simple to implement, but the secret must be distributed to every verifier, so it doesn't scale to multi-party setups. Choose HS256 unless you have a specific reason; HS384/HS512 increase signature size with marginal real-world benefit.

RSA (RS256, RS384, RS512)

Asymmetric. The issuer signs with a private key; verifiers only need the public key. RS256 is the de-facto standard for OIDC ID tokens. Recommended modulus size: 2048 bits or larger.

RSA-PSS (PS256, PS384, PS512)

RSA Probabilistic Signature Scheme — same key material as RS*, but with modern probabilistic padding (RSASSA-PSS) that provides stronger security guarantees. Use PS256 over RS256 when both sides support it.

ECDSA (ES256, ES384, ES512)

Elliptic curve signatures. Much smaller keys and signatures than RSA at equivalent security. ES256 (P-256 curve) is a popular default; ES384 and ES512 use larger curves (P-384, P-521).

EdDSA (Ed25519)

Modern, deterministic signatures with strong defaults and no footguns around random nonces. Ed25519 keys and signatures are both 32–64 bytes. The newest entry in the JWT spec.

Verifying a JWT means checking three independent things — and failing closed if any one of them is off:

1. The signature is intact. The verifier recomputes the signature over base64url(header).base64url(payload) using the expected key. If the result doesn't match the signature segment byte-for-byte, the token has been tampered with or signed by the wrong party.
2. Time-based claims are within tolerance. Reject the token if exp is in the past or nbf is in the future. Most production verifiers allow a few seconds of clock-skew tolerance — the Verify panel above has a configurable knob for this.
3. Identity claims match expectations. Pin the expected iss and aud values. A correctly-signed token aimed at a different audience is still a rejection.

Critically, always pin the expected algorithm at the verifier — never blindly trust the token's alg header. Historically, libraries that did so were vulnerable to tokens forged with alg: "none" or with HMAC algorithms substituted for RSA when only the public key was available to attackers.

1. Login. User submits credentials. The server verifies them and returns a signed JWT (often as an HttpOnly cookie or in the response body).
2. Subsequent requests. The client attaches the token — usually via the Authorization: Bearer <token> header.
3. Validation. The server checks the signature against its key, confirms exp hasn't passed, then trusts the claims.
4. Refresh (optional). Short-lived access tokens are paired with a longer-lived refresh token to mint new access tokens without re-prompting the user.

The exp claim is a Unix timestamp (seconds since 1970-01-01 UTC) marking when the token stops being valid. Once the current time passes exp, a compliant verifier rejects it.

Two related claims are nbf ("not before" — the token isn't valid until this time) and iat ("issued at" — the time of creation). All three are measured in seconds, not milliseconds — a common mistake when working with Date.now().

Typical lifetimes range from a few minutes (high-value access tokens) to a day or two (refresh tokens). Long-lived tokens increase the impact of any leak, so favour short access-token windows paired with refresh flows.

JWS (JSON Web Signature) tokens are signed— anyone can read the payload, but the signature proves it wasn't altered. This is what most apps mean when they say "JWT".

JWE (JSON Web Encryption) tokens are encrypted — the payload is opaque without the key. Use JWE when the claims themselves need to stay confidential, not just authenticated.

Treat the payload of a signed JWT as visible to anyone who holds the token. Don't put passwords, secrets, or sensitive personal data in there.

• Always validate the signature. Reject any token whose alg is none and never trust user-supplied algorithm names — pin the expected algorithm server-side.
• Use strong secrets. HS256 needs at least 256 bits of entropy; treat the secret like any other production credential.
• Verify standard claims. Check exp, nbf, iss, and aud every time. A correct signature on the wrong audience is still a rejection.
• Keep payloads small. Tokens travel on every request — large payloads cost bandwidth and can spill into cookie size limits.
• Store sensibly on the client. HttpOnly, Secure, SameSite cookies are the default for browsers. Avoid localStorage for high-value tokens.
• Rotate keys. Use the kid header to identify which key signed a token so you can roll keys without downtime.

• "invalid signature" — Most often caused by a secret/key mismatch between the signer and the verifier, or by accidentally re-encoding a base64url segment.
• "jwt expired" — Current server time is past the exp claim. Check server clock skew before assuming the token is wrong.
• "jwt malformed"— The token isn't three dot-separated base64url segments. Often a copy-paste mistake — extra spaces, line breaks, or quotes.
• "invalid algorithm"— The verifier was configured with an algorithm that doesn't match the token header. Always pin the expected algorithm.
• "audience invalid" — The aud claim doesn't include the verifier's expected audience string.

1. Paste the token into the decoder above to confirm the header and payload look right.
2. Inspect the alg and kid fields and compare them to what your verifier is configured for.
3. Check the timestamps — the human-readable values shown above make it obvious when exp has passed or nbf hasn't arrived.
4. Re-sign the same payload with the encoder and your dev secret to confirm the algorithm and key produce the expected signature.
5. If the verifier still rejects the token, log the verifier's full error message — most JWT libraries surface a precise reason (signature, exp, audience, issuer).