JWT explorer / creator

What is inside a JWT?

A JSON Web Token carries claims in a compact format. This tool explores the common signed, three-part form: header.payload.signature. It can help you debug a test integration, read an expiration date, or learn how a changed payload affects a signature.

1 · Header

A Base64URL-encoded JSON object describing the token. The alg field declares an algorithm; typ often says JWT. These values are untrusted input, not instructions to select a verification algorithm.

2 · Payload

A Base64URL-encoded JSON object containing claims such as a subject, audience, or expiration time. Encoding is reversible. A signed payload is readable and must not contain passwords or other confidential data.

3 · Signature

Cryptographic protection for the exact encoded header and payload. With HS256, an HMAC is computed using a shared secret and SHA-256. Changing either encoded part should make a signature check fail.

How to decode and check a JWT

1. Paste a three-part token in Explore, or choose a synthetic demo. Header and payload JSON appear as you type, alongside UTC timestamp observations.
2. Treat everything decoded as untrusted. For an HS256 token, supply the expected shared key and select Check signature. The verification policy is fixed to HS256 independently of the header.
3. A matching signature shows only that this token matches the supplied key. A recipient must also trust the key and issuer, enforce the intended audience, check time limits, and apply authorization and replay rules.

For example, load Tampered payload and use the public demo key. The JSON still decodes, but the signature check fails. An Expired demo can have a matching signature while its expiration observation says it has expired. These are separate checks.

How to create an HS256 token

Choose Create HS256, enter a JSON object as the payload, and supply a strong random shared key of at least 32 UTF-8 bytes. You can generate a random key locally or use the public demo key for learning. Load demo claims adds synthetic claims with timestamps relative to your device clock. Create the token, then copy it or explore its parts. The header algorithm is fixed; unsigned alg:none tokens cannot be created or accepted for verification.

The key field uses literal UTF-8 text, including spaces. A key that looks like Base64 is still treated as text; this tool does not silently decode it into different key bytes. Key length alone cannot establish sufficient randomness.

Registered JWT claims

These standard names are optional at the JWT format level; a particular application can require them. Custom claims such as name or role get their meaning from the application. Reading a role does not grant that role.

iss Issuer

Who issued the token.

sub Subject

Who or what the token describes.

aud Audience

The intended recipient or recipients.

exp Expiration

Must not be accepted at or after this time.

nbf Not before

Must not be accepted before this time.

iat Issued at

When the token was issued; not an expiry rule.

jti JWT ID

An identifier that can help a recipient prevent replay.

exp, nbf, and iat use NumericDate: seconds since the Unix epoch, not JavaScript milliseconds. For example, 1700000000 is 2023-11-14 22:13:20 UTC. At the exact exp time the token is expired; at the exact nbf time its not-before limit is reached. This explorer uses your device clock without clock-skew leeway. A future iat is reported as an observation, not treated as a not-before rule.

Common JWT errors and supported formats

• Wrong number of parts: signed compact JWTs have three parts. Five-part encrypted JWE tokens and nested-token decryption are outside this tool’s scope.
• Malformed encoding or JSON: JWT parts use unpadded Base64URL with - and _. Internal spaces, = padding, non-canonical padding bits, invalid UTF-8, duplicate JSON names, and non-object claims are rejected. Outer whitespace is ignored. Complete Unicode characters are supported.
• Unsupported signature policy: RS256, ES256, and other algorithms can be inspected but are not verified here. alg:none, critical header extensions, and b64 overrides are never accepted by the HS256 verifier. Header key references are not fetched.
• No signature match: use the correct key bytes and check whether the encoded header, payload, or signature changed. A successful decode says nothing about authenticity.
• Browser limits: input is limited to 65,536 characters and JSON to 64 nesting levels. Signing and signature checks require Web Crypto over HTTPS or localhost.

Local processing and privacy

Decoding, key generation, signing, and signature verification run in this page. Tokens and signing keys are not sent to a server, analytics, logs, a URL, or persistent browser storage. Copy buttons write the chosen output to your clipboard, which your device or clipboard manager may retain. Clearing the tool or leaving the page clears its input state; the public demo key and all demo identities are synthetic.

Read the JWT specification, HS256 algorithm requirements, and JWT algorithm-verification guidance for the underlying format and security rules.

Related browser tools

• URL encode / decode — Encode text for URLs and decode percent-encoded strings.
• UUID generator / validator — Generate random UUIDs and check their format and version.
• Base64 encode / decode — Encode UTF-8 text as Base64 or Base64URL and decode it back.

Browse all tools.