Token Generator

Generate secure random tokens for API keys, password-reset links, session identifiers, test data and invite codes. Choose the format and length, see the entropy in bits, generate up to 100 at once, and get the SHA-256 hash of each token for storing safely. Tokens are created with your browser’s cryptographic random generator and never leave your device.

What makes a token secure

A security token is only as strong as it is unpredictable. Secure tokens must come from a cryptographically secure random number generator (CSPRNG) and be long enough that guessing is impractical. This generator uses the Web Crypto API (crypto.getRandomValues and crypto.randomUUID), which draws on the operating system’s secure random source. It also uses rejection sampling when mapping random bytes to characters, so every character in the set is equally likely — a subtle detail that simple generators often get wrong.

How much entropy do you need?

Entropy in bits = length × log₂(number of possible characters). Each extra bit doubles the number of guesses an attacker needs; 128 bits is far beyond brute force with any foreseeable computing power.

Formats explained

Storing tokens safely: hash them

Treat tokens like passwords. Show a newly generated API key to its owner once, then store only a hash of it. When a request arrives, hash the presented token and compare it with the stored hash. Because the tokens here are long and random, a fast hash such as SHA-256 is appropriate (slow password hashes like bcrypt or Argon2 are designed for low-entropy human passwords). If your database leaks, the hashes are useless to an attacker. The “Show SHA-256 hash” option displays the hash so you can see what would be stored.

Prefixes for API keys

Many services add a short prefix to API keys, such as app_test_, to show which system and environment a key belongs to. Prefixes help developers tell keys apart, let secret-scanning tools detect leaked keys in code repositories, and make it obvious when a test key is used in production. The prefix adds no security by itself — the random part must still carry enough entropy.

Worked example

A developer needs API keys for a small internal service. They choose alphanumeric, 32 characters, and the prefix svc_. Each key carries about 190 bits of entropy. They give each key to its user once, store only the SHA-256 hash in the database with the key’s owner, creation date and last-used date, and plan to rotate keys every 90 days. For password-reset emails, they use a 43-character base64url token that expires after 30 minutes and can be used only once.

Token handling checklist

• Send tokens only over HTTPS.
• Set expiry times and allow tokens to be revoked.
• Use tokens once where possible (reset links, invites).
• Never log full tokens; log a short prefix or hash for debugging.
• Compare hashes using constant-time comparison.
• Keep secrets out of source code; use a secret manager or environment variables.
• Rotate long-lived keys regularly and after staff changes.

Tokens in URLs

Tokens in links — password resets, email verification, invitations — can leak through browser history, server logs, analytics and the Referer header when the page links to other sites. Keep such tokens single-use and short-lived, set a strict Referrer-Policy on the pages that receive them, avoid third-party scripts on those pages, and exchange the URL token for a session quickly. For API authentication, send tokens in an Authorization header rather than the query string.

Not a password manager

Random tokens are for machines. For your own account passwords, use a password manager, which generates and remembers unique passwords for every site; for passwords you must remember, a passphrase of several random words is easier to type and still strong.

Privacy

Tokens are generated locally in your browser. They are not transmitted, logged or stored by this page. Even so, for production secrets many teams prefer to generate keys inside the system that will use them, so they are never displayed at all.