JWT Claim Builder & Payload Generator (RFC 7519 Standards)

JWT Claim Builder & Payload Generator (RFC 7519 Standards)

Design RFC 7519 registered and custom JWT claims with timestamp calculators for exp, nbf, iat, jti, and audience tags.

Presets label
Registered claims
7 / 7 configured
StringOrURI
Principal ID
Target APIs / Clients
https://api.toolsaa.com/v1https://billing.toolsaa.com
In 1h
Quick Lifespan:
Custom claims
Templates:
7 RFC•2 Custom
14 Lines•305 Bytes
{
  "iss": "https://auth.toolsaa.com",
  "sub": "usr_89f72b10",
  "aud": [
    "https://api.toolsaa.com/v1",
    "https://billing.toolsaa.com"
  ],
  "exp": 1792173872,
  "nbf": 1792170272,
  "iat": 1792170272,
  "jti": "f81d4fae-7dec-11d0-a765-00a0c91e6bf6",
  "scope": "read:profile write:workspace admin:billing",
  "client_id": "spa_client_prod_442"
}
RFC 7519 Ready
Base64: 407 chars
Stat status
7 / 7 Claims

Standard iss, sub, aud, exp, nbf, iat, jti validation

Stat lifespan
In 1h

Second-level Unix epoch precision

Stat payload size
305 Bytes

~3.7% of 8KB HTTP header buffer

Client-Side Processing

High-performance processing executed entirely in browser memory.

Zero Server Upload Privacy

All data payloads remain strictly local with zero external server communication.

Production Ready Export

Clean, optimized output formats ready for immediate deployment.

Technical Reference & Architecture Guide

JWT Claim Builder & Payload Generator (RFC 7519 Standards) Developer Guide — Reference Guide

Design RFC 7519 registered and custom JWT claims with timestamp calculators for exp, nbf, iat, jti, and audience tags.

Key Parameters & Controls

iss (Issuer)string

Identifies the principal that issued the JWT. Usually a domain URI or an authorization service identifier.

Default: https://auth.example.com
sub (Subject)string

Identifies the principal that is the subject of the JWT (e.g., user UUID, service account ID). Must be locally or globally unique.

Default: usr_94b3a8c1-5e2b
aud (Audience)string | string[]

Identifies the recipients that the JWT is intended for. The resource server processing the token MUST verify this claim matches its own identifier.

Default: https://api.example.com/v1
exp (Expiration Time)integer (Unix timestamp)

Identifies the expiration time on or after which the JWT MUST NOT be accepted for processing. Measured in seconds since Unix epoch (RFC 7519 NumericDate).

Default: 1776435600
jti (JWT ID)string

Provides a unique identifier for the JWT. Used to prevent token replay attacks and support one-time token revocation blacklists.

Default: b9c8d6e4-4a2f-48d1-912b-3e5f7a1c8d9e

Pro Tips & Best Practices

Unix Seconds vs Milliseconds Pitfall

RFC 7519 explicitly mandates NumericDate in seconds since the epoch. Never pass JavaScript 'Date.now()' directly without dividing by 1000; passing milliseconds causes the token to be valid for tens of thousands of years or fails immediate verification in libraries like jsonwebtoken and jose.

Minimize Header & Cookie Bloat

JWTs are transferred in the HTTP Authorization header or session cookies with every request. Keep claims lean and omit sensitive PII, large authorization matrixes, or deep nested profile objects to avoid exceeding the 8KB header limit enforced by reverse proxies like Nginx and Cloudflare.

Configure Clock Skew Leeway on Verifiers

Distributed nodes often experience microsecond-to-second clock drift via NTP. When verifying 'exp' and 'nbf', always configure a 30 to 120-second clock tolerance leeway (e.g., 'clockTolerance: 60') in your verifier middleware to prevent false rejection spikes during token rotation.

Common Gotchas & Troubleshooting

Verification rejects token instantly with 'TokenExpiredError' or 'jwt expired'

Check if the 'exp' claim was encoded as milliseconds instead of seconds, or if the server clock has drifted. Verify that 'Math.floor(Date.now() / 1000) + ttl' was used during payload generation, and enable 60 seconds of clock skew leeway on your backend verifier.

Token signature passes but API returns 'jwt audience invalid' (401/403)

The resource server expects its exact client ID or base API URI in the 'aud' claim. Ensure the claim matches identically, or configure 'aud' as an array of valid target audiences if multiple microservices consume the same payload.

Frequently Asked Questions

What is the difference between Registered, Public, and Private claims in RFC 7519?▼

Registered claims (iss, sub, aud, exp, nbf, iat, jti) are predefined by IANA/RFC 7519 for standard security guarantees. Public claims are collision-resistant names registered in the IANA JWT registry or defined via unique URI namespaces. Private claims are agreed upon between producers and consumers (e.g., 'role', 'tenant_id') for application-specific authorization.

Why does RFC 7519 NumericDate use seconds instead of milliseconds?▼

The standard specifies seconds since 1970-01-01T00:00:00Z to align with POSIX standard time representation and keep JSON payload sizes compact. Modern microservices must parse timestamp claims as 32-bit/64-bit integer epoch seconds.

Can I store sensitive credentials or passwords in a JWT payload?▼

No. Standard JWS (JSON Web Signature) tokens are merely Base64URL-encoded and cryptographically signed, not encrypted. Any client or intermediary can decode and inspect payload claims. If confidential data must be included, you must use JWE (JSON Web Encryption, RFC 7516).

How does the 'jti' (JWT ID) claim protect against replay attacks?▼

The 'jti' assigns a cryptographically unique identifier (such as a UUIDv4) to each token. When a refresh token or one-time authorization code is exchanged, the server can record the jti in a fast cache (e.g., Redis) until its 'exp' time. If an identical jti is presented again, it is immediately rejected as a replay attempt.

Related Tools & Utilities

All Tools →
WireGuard Key Pair & Peer Configuration Generatorsecurity

Generate WireGuard Curve25519 public and private key pairs, preshared keys (PSK), and client/server configuration blocks.

Open tool→
Apache & Nginx htpasswd Generator (Bcrypt, APR1-MD5, SHA-1)security

Generate secure HTTP Basic Authentication passwords and .htpasswd entries with Bcrypt, Apache MD5 (APR1), and SHA-1 hashing.

Open tool→
JWT Token Decoder & Security Inspectorsecurity

Decode JSON Web Tokens, inspect header/payload claims, calculate expiration time and verify integrity locally.

Open tool→
Cryptographically Secure Password Generatorsecurity

Generate ultra-secure passwords using Web Crypto API with custom length, symbols, and memorability.

Open tool→
Multi-Algorithm Hash Generator (SHA-256, SHA-512, MD5)security

Compute instant cryptographic hashes entirely in browser with zero server transmission.

Open tool→
JSON Web Token (JWT) Debugger & Signature Verifiersecurity

Decode, verify, and inspect JWT headers, payloads, and claims with local secret or public key without sending data to servers.

Open tool→