- Are these tokens truly random and secure?
- Yes. Tokens are generated using the Web Crypto API (crypto.getRandomValues) which provides cryptographically secure pseudo-random numbers, not Math.random().
- What token length should I use for API keys?
- 32 characters in hex format provides 128 bits of entropy, suitable for most API keys. Use 64+ characters for signing secrets and HMAC keys.
- Can I add a prefix like sk_ to generated tokens?
- Yes. You can add custom prefixes and suffixes to match naming conventions like Stripe (sk_live_), OpenAI (sk-), or your own format.
- Which format should I use: hex, Base64, or alphanumeric?
- Hex is standard for HMAC keys and signing secrets. Base64 is compact for JWTs and cookies. Alphanumeric is human-readable for API keys shared with users.
- Should I store generated tokens in source code?
- Never. Store secrets in environment variables, .env files (gitignored), or a secrets manager like AWS Secrets Manager or HashiCorp Vault.
- Can I generate multiple tokens at once?
- Yes. Use bulk mode to create up to 100 unique tokens at once for provisioning multiple API keys, test accounts, microservices, or environment configs simultaneously. Copy all as newline-separated for direct paste into a .env file, or download as .txt for secure distribution via password manager.
- Does this work for JWT secret keys?
- Yes. For HS256 (HMAC-SHA-256) JWT secrets, use 32 bytes / 256 bits — generate a 64-char hex or 44-char Base64URL token. For HS512, use 64 bytes / 512 bits — 128-char hex or 88-char Base64URL. JWT libraries decode these formats automatically. For RS256 (asymmetric), use our RSA Generator instead.
- Is 16 characters enough for an API key?
- 16 hex chars = 64 bits of entropy. For long-lived API keys, that's marginally OK but not great — attackers with extensive compute could theoretically brute-force given enough time. Use at least 32 hex chars (128 bits) for production API keys. 16 chars is acceptable for short-lived (under 1 hour) session tokens where revocation is fast.
- Should I hash API keys before storing in the database?
- Yes — hash with SHA-256 before storing (no salt needed since the key itself is high-entropy random). On API requests, hash the provided key and look up the hashed value in your database. This way, a database leak doesn't expose live API keys. Show the raw key to the user ONCE at creation time; never display it again. This is how Stripe, GitHub, and AWS handle API keys.
- What's the difference between a token and a password?
- Tokens are high-entropy machine-generated (typically 128+ bits) and don't need to be memorized; passwords are user-chosen and typically have far less entropy (~30 bits). Tokens don't need slow hashing like bcrypt — fast SHA-256 is sufficient since they're already unguessable. Passwords need bcrypt/argon2 to slow brute-force attacks. Different threats, different mitigations.
