Question 1

What's the difference between `Math.random()` and `crypto.getRandomValues()`?

Accepted Answer

**`Math.random()`** is a pseudo-random number generator seeded from system state. It's fine for visual effects, game logic, and load distribution. It is **not** safe for security tokens, the output is predictable enough that an attacker who observes a few values can predict future ones (and the seed is sometimes guessable). **`crypto.getRandomValues()`** uses the OS's cryptographically-secure random source (CryptoAPI on Windows, `/dev/urandom` on Unix-likes). Output is computationally indistinguishable from true random. **Rule**: anything that protects a secret, session IDs, API keys, password reset tokens, CSRF tokens, OAuth state, nonces, IVs, must use `crypto.getRandomValues()` or equivalent (`crypto.randomBytes` in Node, `secrets` module in Python). This tool only uses the secure source.

Question 2

How long should a token be?

Accepted Answer

**Bits of entropy** matters, not characters. **128 bits is the modern minimum** for tokens that need to be unguessable (session IDs, CSRF tokens). **256 bits** for high-value secrets (encryption keys, long-lived API keys). **Character count depends on charset**: hex (16 chars per 64 bits → 32 hex chars = 128 bits); base64url (4 chars per 24 bits → ~22 chars = 128 bits); alphanumeric (62 chars, ~5.95 bits each → 22 chars ≈ 130 bits). **Don't go shorter than 22 chars** for any security-sensitive token. **Length doesn't equal security** if randomness is weak, a 1000-char token from `Math.random()` is still weak; a 22-char token from `crypto.getRandomValues()` is strong.

Question 3

Which charset should I use, hex, base64url, alphanumeric?

Accepted Answer

**hex** (`0-9a-f`): universal, case-insensitive, no special characters. Twice as long as base64url for the same entropy. Use for: anywhere case-sensitivity might break (URLs in case-insensitive systems, log analysis tools that downcase). **base64url** (`A-Za-z0-9-_`): URL-safe (no `+`, `/`, `=`), 33% shorter than hex, case-sensitive. Use for: web tokens, URL parameters, headers. **alphanumeric** (`A-Za-z0-9`): no special characters at all, can be typed manually if needed. Use for: human-readable codes, password reset codes (slightly less dense than base64url). **numeric** (`0-9`): for OTP/SMS codes (typically 6 digits = ~20 bits, fine when also rate-limited). Use for: 2FA-style numeric codes. **base32** (Crockford or RFC 4648): looks like base64 but ASCII-safe, no ambiguous characters (0/O, 1/l). Use for: human-spoken codes.

Question 4

Why do real APIs use prefixes like `sk_live_` or `ghp_`?

Accepted Answer

**Prefixes serve three purposes**. **(1) Type identification at a glance**, `sk_` = secret key, `pk_` = publishable (public-ok), `live` vs `test`. Devs and security tools can immediately tell what kind of credential leaked. **(2) Secret scanning**, GitHub, GitLab, and AWS all run scanners on every commit looking for prefixed tokens (`AKIA...` AWS, `ghp_...` GitHub PAT, `sk_live_...` Stripe). When found, they alert the issuing service which can revoke automatically. The prefix is what makes the scanner work, random hex has too many false positives. **(3) Disambiguation**, distinguishes from random IDs. **For your own service**: pick a unique 3-5 char prefix; use distinct prefixes for live/test, secret/public, and different scopes. Make scanning easy. Examples: Stripe (`sk_live_`, `pk_test_`), GitHub (`ghp_`, `ghs_`, `gho_`), Twilio (`SK`, `AC`).

Question 5

How should I store the tokens I generate, hash them in the database?

Accepted Answer

**Yes, for tokens that authenticate users or grant API access, store a hash, not the plaintext.** Reason: if your database is breached, the attacker shouldn't get usable tokens. **For long random tokens** (≥128 bits entropy), a fast hash like SHA-256 is enough, no need for bcrypt/argon2 because the input space is already huge. **For short codes** (6-digit OTPPs), use bcrypt/argon2 because brute force on short codes is fast otherwise, but better: use TOTP (rotating codes) instead of long-lived short codes. **At creation**, show the token to the user ONCE; never display again. **For lookup performance**, store the prefix as plaintext (indexed) and the rest as hash. **For revocation**, just delete the row. Never email tokens; show them in the UI, recommend immediate copy.

Question 6

Is my generated token sent anywhere?

Accepted Answer

No. The token is generated entirely in your browser via `crypto.getRandomValues()`, a synchronous, local-only API. There's no server roundtrip. Open DevTools Network during use: zero outbound requests when generating tokens. **This is essential for the use case**: if the generator sent the token anywhere, the recipient would know the secret you were about to use, defeating the purpose. The whole point of a client-side token generator is local-only randomness, copy the token, paste into your service, never see it again.

Question 7

What standards does Token/Secret Generator validate against?

Accepted Answer

Token/Secret Generator checks compliance with RFC 4122/9562 (UUID), RFC 7519 (JWT).

Question 8

What are the limitations of Token/Secret Generator?

Accepted Answer

UUID generation uses crypto.getRandomValues, not suitable for distributed systems without coordination JWT generation is unsigned, no signature support Token entropy depends on browser CSPRNG

Charset	Bits/Char	Standard Length	Total Entropy
Hex (0-9a-f)	4.00	32 chars	128 bits
Base64URL	6.00	22 chars	132 bits
Alphanumeric	5.95	32 chars	~190 bits
Numeric (0-9)	3.32	6 digits	~20 bits

Token/Secret Generator

What is Token/Secret Generator?

Frequently Asked Questions

Technical Deep Dive

Token/Secret Generator

Instant Generation

Fine-Grained Control

Verified Output

01 Entropy Density Matrix

02 Provisioning Pipeline

Runs 100% in your browser

You Might Also Need

Bitwise Calculator

Changelog Generator

Favicon Generator

Graph Plotter