- How do I generate a random API token online?
- Choose an output format (hex, Base64, Base64URL, or alphanumeric), set the length — 32 characters is a solid default — and click Generate; the token appears instantly and can be copied with one click. Add a prefix like sk_ or api_ if your service follows a naming convention. Everything runs client-side in your browser, so the token never touches a server.
- 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 makes a token cryptographically secure?
- A token is cryptographically secure when it comes from a cryptographically secure random number generator (CSPRNG) — such as the Web Crypto API's crypto.getRandomValues() — rather than a plain pseudo-random generator like Math.random(), whose output can be predicted from a few samples. A CSPRNG draws on operating-system entropy sources, so even an attacker who has seen previous tokens cannot guess the next one. Sufficient length matters too: aim for at least 128 bits of entropy so brute-force guessing is computationally infeasible.
- What token length should I use for API keys?
- 32 characters in hex format provides 128 bits of entropy, which is enough to make brute-forcing infeasible and is suitable for most API keys. For signing secrets, HMAC keys, and other long-lived credentials, use 32+ bytes (64 hex characters) for a full 256 bits of entropy.
- 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.
