Cryptography Tools

Active tool: Cryptographic Tools

Selected option: JWT Encoder

What It Does

Creates and signs JSON Web Tokens (JWT) with configurable headers, payloads, and signing algorithms. A JWT is a compact, URL-safe token format used for authentication and information exchange between parties.

How to Use It

Choose an algorithm from the dropdown (e.g., HS256). The header’s alg field updates automatically.
Edit the payload JSON. Use the claim helper buttons to quickly insert standard claims like iat,exp, or jti with a single click.
Enter your signing secret or key. For HMAC algorithms (HS256/384/512), enter a shared secret. For RSA or ECDSA, paste the private key in PEM format.
Click “Generate Token”. The signed JWT appears in the output area.
Click “Copy” to copy the token, or use “Test in Decoder” to verify it immediately.

Options Explained

Option	Description
Algorithm	The signing algorithm. HS256/384/512 use a shared HMAC secret. RS256/384/512 use RSA key pairs. ES256/384/512 use Elliptic Curve key pairs. EdDSA uses Ed25519 keys.
Secret encoding	How the secret/key is interpreted: UTF-8 (plain text), Hex, or Base64.
Claim helpers	One-click buttons that insert standard JWT claims into the payload with sensible defaults.
TTL selector	Sets the `exp` (expiration) claim relative to now: 5 min, 15 min, 1 hour, 24 hours, etc.

Standard JWT Claims

Claim	Name	Purpose
`iss`	Issuer	Identifies who issued the token (e.g., your API domain).
`sub`	Subject	Identifies the principal (user ID, email, etc.) the token is about.
`aud`	Audience	Identifies the intended recipients. Verifiers should reject tokens with an unexpected audience.
`exp`	Expiration	Unix timestamp after which the token must be rejected. Use the TTL selector or the claim helper to set it.
`nbf`	Not Before	Unix timestamp before which the token must not be accepted. Useful for delayed activation.
`iat`	Issued At	Unix timestamp of when the token was created. Inserted automatically by the claim helper.
`jti`	JWT ID	A unique identifier for the token; prevents replay attacks when tracked server-side.

Choosing an Algorithm

Type	Algorithms	When to Use
HMAC (symmetric)	HS256, HS384, HS512	Both signer and verifier share the same secret. Simple to set up; ideal for internal services where both sides are trusted.
RSA (asymmetric)	RS256, RS384, RS512	Sign with a private key, verify with a public key. Best for systems where verifiers should not be able to create tokens.
ECDSA (asymmetric)	ES256, ES384, ES512	Same concept as RSA but with smaller keys and faster operations. Preferred for mobile and IoT.
EdDSA (asymmetric)	EdDSA (Ed25519)	Modern, high-performance signatures. Excellent security with compact keys.

Tip: Use the “Test in Decoder” button to immediately verify the token you just created. For production systems, prefer asymmetric algorithms (RS256, ES256) over shared-secret HMAC — this way verifiers never need access to the signing key.

Security: For HS256, the secret should be at least 256 bits (32 bytes) to match the hash output size. Short or predictable secrets can be brute-forced. Never embed secrets in client-side code.

Algorithm

Header (JSON)

Payload (JSON)

Add claim:

Secret formatSecret

Minimum 32 characters (256 bits) recommended for HMAC security.

Security note: Store secrets securely. Never commit secrets to version control. For production, consider using asymmetric algorithms (RS256, ES256).

About JWT Encoding

JSON Web Tokens (JWTs) are compact, URL-safe tokens defined by RFC 7519 for securely transmitting claims between two parties. Every JWT consists of three Base64URL-encoded parts separated by dots: header.payload.signature. The header declares the signing algorithm (e.g. HS256, RS256, ES256) and token type. The payload carries the claims — statements about the user and additional metadata such as expiration time. The signature is produced by signing the header and payload with a secret or private key, allowing recipients to verify the token's integrity.

Encoding a JWT means assembling these three parts and cryptographically signing them. HMAC algorithms (HS256/384/512) use a shared secret, while RSA and ECDSA algorithms use an asymmetric key pair — you sign with the private key and verify with the public key. Choosing the right algorithm depends on your trust model: shared-secret HMAC is simpler for single-service setups, whereas asymmetric algorithms are preferred when the verifier should not possess the signing key.

Keep in mind that JWTs are encoded, not encrypted. The payload is Base64URL-encoded and can be read by anyone who possesses the token. Never place sensitive data such as passwords or personal identifiers in the payload unless you also apply JWE (JSON Web Encryption). Always set reasonable expiration (exp) and “not before” (nbf) claims to limit a token's useful lifetime.

Common Use Cases

Authenticating users after login — the server issues a signed JWT that the client presents on subsequent requests
Authorizing API requests by including the JWT in the Authorization header as a Bearer token
Enabling single sign-on (SSO) across multiple services that share a verification key
Passing identity claims between microservices without additional database lookups
Generating short-lived tokens for email verification, password reset links, and invitation URLs

What Is a JSON Web Token (JWT)?

A JSON Web Token (JWT, pronounced “jot”) is an open standard (RFC 7519) for securely transmitting information between parties as a compact, self-contained JSON object. A JWT consists of three Base64URL-encoded parts separated by dots: header.payload.signature. The header identifies the signing algorithm (e.g., HS256, RS256), the payload contains claims (key-value pairs such as user ID, roles, and expiration time), and the signature ensures the token has not been tampered with. JWTs are stateless — the server does not need to store session data because all necessary information is embedded in the token itself.

Frequently Asked Questions

Is the JWT payload encrypted?

No. A standard signed JWT (JWS) only provides integrity and authenticity — anyone can decode the payload. If you need confidentiality, use JSON Web Encryption (JWE) or transmit JWTs over HTTPS only.

What is the difference between HS256 and RS256?

HS256 uses a shared secret (symmetric) for both signing and verification. RS256 uses an RSA key pair — the private key signs and the public key verifies. RS256 is preferred when the verifier should not be able to create tokens.

Should I store JWTs in localStorage or cookies?

HttpOnly, Secure, SameSite cookies are generally recommended because they are not accessible to JavaScript, reducing XSS risk. localStorage is simpler but vulnerable to XSS attacks.

Is my key sent to a server?

No. All signing runs locally in your browser. Your secret key and token are never transmitted or stored.

All encoding and signing runs entirely in your browser. No keys or tokens are sent to any server, ensuring your credentials remain private.