JWT Decoder & Encoder

A JSON Web Token (JWT, pronounced "jot") is a compact, URL-safe token format defined by RFC 7519. JWTs provide a standardized way to securely transmit information between parties as a JSON object. The information is digitally signed, so it can be verified and trusted by the recipient.

JWTs are the backbone of modern authentication and authorization systems. When you log into a web application, the server typically issues a JWT that your browser stores and sends with each subsequent request. The server can verify the token's signature without querying a database, making JWTs ideal for stateless, scalable architectures.

Unlike session cookies that require server-side storage, JWTs are self-contained — they carry all the necessary information within the token itself. This makes them popular for single sign-on (SSO), API authentication, microservice communication, and mobile app backends.

Every JWT consists of three parts separated by dots (.): the header, the payload, and the signature. Each part is Base64URL-encoded, making the token URL-safe and compact enough to include in HTTP headers, query parameters, or POST bodies.

Header

The header typically contains two fields: alg (the signing algorithm, such as HS256 or RS256) and typ (the token type, always "JWT"). The header is Base64URL-encoded to form the first segment of the token.

Payload

The payload contains the claims — statements about the user and additional metadata. Claims can be registered (standardized names like sub, exp, iat), public (custom names that should be collision-resistant), or private (agreed upon between parties). The payload is Base64URL-encoded but not encrypted — anyone with the token can read its contents.

Signature

The signature is created by taking the encoded header, the encoded payload, a secret key (for HMAC) or a private key (for RSA/ECDSA), and signing them with the algorithm specified in the header. The signature ensures that the token hasn't been tampered with. If any part of the header or payload changes, the signature will no longer match.

RFC 7519 defines a set of registered claim names that provide a common vocabulary for token metadata. While none are mandatory, using these standardized names ensures interoperability between different systems and libraries.

• Never store sensitive data in the payload — JWTs are encoded, not encrypted. Anyone with the token can read the payload. Avoid including passwords, credit card numbers, or other sensitive information.
• Always verify the signature — Before trusting any claim in a JWT, verify the signature using the appropriate key. Never use a JWT's claims without verification in a production system.
• Set short expiration times — Use the exp claim to limit token lifetime. Short-lived tokens (15 minutes to 1 hour) reduce the window of opportunity if a token is compromised. Use refresh tokens for longer sessions.
• Use strong secrets — For HMAC algorithms, use a secret key with at least 256 bits of entropy. Never use simple strings like "secret" or "password" in production.
• Validate the algorithm — Always validate the alg claim on the server side. Do not let the token dictate which algorithm to use for verification — this prevents algorithm-switching attacks.
• Use HTTPS — Always transmit JWTs over HTTPS to prevent token interception. A JWT intercepted in transit can be used by anyone until it expires.
• Consider the aud claim — Set and validate the audience claim to prevent tokens intended for one service from being accepted by another.

• Instant decoding — Paste any JWT and see the header, payload, and signature decoded in real time as you type. The token is parsed and formatted as JSON with syntax highlighting for easy reading.
• Claims inspector — Every claim in the payload is displayed in a structured table with human-readable descriptions. Timestamp claims (exp, iat, nbf) are automatically converted to local date/time with relative time indicators.
• Expiry detection — Tokens with an exp claim are automatically checked against the current time. A visual badge instantly shows whether the token is valid, expiring soon, or expired.
• Signature verification — Enter your HMAC secret key to verify the token's signature directly in the browser. Supports HS256, HS384, and HS512 algorithms using the Web Crypto API.
• Token generation — Build JWTs from scratch by editing the header and payload JSON, choosing an algorithm, and providing a secret key. Quick-add buttons for common claims (sub, iat, exp) speed up the process.
• Bearer prefix handling — Paste a token with or without the "Bearer " prefix — it's automatically stripped during decoding.
• 100% client-side — All decoding, encoding, and verification happens entirely in your browser. Your tokens and secrets are never transmitted to any server. The tool works offline after the initial page load.
• No dependencies — Built with vanilla HTML, CSS, and JavaScript. No frameworks, no build tools, no third-party libraries. Uses the browser's native Web Crypto API for cryptographic operations.