Free API Key Generator by NexLink Core
The NexLink Core API Key Generator creates secure keys, access tokens and secrets for the services around your server — Discord bots, webhook endpoints, RCON bridges, panel integrations and anything else that needs to authenticate a machine rather than a person.
Pick a plain random token, a prefixed key in the style used by most modern APIs, or a UUID.
Generate an API Key
Choosing a Key Format
Token
A plain random string. This is the right default when you control both ends of the integration and just need a shared secret.
Base62 (letters and numbers) is the safest general-purpose choice — it survives being pasted into URLs, headers, JSON, YAML and environment variables without escaping. Use Base64 URL-safe if you want slightly more entropy per character, or Hexadecimal when a system expects hex specifically.
Prefixed
A key in the nlc_live_A1b2C3… style popularised by Stripe and GitHub. The random secret does all the security work, but the prefix earns its place:
- Identifiable in logs. You can tell at a glance which system a key belongs to.
- Environment safety. A
testkey that leaks costs you nothing, and the prefix makes it obvious when someone has wired a test key into production by mistake. - Secret scanning. A distinctive prefix is what lets automated scanners flag a key that has been committed to a repository, rather than it sitting there unnoticed.
UUID
A UUID v4 carries 122 random bits, which is ample for an identifier. It’s a good fit where a system already expects the UUID format. Because the size is fixed, use Token or Prefixed mode when you want a longer secret.
How Long Should an API Key Be?
For a machine credential, aim for at least 128 bits of entropy — the generator shows the current figure as you adjust the settings.
| Key type | Recommended |
|---|---|
| Internal service-to-service token | 32+ Base62 characters (~190 bits) |
| Public-facing API key | 40+ Base62 characters (~238 bits) |
| Webhook signing secret | 32+ Base62 characters |
| Identifier only, not a secret | UUID v4 |
Unlike a password, nobody has to type an API key by hand, so there is no reason to be frugal with length.
Longer is cheap here. Going from 24 to 40 characters costs you nothing operationally and removes brute force from the threat model entirely.
Handling Keys Safely
An API key is a bearer credential: whoever holds it is the caller. Treat it like a password that never gets a second factor.
- Never commit keys to a repository. Use environment variables or a secrets manager. If a key has ever been committed, rotate it — deleting the commit does not remove it from history or from anything that already cloned it.
- Never put keys in client-side code. Anything shipped to a browser or game client is public, no matter how it’s obfuscated.
- Store a hash, not the key. If you are the one issuing keys, store a hash of each key and show the full value to the user exactly once. A leaked database then yields nothing usable.
- Scope keys narrowly. One key per integration, with only the permissions that integration needs. When something has to be revoked, you revoke one thing.
- Rotate on a schedule and on staff changes. Support both an old and a new key briefly during a rotation so nothing breaks mid-swap.
Do not paste API keys into public Discord channels, screenshots, pastebins or support tickets. If a key has been shared anywhere you don’t fully control, assume it is compromised and rotate it.
Frequently Asked Questions
How random are these keys?
Every character is chosen with a cryptographically secure random number generator, combined with rejection sampling so that each character in the set is equally likely. This is the same class of randomness used for encryption keys.
Does the prefix make my key less secure?
No. The prefix is assumed to be public — the security comes entirely from the random portion, which is why the entropy readout counts only that part. A prefix costs you nothing and makes the key far easier to manage.
Can I use this for a Discord bot token?
Not for the bot token itself — Discord issues that, and you can only regenerate it in the Discord Developer Portal. This tool is for secrets you issue: webhook signing secrets, admin API keys for your own bot, and credentials for integrations between your own services.
Should I use a UUID as an API key?
You can, and 122 bits is genuinely strong. The caveats are that the format is fixed-length and that UUIDs are widely used as non-secret identifiers, so a UUID in a log or a URL is less likely to be recognised as something that needs protecting. A prefixed key signals its own sensitivity.
What do I do if a key leaks?
Revoke it first, then issue a replacement — in that order. Afterwards, check your logs for calls made with the old key so you know what, if anything, was accessed.