SSOGEN / Free tools / Free API Key Generator: Secure Random Keys and Client Secrets in Your Browser
Free tool
Free API Key Generator: Secure Random Keys and Client Secrets in Your Browser
An API key is a random secret that a client sends to prove who it is. This free API key generator makes strong ones with your browser's secure random source, shows the entropy in bits, and gives you the hash to store instead of the key. Nothing is uploaded.
Generate a key here
Choose a format, a size and the number of keys (1 to 20), then press Generate. Each result shows:
- the key and its length
- its bits of randomness
- a ready-made environment line such as
ACME_API_KEY=... - the key’s SHA-256 hash in hex, which is the value the server should keep
Copy key or Copy all keys copies the values.
Press Generate. The UUID format always uses 16 bytes and carries 122 random bits.
Private by design. Keys are made in this page with crypto.getRandomValues. Nothing is sent to SSOGEN or anyone else, and nothing is stored. A key made on any web page is one you have seen on a screen, so treat these as examples and generate production keys on the machine or service that will hold them.
Free, in your browser. No sign-up and no usage limit. The tool makes no network request and stores nothing.
- Keys. They come from
crypto.getRandomValues, the browser’s secure random source, never fromMath.random, which was not designed for secrets. - Hash. It comes from the browser’s
crypto.subtle.digest.
A key displayed on a web page has still been on a screen. Treat generated values as examples and create production keys inside the system that will hold them.
Use the tool to settle formats, sizes and hashing before you write the code.
What makes a good API key
An API key is a long random string that a program sends with each request so the service can identify the calling client. A strong key is 16 to 32 bytes from a cryptographically secure random source (128 to 256 bits), encoded as hex, base64url or base32. The server stores only a hash of it.
- Size. 16 to 32 bytes, which is 128 to 256 bits.
- Source. A cryptographically secure random source.
- Encoding. Hex, base64url or base32.
- Storage. The server keeps only a hash.
This free API key generator produces such keys in your browser. It also generates an OAuth client secret and a client ID.
API key, client secret and bearer token are different things
The three are often confused, and each one needs different handling.
- An API key identifies and authenticates a calling application to a service. It is long-lived, usually created by hand in a console, and sent in a header on every request.
- A client secret is the confidential half of an OAuth client’s credentials; the client ID is the public half. OAuth names it
client_secret, and RFC 6749 (section 2.3.1, read 2026-10-09) describes how the client uses the pair to authenticate to the authorization server. The secret never goes to the API. It goes only to the authorization server, in exchange for a token. - A bearer token is what the client receives and then sends to the API. RFC 6750 (section 1.2, read 2026-10-09) defines it as a security token that any party in possession of it can use, in any way any other holder can. Whoever holds the token is the caller, so a stolen bearer token works for the thief.
| API key | Client secret | Bearer (access) token | |
|---|---|---|---|
| Who issues it | You or the service, by hand | The authorization server, at client registration | The authorization server, on request |
| What it proves | This application | This OAuth client | Permission already granted |
| Sent to | The API | The authorization server only | The API |
| Typical life | Months to years | Months to years | Minutes to an hour |
| Pair with | A scope or role on the key | A client ID | An expiry and scopes |
An API key is also a bearer credential: possession is enough. The guidance below on storage, rotation and logging applies to all three.
How much entropy is enough
Entropy is the number of random bits in a key. A key with n bits has 2^n possible values, and an attacker guessing blindly must search that whole space. The OAuth specification sets two thresholds.
RFC 6749, section 10.10 (read 2026-10-09) says that the probability of an attacker guessing generated tokens, and other credentials not meant to be typed by people:
“MUST be less than or equal to 2^(-128) and SHOULD be less than or equal to 2^(-160)”.
A value drawn at random from 2^128 possibilities has a 2^-128 chance of being guessed in one attempt; with 2^160 possibilities the chance is 2^-160. That corresponds to 16 bytes and 20 bytes of randomness.
- The tool’s smallest size (16 bytes) meets the MUST.
- Sizes of 24 bytes and up meet the SHOULD.
- The same section says the authorization server must also prevent guessing of client credentials, so rate limiting and lockout belong next to entropy.
Production services go well above the floor. GitHub’s engineering blog on its token formats (read 2026-10-09) reports that its OAuth access tokens carry 178 bits of entropy in 30 characters, up from 160 bits in 40 characters.
Its authors describe keeping the previous level of entropy and then raising it.
Length counts only if the bytes are random. A key built from a timestamp, a user ID or a hash of a guessable value has far fewer bits than its length suggests.
A UUID v4 is 36 characters but carries only 122 random bits, because six bits are fixed to mark version and variant. For this reason the tool reports bits of randomness separately from length.
Formats, bytes, characters and bits
The same random bytes can be encoded several ways. A larger alphabet gives a shorter key; the number of bits stays the same. Each cell shows characters, then bits.
| Format | 16 bytes | 24 bytes | 32 bytes | 48 bytes | 64 bytes |
|---|---|---|---|---|---|
| Hex (0-9, a-f) | 32 chars, 128 bits | 48, 192 | 64, 256 | 96, 384 | 128, 512 |
| Base64url (A-Z, a-z, 0-9, hyphen, underscore) | 22, 128 | 32, 192 | 43, 256 | 64, 384 | 86, 512 |
| Base32 (A-Z, 2-7) | 26, 128 | 39, 192 | 52, 256 | 77, 384 | 103, 512 |
| Prefixed random part (base62) | 22, 130 | 33, 196 | 43, 256 | 65, 387 | 86, 512 |
| UUID v4 | 36 chars, 122 bits at any size |
Which to choose:
- Hex is safe in every context. It uses only digits and a to f, so it survives shells, URLs, spreadsheets and case-insensitive systems. It is also the longest.
- Base64url is the shortest common choice. Its alphabet is URL and filename safe, and the tool omits the trailing
=padding. - Base32 uses upper-case letters and the digits 2 to 7, which avoids look-alike characters such as 0 and O or 1 and l. Use it when people read keys aloud or retype them.
- UUID v4 is familiar and fine as an identifier, and acceptable as a key when 122 bits is enough. Its size cannot be changed.
- Prefixed keys carry a readable label, covered next.
Prefixes make leaks findable
A prefix is a fixed, readable start such as acme_live_, followed by the random part. It serves three purposes:
- People can tell what a string is and which environment it belongs to.
- Support staff can ask for the first few characters without learning the secret.
- Scanners can find the key.
Secret scanning works on patterns. GitHub’s documentation on secret scanning (read 2026-10-09) says it:
- scans the entire Git history on all branches for hardcoded credentials;
- uses patterns from service-provider partners;
- lets an organization define its own regular expressions for secrets the defaults do not cover.
A regular expression for acme_live_[0-9A-Za-z]{43} is easy to write and rarely matches by accident. A bare 43-character random string looks like any other base64 text.
GitHub’s token-format post makes the same point from the vendor side. Its authors expected the prefix alone to cut the false positive rate of secret scanning to 0.5%.
They also expected a CRC32 checksum in the last six characters of each token to “virtually eliminate” false positives offline, because a scanner can check a candidate without a database call.
The tool’s checksum suffix option follows that design. It appends six base62 characters computed from the CRC-32 of the prefix and the random part.
The checksum is not secret and adds no entropy; it lets a scanner or a gateway reject typos and look-alikes cheaply.
Keep prefixes short, lowercase and free of any secret material. Name the product, the environment (live, test) and, optionally, the key type.
Store the hash, not the key
Show the key to its owner once, at creation, and store only a hash. A leaked table of hashes cannot be used to call your API; a leaked table of keys can.
The tool shows the SHA-256 of each key as hex, so you can see the shape of the stored value.
- Show the key to its owner once, at creation.
- Store its SHA-256 hash, and a short identifier or the prefix beside it so you can find the record without a table scan.
- On each request, hash the key you receive and look up that hash.
- Compare in constant time.
A generated key is long and random, so a fast hash such as SHA-256 is sufficient. Slow, salted password hashes exist because people choose guessable passwords, and a 256-bit random key is not guessable.
Rotation, expiry and where keys must never go
- Rotate on a schedule and on suspicion. Allow two valid keys per client at once so a customer can switch with no downtime, then revoke the old one.
- Set an expiry. A key that never expires is a standing risk. RFC 6750 (section 5.3, read 2026-10-09) says token servers should issue short-lived bearer tokens of one hour or less, especially to clients that run in a browser. A long-lived key needs expiry and rotation all the more.
- Never put a key in a URL. The same RFC (sections 2.3 and 5.1) says bearer tokens should not be passed in page URLs, because browsers, web servers and other software may not secure URLs in history and logs. Send the key in the
Authorizationheader. - Never commit a key. Read it from an environment variable or a secret manager. The env line this tool prints is for a local
.envfile listed in.gitignore. A key that reaches source control is leaked: rotate it even after you delete the commit, because history and forks keep copies. - Use TLS everywhere. RFC 6749 section 10.1 (read 2026-10-09) requires that access token credentials only be transmitted using TLS.
- Log the prefix or the hash, never the key.
Scopes and least privilege
Each key should do one job. Give it a scope or a role, an environment, an owner and an expiry, and reject everything else.
- Reporting key. A read-only reporting integration gets a key that cannot write.
- Test key. A test key does not work in production.
- Leak. A leaked key can then do only what it was allowed to do.
The AI agent permissions builder applies the same least-privilege method to agent tools: name each action, grant the weakest scope that works, and mark the dangerous actions for a person’s approval.
When to use OAuth client credentials or short-lived tokens instead
A static API key is the simplest credential that works, and for server-to-server calls with one trusted owner it can be enough.
Its weakness is that it stays valid until someone revokes it. Where you can, use a token flow instead:
- OAuth client credentials grant. The client keeps a client secret but sends it only to the authorization server. RFC 6749 (section 4.4, read 2026-10-09) says a client can request an access token with only its client credentials when it is accessing resources under its control, and that this grant is for confidential clients. The API receives a short-lived access token, not the long-lived secret. See What is OAuth 2.0.
- Token exchange. When one service calls another on behalf of a caller, exchange the incoming token for a narrower one instead of forwarding a key. See OAuth token exchange.
- Sender-constrained tokens are useless to a thief without the key the client holds. See DPoP.
Inspect the tokens you receive with the free JWT decoder.
Keys for AI agents
An AI agent should not share a team key. Give each agent its own credential:
- Owner. Tie it to a named owner.
- Scope. Give it narrow scopes.
- Lifetime. Keep it short.
- Revocation. You can then revoke one agent without affecting the others.
- Audit. The audit trail shows which agent did what.
SSOGEN’s pages on AI agent identity and AI agent permissions describe that model: an owned identity, short-lived credentials and approval for sensitive scopes.
In SSOGEN, an agent has no shared secret. It signs each token request with a private key that stays on its own machine and receives a token bound to that key, valid for about four minutes.
How do I generate an API key?
How long should an API key be?
Is it safe to generate an API key in the browser?
What is the difference between an API key and a client secret?
Why add a prefix to an API key?
Should I store API keys in my database?
Can I put an API key in a URL query string?
Where to go next
- Make other secrets with the random string generator.
- Check how strong a human-chosen password is with the password entropy calculator.
- Browse the other free tools.
- Use a key like this as a signing secret and check a signature with the HMAC generator.
Sources, all read 2026-10-09: RFC 6749, RFC 6750, GitHub’s secret scanning documentation and GitHub’s engineering blog post on its token formats.