Skip to content
Processing locally — files never leave your device

Random API Token Generator

Generate cryptographically random tokens of any byte length. Output as hex, Base64, or URL-safe Base64. Perfect for API keys and session IDs.

    How to use API Token Generator

    1. Choose the number of random bytes. 32 bytes (256 bits) is a strong, common default for API keys.
    2. Pick an output format: hex for readability, Base64 for density, or Base64URL for tokens that go in URLs.
    3. Set how many tokens to generate at once if you need a batch.
    4. Click Generate. Each token is produced from a cryptographically secure random source in your browser.
    5. Copy a single token or copy them all, then paste into your config, secrets manager, or environment variables.

    Generating secure random tokens for keys, secrets, and IDs

    API keys, session identifiers, password-reset links, CSRF tokens, and webhook secrets all share one requirement: they must be impossible to guess. The only honest way to achieve that is to generate them from a cryptographically secure random source and make them long enough that brute force is hopeless. This tool does both, entirely in your browser.

    The source has to be a CSPRNG

    For a machine secret the stakes around randomness are higher than for a human password, because a token is often the only thing protecting an endpoint. A CSPRNG — cryptographically secure pseudo-random number generator — is the one source whose past output reveals nothing about its future output. This tool fills every byte from crypto.getRandomValues(); an attacker who somehow saw a million previous tokens still could not narrow down the next one.

    Bytes are the real measure of strength

    It is the number of random bytes, not the length of the printed string, that determines how strong a token is. A token of n bytes carries 8 × n bits of entropy regardless of how you encode it:

    16 bytes = 128 bits  → 32 hex chars / 22 Base64URL chars
    24 bytes = 192 bits  → 48 hex chars / 32 Base64URL chars
    32 bytes = 256 bits  → 64 hex chars / 43 Base64URL chars

    256 bits is the comfortable default for anything security-sensitive: the number of possible 32-byte tokens is so astronomically large that guessing one is not a threat anyone needs to plan for.

    Choosing an encoding

    • Hex uses only 0–9 and a–f, so it is unambiguous and easy to read aloud — at the cost of being twice as long as the raw bytes.
    • Base64 packs the bytes more densely (~1.33 characters per byte) using letters, digits, +, and /.
    • Base64URL is Base64 with + and / replaced by - and _ and the padding stripped, so it drops straight into URLs and file names without escaping.

    Handling tokens safely

    Generating a strong token is only half the job. Keep secrets out of your source code and version control, inject them through environment variables or a dedicated secrets manager, never log them, and rotate them if you suspect exposure. Where possible, store only a hash of a token on the server so that a database leak does not hand attackers the live secret.

    Related security tools

    Frequently asked questions

    How random are these tokens?
    Each token is filled byte-for-byte from crypto.getRandomValues(). Because that source is unpredictable even to someone who has watched earlier outputs, two tokens never share a guessable relationship — which is the whole point of a machine secret.
    Should I choose hex, Base64, or Base64URL?
    Hex is the most readable but encodes each byte as two characters, so it is twice as long. Base64 is more compact (about 1.33 characters per byte). Base64URL is Base64 with + and / swapped for - and _ and padding removed, so it is safe to drop into URL paths and query strings without escaping.
    How many bytes should an API key or secret have?
    16 bytes (128 bits) is the practical floor; 24 to 32 bytes (192 to 256 bits) is the modern standard and what you should default to. 256 bits of randomness is so large that brute-forcing it is infeasible for any conceivable attacker, which is why it matches the strength of common encryption keys.
    Why does byte length matter more than character length?
    Because the security comes from the underlying random bytes, not the text you see. A 32-byte token always carries 256 bits of entropy whether you render it as 64 hex characters or 43 Base64 characters. The encoding only changes how it looks, never how strong it is.
    Are these tokens generated privately?
    Yes. The bytes are drawn in-page and shown to you alone; nothing about a token is transmitted. For a key that will guard production, generating it on a machine that is currently offline removes even the theoretical worry.
    Can I use these as session IDs or CSRF tokens?
    Yes. Cryptographically random, sufficiently long tokens are exactly what session identifiers and CSRF tokens require, since they must be impossible to guess or forge. 16 to 32 bytes rendered as Base64URL is a common, sound choice for both.
    Is a random token the same as a UUID?
    Not quite. A UUIDv4 is a random 128-bit value wrapped in a fixed format with a few bits reserved, leaving about 122 bits of randomness. A raw token lets you choose any byte length and encoding, so for high-security keys a 256-bit token gives you more entropy than a UUID.
    How should I store the generated secret?
    Treat it like a password: keep it out of source code and logs, inject it through environment variables or a secrets manager, and rotate it if you suspect exposure. If a token grants access to anything important, store it somewhere encrypted rather than in a plain text file.

    More tools you might find useful in the same flow.

    Built by Muhammad Tahir · About