randarium
Tokens

Random JWT Generator

Create random JSON Web Token (JWT) strings with configurable algorithm, subject, and timestamps. These are synthetic test tokens shaped to parse correctly but are not cryptographically signed and must never be used for real authentication.

Also known as: jwt token · bearer token · auth token

seeded · synthetic data

Presets

iat unix seconds

Output

No output yet — set your options and hit .
About this tool, tips & examples

What it does

The Random JWT Generator creates structurally valid JSON Web Token strings — proper header.payload.signature shape with configurable algorithm declaration (HS256, RS256, or none), subject claim, issued-at timestamp, and random jti values. The tokens parse correctly in any JWT library but are not cryptographically signed: the signature segment is synthetic. Up to 1,000 per run, seeded.

Common use cases

  • Token parser fixtures — decoding, claim extraction, and display logic exercised with realistic tokens.
  • API testing — Authorization headers filled with token-shaped values for middleware that inspects-but-doesn’t-verify in test mode.
  • UI development — JWT debugger panes, session displays, and token-expiry indicators fed varied input.
  • Security testing — verify your backend rejects these (signature validation must fail) — arguably the most valuable use.

Settings

  • Algorithm — HS256, RS256, or none (the unsecured variant — presets for each).
  • Subject (sub) / Issued At (iat) — set the standard claims.
  • How many — 1 to 1,000 tokens, exportable as text, CSV, or JSON.
  • Seed — identical seed + settings = identical tokens.

Privacy note

Tokens are generated locally in your browser and never uploaded. They are nonfunctional dummy tokens — unsigned, granting nothing. Never use them for real authentication, and never configure a system to accept them.

FAQ

Will these pass JWT validation? They’ll decode (correct base64url structure and JSON) but fail signature verification — by design. A backend that accepts one has a critical bug; that’s a test worth running.

Why include the none algorithm? Because the historic alg: none attack still surfaces: libraries that honor it accept unsigned tokens. Generating them lets you prove yours doesn’t.

I need a real signed token for testing. Sign one in your test suite with a test key — signing requires a key, which is exactly why this tool doesn’t do it. For random secrets, see the Secure Token Generator.