Generate secure random tokens online
Generate random credentials
This generates random values, not valid API keys for third-party services. Issuing sessions, expiry, and revocation remain server responsibilities. Regenerate after changing settings.
32 HEX characters = 16 random bytes = 128 bits. 32 Base64url bytes = 43 unpadded characters = 256 bits. The two length settings use different units.
Estimated custom-token entropy = character count Γ logβ(alphabet size). A fixed prefix adds no entropy. The estimate is per token, not multiplied by batch count.
.env values use single quotes to preserve characters such as # and $. If your loader additionally expands variables, verify the loaded value. Bearer export is enabled only when the actual tokens meet the header character rules.
The full guide also includes pitfalls, worked examples, snippets, FAQs, and related tools for checking results or troubleshooting.
Generate random values locally for services you control. HEX length counts hexadecimal characters; Base64url length counts random bytes and omits padding. Custom alphabets use rejection sampling to avoid modulo bias. Prefixes label tokens but add no entropy. Copy plain tokens, single-quoted .env values, or Bearer headers when the resulting characters are compatible. Changing settings clears old output. This tool does not issue valid third-party API keys, register sessions, assign permissions, or enforce expiry. Generated tokens and prefixes are not uploaded or persisted; only non-secret generation settings are saved.
Prefix
Use it to label token type, environment, product area, or docs examples.
Random body
Use it as the actual secret that must resist guessing and accidental collision.
Note: A prefix is useful product polish; the random body is the security work.
Bearer header
Use it when testing an API request directly in an HTTP client or terminal.
.env value
Use it when preparing app configuration, deployment variables, or local test setup.
Note: Copying the right wrapper around the same token removes a surprising amount of small manual error.
Opaque random token
Use for reset links, API keys, and anti-guessable identifiers.
Structured token payload
Use when token must carry verified claims and expiration metadata.
Note: Opaque tokens require server-side registration and validation; correctly signed structured tokens can carry verifiable claims.
Long-lived token
Use only for tightly controlled machine-to-machine integrations.
Short-lived rotating token
Use for user-facing auth and sensitive operations.
Note: Rotation and short TTL dramatically limit blast radius after leakage.
Bad input: Environment prefix predictable and entropy too low.
Failure: Attackers can enumerate token shape and increase hit probability.
Fix: Use high-entropy generation and isolate secrets per environment.
Bad input: Reset link token TTL set to 72h without one-time invalidation.
Failure: Compromised inbox enables delayed account takeover.
Fix: Use short TTL and one-time use semantics with immediate revocation on consume.
Q01
Generate random values for services you control; this does not issue third-party API keys. Copy plain tokens, quoted .env values, or Bearer headers only when the resulting characters are compatible.
Q02
It depends on the risk and charset. API keys, session tokens, and integration secrets usually deserve more entropy than short human-entered codes.
Q03
Base64url avoids +, /, and padding. Transport compatibility does not protect secrets from URL history or logs; keep real credentials out of both.
Recommend: Use high-entropy short-lived one-time tokens.
Avoid: Avoid reusable long-lived tokens for high-risk user actions.
Recommend: Use rotated scoped tokens with audit trails and secret management.
Avoid: Avoid static shared tokens hardcoded in repositories.
Cause: API keys, browser sessions, and short verification codes have different constraints and lifetimes.
Fix: Choose token length, alphabet, and lifetime according to the specific transport and risk profile.
Cause: Example tokens copied into docs or chats can later leak into real environments.
Fix: Document the generation policy and regenerate fresh tokens for real usage instead of reusing examples.
Cause: Prefixes help humans and systems recognize token type, but predictable text does not make a secret harder to guess.
Fix: Treat the random part as the security boundary and keep it long enough for the risk level.
Goal: Generate a batch of new API-key-shaped secrets and copy them into the format your deployment workflow expects.
Result: You get candidate secrets and quoted configuration values. Register the new secret on your server and verify it before revoking the old one.
Goal: Create realistic API token examples for docs, test fixtures, or onboarding without reusing production values.
Result: The examples look like the real integration, but they do not train the team to copy one shared secret everywhere.
text
DOCS_ONLY_NOT_A_REAL_SECRETdotenv
API_TOKEN_1='DOCS_ONLY_NOT_A_REAL_SECRET'No. A prefix changes the shape only. Your server must register and validate the secret; third-party credentials must be issued by that provider.
HEX 32 means 32 hex characters (128 random bits). Base64url 32 means 32 random bytes (256 bits), encoded as 43 unpadded characters.
Custom symbols such as #, $, or braces do not fit the Bearer credential syntax. Use HEX, Base64url, or a compatible alphabet. Prefixes accept only letters, digits, underscores, and hyphens, up to 64 characters.
Single quotes keep # and other symbols inside the value rather than treating them as comments or shell operators. Check your loader if it additionally performs variable expansion.
No. Tokens and prefixes stay in page memory until cleared or the page closes. Analytics records counts and format choices, not generated values or prefix text. Old stored prefixes are removed when opening the tool.
Keep browsing