JWT Encoder/Decoder

1. Decode: paste a compact JWT to inspect its header, payload, signature, recognized claims, and readable dates for supported time claims.
2. Verify: provide an HMAC-signed token and its secret. The tool checks the signature with the algorithm declared in the token.
3. Encode: edit the JSON header and payload, choose HS256, HS384, or HS512, enter a test secret, and generate a signed token.
4. Use the example token to explore the tool, copy results as needed, or clear the fields when finished.

JWT Encoder/Decoder

A JSON Web Token (JWT) is a compact token format commonly used to pass claims between systems. A compact token has three parts: header.payload.signature. This tool can decode a token, verify HMAC signatures, and generate signed tokens for development and testing. Token processing happens in your browser; the tool does not save the fields you enter.

The three parts of a JWT

The header contains token metadata, commonly the type and signing algorithm. The payload contains claims: information about the token or its subject. The signature is used to check that the encoded header and payload were signed with the expected secret and have not been changed. Header and payload data are Base64URL-encoded, not encrypted. Anyone with the token can generally decode them, so do not put passwords, API secrets, private keys, credentials, or sensitive personal information in a normal JWT payload.

Decode versus verify

Decoding answers what information is encoded in a token. Verification checks whether its HMAC signature matches the token data and the supplied secret. A token can be decoded even when its signature is invalid, its secret is unknown, its contents were altered, or it has expired. Readable does not mean trustworthy. Even a valid signature does not decide whether an application should authorize a user or accept a particular issuer, audience, role, or claim.

JWT claims and date values

Common registered claims include iss (issuer), sub (subject), aud (intended audience), exp (expiration), nbf (not-before time), iat (issued-at time), and jti (token identifier). The exp, nbf, and iat claims commonly contain Unix timestamps in seconds. The decoder presents supported numeric date claims as readable dates. The application that consumes the token remains responsible for interpreting and enforcing these claims.

Verify HMAC signatures

The verifier supports HS256, HS384, and HS512. These algorithms use HMAC with SHA-256, SHA-384, and SHA-512 respectively, together with a shared secret. The tool uses the algorithm declared in the token header and compares the calculated signature with the token’s signature. A successful result means the signature matches the supplied secret and token data. It does not establish authorization or validate every claim. RSA and ECDSA public/private-key verification, such as RS256 or ES256, is not supported.

Generate a signed JWT

In Encode mode, edit the JSON header and payload, select HS256, HS384, or HS512, and provide a secret to create a signed compact token. Use generated tokens and test secrets for development. Generating a signed JWT does not make its claims appropriate or secure for production.

Use JWTs carefully

Decoding is not verification, and verification is not authorization. Use test or development secrets for browser-based experimentation and avoid entering production credentials. JWT payloads are normally encoded rather than encrypted, so treat their contents as readable by anyone who obtains the token. Your application must separately validate claims and permissions before granting access.

Paste a compact JWT to inspect its header, payload, signature, registered claims, and readable dates for supported numeric date claims.

Check an HMAC signature using HS256, HS384, or HS512 and the secret used to sign the token. Verification checks the signature, not application permissions.

Edit the JSON header and payload, choose an HMAC algorithm, provide a secret, and create a signed token for testing.

Inspect claims such as iss, sub, aud, exp, nbf, iat, and jti. Remember that decoding does not verify authenticity and JWT payloads are not encrypted.