Secret Key & Password Generator

Cryptographically random API keys, UUIDs, hex and base64 secrets - generated in your browser, never sent anywhere

100% free. Runs entirely in your browser - your files and data never leave your device and nothing is uploaded to any server.

URL-safe alphanumeric - the shape used by Stripe, GitHub and most REST APIs.

32
5

Generated with crypto.getRandomValues() in your browser - nothing is sent to a server, and nothing is stored.

About this tool

Generate cryptographically random secrets in the format your project actually needs - API-style keys, UUID v4 values, hex strings, base64 strings, or strong passwords - using your browser's crypto.getRandomValues() so nothing is ever sent to a server. Add an optional prefix, generate a batch at once, and copy or download the results as a .txt file.

How to use this tool

  1. Pick a formatChoose API Key, UUID v4, Hex, Base64, or Password depending on what you need to generate.
  2. Set length and prefixAdjust the character length (where applicable) and optionally add a fixed prefix like `sk_live_`.
  3. Choose how many to generateGenerate a single secret or a batch of up to a few hundred at once.
  4. Copy or downloadClick any row to copy it instantly, copy the whole batch, or download everything as a .txt file.

How long should a secret key be?

For signing keys and API secrets, use at least 32 random bytes - 256 bits - which is 64 hex characters or about 43 Base64 characters. Passwords for people should be at least 16 characters from a mix of character types, or a passphrase of several random words.

Store secrets in environment variables or a secrets manager, never in source code or a repository, and rotate them if they may have been exposed.

Key features

  • Uses the browser's built-in cryptographically secure random number generator, not Math.random().
  • Covers the five secret formats developers reach for most: API keys, UUIDs, hex, base64, and passwords.
  • Optional prefix support makes keys look like real API tokens for seeding test data.
  • Batch generation with one-click copy and a .txt download for seeding env files or test fixtures.

Common uses

  • Generating placeholder API keys for local development or demo environments.
  • Creating UUIDs for database seed data or mock records.
  • Generating hex or base64 secrets for signing keys, encryption tests, or session tokens.
  • Producing a batch of strong passwords for test accounts.

Tips for better results

  • Never reuse a generated development secret as a real production credential - always issue fresh production keys through your actual provider.
  • Use the prefix field to mimic your real key format (e.g. `sk_test_`) so test data behaves like production data in your code.
  • For encryption or signing keys, prefer Hex or Base64 format at a longer length rather than the API Key format.
  • Download as .txt when seeding multiple environment variables at once to avoid retyping values.

Mistakes to avoid

  • Using a short length for a value meant to be a real security secret.
  • Assuming UUID v4 values are cryptographically unpredictable enough to double as auth secrets - use Hex or Base64 for that instead.
  • Committing generated secrets to source control, even placeholder ones, out of habit.
  • Forgetting that a prefix counts toward the visible string but not the random portion's length.

Frequently asked questions

They are generated with crypto.getRandomValues(), the Web Crypto API's cryptographically secure random source, the same primitive used to generate real API keys and tokens - not Math.random(), which is not safe for security-sensitive values.

You can, since the randomness itself is secure, but most real API keys need to be registered with the service that will authenticate them - generating a random string here doesn't create a working key in some other system, it just gives you a securely random value.

API Key and Password use a mixed alphanumeric (plus symbols for Password) charset at a length you choose; UUID v4 is a fixed-format 36-character identifier; Hex and Base64 encode raw random bytes in those two standard encodings, commonly used for signing keys and tokens.

At least 128 bits of randomness, which is 32 hex characters or about 22 base64 characters; 256 bits is a common choice for signing secrets such as JWT keys. Longer adds little once you are past that.

In environment variables or a secrets manager, never in source code or a public repository. Rotate any key that has been pasted into a chat, ticket or commit.

A prefix shows at a glance what a key is for and which environment it belongs to, and it lets secret scanners on GitHub and elsewhere recognise leaked keys automatically.

Related guides