Security

Hex Password Generator

Generate random hexadecimal strings (0-9, a-f). Ideal for encryption keys, tokens, and API secrets. Configurable length. Free, browser-based, no signup.

About this hex password generator

Hexadecimal strings — characters 0-9 and a-f — are the standard format for encryption keys, authentication tokens, MAC addresses, and many API secrets. Each hex character represents exactly 4 bits, making it easy to calculate key strength: a 32-character hex string is a 128-bit key, 64 characters is 256 bits. This generator produces random hex strings using a cryptographically secure random number generator (Web Crypto API). Common use cases include WEP/WPA keys, AES encryption keys, HMAC secrets, session tokens, and color codes. Note that hex passwords have lower entropy per character (~4 bits) than full alphanumeric passwords (~5.95 bits), so they need to be longer to achieve the same strength. A 32-hex-character password (128 bits) is equivalent in strength to about a 22-character alphanumeric password.

Hexadecimal encoding: how it works and why it matters

Hexadecimal is a base-16 numeral system that uses the digits 0-9 and the letters a-f (or A-F) to represent values from 0 to 15. Each hex character encodes exactly 4 bits of binary data, making hex the most direct and human-readable way to represent raw binary. A byte (8 bits) becomes exactly two hex characters: the value 255 in binary (11111111) is "ff" in hex, the value 0 (00000000) is "00". This direct relationship between bits and characters is why cryptographic systems universally prefer hex for representing keys, hashes, and tokens. When a system tells you it needs a "128-bit key," it expects a 32-character hex string. A "256-bit key" is 64 hex characters. The math is always hex_length = bit_length / 4. This predictability makes hex the standard encoding for encryption keys, cryptographic hashes (SHA-256 output is 64 hex characters), HMAC secrets, and session tokens across virtually every programming language and platform.

Common use cases for hexadecimal strings

Hex strings appear throughout software development and cryptographic applications. AES encryption keys are specified as hex — AES-128 uses a 32-char hex key, AES-256 uses a 64-char hex key. SHA-256 hashes are displayed as 64 hex characters; SHA-512 as 128 hex characters. HMAC secrets for JWT signing and API authentication are typically 32-64 hex characters. OAuth client secrets and API keys from services like AWS, Stripe, and Twilio are often hex-encoded random values. MAC addresses (hardware network identifiers) use 12 hex characters. Color values in CSS use 6 hex characters (RGB) or 8 hex characters (RGBA). Session tokens and CSRF tokens in web applications are typically 32-64 hex characters. WPA/WPA2 network keys in hex format bypass passphrase derivation for direct 128-bit key material. In all these contexts, the hex format signals that the value represents raw binary data, not a human-readable string.

Hex vs Base64 vs alphanumeric: choosing the right encoding

When generating random tokens and secrets, the encoding format affects both the length required for a given security level and the compatibility with target systems. Hex (Base16) encodes 4 bits per character — the most verbose format, requiring twice as many characters as the underlying bytes. A 128-bit secret needs 32 hex characters. Base64 encodes 6 bits per character, requiring only 22 characters for 128 bits — 31% more compact than hex. Base64url (URL-safe Base64) replaces + and / with - and _ for safe use in URLs and headers. Alphanumeric (Base62, using A-Z, a-z, 0-9) encodes ~5.95 bits per character, requiring 22 characters for ~128 bits. The choice depends on context: if the system explicitly expects hex (hash algorithms, encryption keys, network configurations), use hex. If you are designing a system and have flexibility, Base64url gives shorter tokens for the same security level. For human-visible tokens where compactness is not critical, alphanumeric avoids the + and / characters that require escaping.

Generating cryptographically secure hex values

The security of a hex key or token depends entirely on the quality of the underlying random number generator, not on the hex encoding itself. A hex string generated from a cryptographically secure source (the Web Crypto API, /dev/urandom on Linux, or CryptGenRandom on Windows) is indistinguishable from random binary data and provides the full security of its bit length. By contrast, a hex string generated from a weak source like Math.random() in JavaScript or the default random() in older languages would have far fewer than 4 bits of real entropy per character — the value could be predicted or reproduced. This generator uses window.crypto.getRandomValues, which is the browser's access point to the operating system's cryptographic random number pool. This is the same entropy source used by all properly implemented cryptographic libraries. The result is a hex string with genuine maximum-entropy randomness at 4 bits per character.

Storing and rotating hex credentials

Hex tokens and keys used as API secrets, HMAC signing keys, and encryption keys require careful storage and rotation practices. Never embed hex secrets directly in source code — use environment variables or a secrets manager instead. In version control, even a briefly committed secret should be considered fully compromised and rotated immediately, as git history is public and permanent for any repository ever made public or shared. For API signing keys and HMAC secrets, implement a key rotation mechanism from the start: store the current key and the previous key simultaneously, accepting signatures from either during a transition window. This allows seamless rotation without downtime. For encryption keys protecting stored data, key rotation requires re-encrypting the data under the new key, which is more complex — plan this architecture before first deployment. Hex keys should be stored in secrets managers (Vault, AWS Secrets Manager) with access logging, not in plaintext config files or environment variable exports in shell profiles.

FAQ

Common questions

What is a hexadecimal password used for?

Encryption keys (AES-128, AES-256), authentication tokens, HMAC secrets, WEP/WPA network keys, API secrets, session identifiers, and any system that requires input in hex format.

How long should a hex password be?

It depends on the required bit strength: 32 hex characters = 128 bits (standard encryption), 48 hex characters = 192 bits, 64 hex characters = 256 bits (maximum standard encryption strength).

Is hex the same as Base16?

Yes. Hexadecimal (hex) is Base16 encoding, using digits 0-9 and letters a-f (or A-F). Each character represents 4 bits of data, making it a convenient way to represent binary data in text form.

Should I use uppercase or lowercase hex?

Both are valid and represent the same values. Lowercase (a-f) is more common in modern programming (JavaScript, Python, CSS color codes). Uppercase (A-F) is traditional in networking and hardware contexts.

Why does hex use only 0-9 and a-f rather than the full alphabet?

Hex represents binary data where each group of 4 bits maps to a single character. 4 bits can hold values 0-15, and hex represents these as 0-9 (for 0-9) and a-f (for 10-15). This makes conversion between binary and hex direct and predictable — every hex character is exactly 4 bits with no ambiguity.

Can I use a hex string as a WPA2 WiFi password?

Yes. WPA2 accepts hex strings for network keys — a 32-hex-character key is used as a 128-bit raw key, bypassing the normal PBKDF2 derivation process. This is more secure than a passphrase-derived key of equivalent length because no derivation weaknesses apply.

Is hex output from this generator truly cryptographically random?

Yes. This tool uses the Web Crypto API (window.crypto.getRandomValues) to generate random bytes, then encodes them as hex. The randomness source is the same cryptographic-quality entropy used for full password generation — the hex encoding does not affect the underlying randomness.

How does hex compare to Base64 encoding for tokens and secrets?

Both encode binary data as text. Hex uses 2 characters per byte (50% efficient). Base64 uses ~1.33 characters per byte (75% efficient), making it more compact. For the same security level, a Base64 token is about 25% shorter than a hex token. Hex is preferred when the receiving system explicitly expects hex format; Base64 is preferred for URL-safe tokens and compact storage.