Numbers
Hex Token Pair Generator
Used by developers, writers, and creators worldwide.
A hex token pair generator creates matched key-secret pairs as hex strings — the foundation of API authentication, OAuth client credentials, and webhook signing. The key acts as a public identifier (safe to log and transmit); the secret proves identity and stays private. Set the key to 16 bytes and the secret to 32 bytes and you get the most common credential format: a 32-char key and 64-char secret. Generate up to hundreds of pairs at once and paste them straight into your config files or environment variables. Most developers reach for this when provisioning test clients, seeding staging databases, or wiring up a local OAuth server without touching production infrastructure.
Loading usage…
Free forever — no account required
How to use
- Choose your options above
- Click Generate
- Copy your result
Detailed instructions
- Set the count field to the number of key-secret pairs you need to generate.
- Adjust key length (default 16 bytes) and secret length (default 32 bytes) to match your system's requirements.
- Click Generate to produce the batch of hex token pairs.
- Copy individual pairs or the full list, then paste keys and secrets into your config file, database seed script, or environment variables.
Use Cases
- •Provisioning 20 OAuth2 client_id / client_secret pairs for a multi-tenant staging environment
- •Seeding a mock OAuth server in a GitHub Actions CI pipeline with realistic credential fixtures
- •Populating HMAC_KEY and HMAC_SECRET environment variables in a local Docker Compose setup
- •Generating webhook signing key pairs to test payload verification logic in Jest or Supertest
- •Bulk-creating API gateway credentials in Postman environments before a load-testing run
Tips
- →Use a 16-byte key and 32-byte secret as defaults — these match common OAuth2 server expectations out of the box.
- →Generate 10-20 pairs at once when seeding a test database; you'll need more than you think for realistic fixture data.
- →If your system expects base64 instead of hex, convert with btoa(hexString) in JS or binascii.unhexlify + base64 in Python.
- →Prefix keys with a short identifier string (e.g. 'pk_live_' or 'app_') after generating — it makes credential type obvious at a glance.
- →Keep key and secret lengths consistent across your whole system; mixing lengths makes log parsing and debugging harder.
- →When testing webhook signing, use the same secret in both your sender and receiver config — regenerate a fresh pair for each test environment.
FAQ
how long should an api secret be in bytes
32 bytes (64 hex characters) is the practical minimum — that's 256 bits of entropy, sufficient against brute-force. Keys only need to be unique, not unpredictable, so 16 bytes is the standard. If your target system specifies a character length instead of bytes, divide by two to get the byte input value.
are these hex tokens safe to use in production
No. This generator runs in the browser using a non-cryptographic PRNG, so the output is not suitable for production secrets. For real credentials, use crypto.randomBytes() in Node.js, secrets.token_hex() in Python, or openssl rand on the command line. Treat this tool as a dev and prototyping shortcut only.
what's the difference between the key length and secret length settings
The key is a public identifier — it only needs to be unique, so 16 bytes is plenty. The secret must be unpredictable as well as unique, because it's the proof of identity; 32 bytes or more is recommended. Increasing key length doesn't improve security, but shortening the secret does meaningfully weaken it.