JWT Creator - Decoding Digital Anomalies

Start from a template:

Signing algorithm

Header JSON

Payload fields

Type into the fields below to set the standard claims. The raw JSON below stays in sync; advanced users can edit either view.

iss— Issuer

The principal that issued the JWT. Identifies who created and signed the token.

Type: StringExample: "https://auth.example.com"

sub— Subject

The principal that is the subject of the JWT. The "who" the token is about — usually a user id.

Type: StringExample: "user-1234"

aud— Audience

The recipient(s) the JWT is intended for. A consumer MUST reject a token whose audience does not include its own identifier.

Type: String or Array of StringsExample: "api.example.com"— Comma-separated

Watch out: The value may be a single string or an array of strings. Consumers must check every entry, not just the first.

jti— JWT ID

A unique identifier for the JWT. Can be used to prevent the token from being replayed (each token issued with a fresh jti).

Type: StringExample: "abc123def456"

name— Name

The full name of the user. A common OIDC profile claim, often included in ID tokens.

Type: StringExample: "Sample User"

email— Email

The user's email address. A common OIDC profile claim; consumers often treat this as verified only when paired with an `email_verified` claim.

Type: StringExample: "sample@example.com"

roles— Roles

Authorization roles assigned to the user. A common custom claim used for role-based access control; the exact shape is application-specific.

Type: Array of StringsExample: ["reader", "writer"]— Comma-separated

Payload JSON

Issued at (iat):

Not before (nbf):

Expires at (exp):

Shared secret (HS256/384/512)

About JWT Creation

A JSON Web Token (JWT) is three base64url segments — header, payload, and signature — separated by dots. This tool helps you build one from scratch: pick an algorithm, supply a key, and the resulting token is ready to copy.

For symmetric algorithms (HS256/384/512) the same secret signs and verifies. For asymmetric algorithms (RS*/ES*) the token is signed with a private key and verified with the matching public key.

JWTs are not encrypted — anyone with the token can read the header and payload. Confidentiality must come from transport security (TLS) or from an encrypted variant (JWE).

Comments

Please accept the "Functionality" cookie category to view and post comments.