A JWT is a compact, URL-safe token format defined in RFC 7519 for representing claims (statements) between two parties. A JWT has three base64url-encoded parts separated by dots: header.payload.signature. The header describes the signing algorithm, the payload contains the claims, and the signature is computed over the header and payload.

JWTs are commonly used for authentication and authorization in web APIs: after a user logs in, the server issues a JWT that the client includes in subsequent requests (typically as a Bearer token in the Authorization header).

Because the payload is base64url-encoded (not encrypted), anyone with the token can read its contents. JWTs are signed, not encrypted — they guarantee integrity, not confidentiality.

No. JSONLab only decodes the header and payload — it does not verify the signature. Signature verification requires knowledge of the signing key (an HMAC secret for HS256, or a public key for RS256/ES256), which we never ask you to enter.

If you need to verify a signature, use a trusted library like jsonwebtoken (Node.js), pyjwt (Python), or jose (browser). Verification must always happen server-side, never in the client, because the verification key must remain secret.

Treat JSONLab as an inspector for debugging and learning — not as a security validator.

JSONLab is 100% browser-based, so your token never leaves your device. You can verify this in your browser's network panel — no requests are made after the initial page load. The token is decoded locally using atob and TextDecoder.

That said, JWTs often contain sensitive claims like user IDs, email addresses, roles, and session identifiers. Anyone with the token can read these claims. Treat JWTs as credentials and avoid sharing them in chat apps, screenshots, or support tickets.

If you need to share a JWT for debugging, redact sensitive claims first or use a token with synthetic data.

The exp (expiration time) claim specifies when the token stops being valid, as a Unix timestamp in seconds. After exp, APIs should reject the token and the user should re-authenticate to get a fresh one.

JSONLab shows a clear warning if the current time is past exp, with the exact expiration date and time displayed. This is useful for diagnosing why an API is suddenly returning 401 errors — the most common cause is an expired token.

Short-lived tokens (5–60 minutes) are a security best practice because they limit the window of opportunity if a token is leaked. Refresh tokens are typically used to obtain new access tokens without re-prompting the user for credentials.

HS256 (HMAC with SHA-256) uses a single shared secret to both sign and verify tokens. It's symmetric: whoever has the secret can both create and validate tokens. This makes HS256 unsuitable for distributed systems where multiple services need to verify tokens without being able to forge them.

RS256 (RSA Signature with SHA-256) uses a private RSA key to sign tokens and a public key to verify them. The private key stays with the issuer; the public key can be freely distributed. This is the more common choice in production because services can verify tokens without being able to mint new ones.

Other algorithms include ES256 (ECDSA, similar properties to RS256 but with smaller signatures) and none (no signature — should be rejected by all modern libraries). JSONLab displays the algorithm from the header so you can spot suspicious values.