A secure random token needs more than an impressive-looking string. The system must generate enough unpredictable bytes, encode them without losing information, store an appropriate verifier and enforce expiry, scope and revocation. A token copied into a URL can grant access to anyone who obtains it if the application treats possession as authority.
Define the token's purpose first. A password-reset token, an API credential and a temporary download link have different lifetimes and permissions. The generation step can be similar, but the surrounding acceptance rules should reflect the action being authorised.
Choose a byte budget before an encoded length
The random token generator uses cryptographic random bytes and displays either hexadecimal or unpadded Base64url. It reports the number of random bytes and corresponding entropy bits. The generated token is kept outside ordinary report exports.
Sixteen independent random bytes provide 128 bits of randomness. Thirty-two bytes provide 256 bits. Encoding changes the text length, not the underlying entropy. A longer hexadecimal representation is not inherently stronger than a shorter Base64url representation of the same bytes.
The appropriate budget depends on expected guessing opportunities, number of valid tokens and lifetime. Use a considered security design rather than copying the shortest token another service happens to display. Online rate limits complement randomness but should not be the only barrier protecting a sensitive token.
| Random bytes | Entropy bits | Hex characters | Unpadded Base64url characters |
|---|---|---|---|
| 16 | 128 | 32 | 22 |
| 24 | 192 | 48 | 32 |
| 32 | 256 | 64 | 43 |
| 48 | 384 | 96 | 64 |
Hex uses two characters per byte. Unpadded Base64url uses the ceiling of eight times the byte count divided by six. These lengths assume the complete encoded value is retained; truncating the string changes the effective token space.
Keep the representation stable across systems
Base64url replaces the plus and slash characters of ordinary Base64 with URL-friendly alternatives. The generator also removes padding. A receiving system must decode or compare the same representation consistently and reject malformed input according to its contract.
Do not lowercase a Base64url token, because its alphabet is case-sensitive. Hexadecimal can be normalised deliberately, but that rule does not transfer to every encoding. A generic case-insensitive database column can silently alter token comparison semantics.
If the token travels through a query parameter, use a proper URL builder and avoid accidental double encoding. If it travels in a header, follow that header's syntax. Preserve the exact token at the boundary rather than applying broad trimming or punctuation removal.
Store a verifier when the use case permits it
For a high-entropy bearer token, storing a cryptographic digest of the token can reduce the consequences of a database read exposure. On receipt, calculate the verifier and compare it with the stored value through a suitable design. The original token is shown only when created if the product does not need to recover it.
This differs from password storage because a correctly generated random token has a defined high-entropy source. Human passwords need specialised password-hashing treatment. Do not generalise the token-verifier design to low-entropy user-chosen secrets.
Some systems use a public identifier plus a secret component to locate the record efficiently. Keep the identifier and secret roles explicit. A public prefix should not be counted as secret entropy, and logs should not include the secret component.
Bind the token to purpose and expiry
Store the intended account, action, scope, creation time and expiry with the verifier. A password-reset token should not automatically authorise unrelated account changes. An API token should carry only the permissions its client needs.
Enforce expiry on the server when the token is used. A frontend countdown is only a display. Use a reliable server clock and a defined comparison boundary. Decide how clock tolerance applies, if relevant, without extending validity indefinitely.
Provide revocation for long-lived credentials and consume single-use tokens atomically. If two requests arrive together, a check-then-update race can allow both to succeed. The database operation should enforce the intended once-only transition.
Design a password-reset flow
When a reset is requested, generate a fresh token, store its verifier with a short documented expiry and associate it with the intended account and action. Send the link through the service's established delivery route. Avoid revealing account existence through unnecessarily different public responses.
When the link is opened, validate the token and its state before allowing the password change. After a successful change, consume the token and apply the account's session-revocation policy. Decide whether issuing a new reset invalidates earlier outstanding tokens and implement that rule consistently.
Do not log the full reset URL in ordinary analytics or error reports. Use an appropriate referrer policy and avoid unnecessary third-party resources on the reset page. The token can leak through copied links, browser history and support screenshots even if generation was perfect.
Test expired, revoked, reused and concurrently submitted tokens. Also test a token from one account against another account's route. The security property is the complete state transition, not merely a successful random-byte call.
Generate at the trusted creation boundary
The local generator creates a string but does not register it with a service. For an application credential, the trusted server normally owns issuance or validates the issuance process. Pasting a random string into a form does not automatically make it an active or authorised token.
Use a standard cryptographic random facility in the issuing environment. Avoid timestamps, counters, user IDs and predictable concatenations as secret material. These can be useful public identifiers but do not supply the unpredictability expected of bearer credentials.
Handle generation errors explicitly. A fallback to a weaker random function during an outage can silently change the security model. If secure generation is unavailable, fail the issuance operation and preserve a clear error for the operator.
Limit where the token appears
Display a newly created API token once when appropriate, explain where to store it and provide a way to revoke or replace it. Avoid including it in generic JSON reports, print views or searchable diagnostic fields. The included generator follows that separation for its local output.
Clipboard and screen-sharing risks remain. Save the token in the intended secret store and clear unnecessary visible copies. A web application cannot promise to erase every clipboard-history or operating-system memory copy after reset.
For operational logs, use an independent token identifier or a carefully designed non-secret reference. Do not expose enough of the token to reduce its security budget without considering the impact. Even partial values can become useful linkage data.
Make replacement a routine operation
Long-lived API credentials should have an owner, purpose and rotation or revocation process. If clients need overlap during replacement, bound that overlap and verify adoption of the new credential before retiring the old one.
Keep permissions stable or narrower during rotation unless a separate reviewed change requires more access. A replacement token should not accidentally gain broad administrative scope because it was created through a different interface.
After an exposure, revoke the affected credential and investigate its use through available audit records. Generating a new token without disabling the old one does not remove the old token's authority.
Validate the decoded byte count
If an API accepts a fixed-size encoded token, validate both its permitted text form and decoded byte length. A string with the expected number of characters can still contain malformed encoding or invalid trailing bits. Keep the accepted representation canonical where the protocol requires it. This prevents alternate textual forms from confusing lookup, logging or signature boundaries and makes a token’s actual random-byte budget explicit.
Frequently asked questions
Is a 32-character hex token 256 bits?
No. Each hexadecimal character represents four bits, so 32 hex characters represent 128 bits when generated uniformly. Count the original random bytes and retain the complete encoding. Visual length alone can be misleading across different alphabets.
Does Base64url make the token secret?
It is an encoding, not encryption. Secrecy comes from unpredictable generation and protected handling. Anyone who receives the token can decode its bytes, and a bearer-token system may grant authority simply from possession.
Can I lowercase tokens for easier comparison?
Only if the defined representation permits it. Base64url is case-sensitive, so lowercasing changes the token. Choose a canonical format and enforce it consistently in storage, transport and comparison rather than applying generic text normalisation.
Does this generator create an active API key?
No. It creates random text locally and does not register it with any service. An API key becomes meaningful only through the issuing application's storage, scope and verification process. Use the service's supported credential-creation workflow.
Why store a hash instead of the token?
A verifier can let the service validate a high-entropy token without retaining its recoverable plaintext. The design still needs secure comparison, scope, expiry and database protections. It should not be copied unchanged for low-entropy human passwords.
Is a single-use flag enough?
The flag must be enforced atomically with the protected action. Separate checks and updates can race under concurrent requests. Test two simultaneous uses and confirm that only the intended operation succeeds.
What confirms a token system is ready?
Verify generation, encoding, storage, scope, expiry, revocation, duplicate handling and secret-free logs. Include the actual transport and user recovery flow. A long random string is only one component of that system.