Somebody on the team needs a new database password, a new admin account on a freshly provisioned host, a new webhook secret for a third-party integration, or an API key to hand a vendor — and they need it now. The wrong instinct is to mash the keyboard or recycle a pattern; both produce credentials with predictable structure that show up in every dictionary attack and credential-stuffing list. The right instinct is to ask a cryptographically-secure random number generator for the bytes. PortJar’s Password & API Key Generator is that, with the four toggles you actually need.
What the tool does
Password & API Key Generator produces cryptographically random passwords and API keys using Node’s crypto.randomInt and crypto.randomBytes — the same CSPRNG primitives used for TLS session keys, not Math.random. You set the length and toggle whether to include uppercase letters, digits, and symbols. The page also returns three sample API keys alongside the password in conventional formats: 32-byte hex, 16-byte hex, and 24-byte base64url.
The tool runs entirely client-side. Bytes are generated in your browser tab and never transit a PortJar server. That is the only safe shape for a tool of this kind — a generator that round-trips your future secret through someone else’s server log is not a generator, it is a vulnerability.
How to use it
Open portjar.com/tools/password-generator. Set the length (16 is the floor for anything that protects real value; 32 is a reasonable default for service accounts and admin credentials), toggle uppercase, digits, and symbols according to where the credential is going, and hit Run. The example chips load 16 and 32 as quick-pick lengths. Each click of Run produces a fresh value — the previous one is gone unless you copied it.
If the destination has character-class restrictions (no symbols, only A–Z, etc.), set the toggles to match before you generate, rather than generating and editing afterwards. Editing reduces entropy in non-obvious ways and is the source of more “this password seems to keep getting brute-forced” tickets than the generator itself.
When you’d reach for it
- Setting a new database
rootor admin password during a rotation, where the value will go into a secrets manager rather than into a human’s memory. Length 32 with all classes on; the human never types it. - Generating a webhook signing secret that you will paste into one provider’s dashboard and one corresponding receiver. Use a 32- or 64-byte hex value (the 32-byte hex API key sample is exactly this) rather than a password — webhook secrets do not get typed.
- Provisioning an API key for a vendor or partner integration that will live in their config rather than your code. The 24-byte base64url sample is the right shape for systems that pass keys in URL query strings or HTTP headers.
- Replacing a service account password that just leaked (in a screenshot, in a code commit, in a chat). The first move is generating a new value of the right length, the second is rotating, the third is auditing how the previous value escaped.
- Onboarding a new operator account where you need a strong temporary password they will change on first login. Length 16–20 with all classes on, delivered through a credential vault link rather than pasted directly into chat.
What to make of the output
Treat every value the tool produces as live the moment it appears in the textbox. If your browser, your operating system, or a screen-recording tool captured it on screen, it is no longer secret to that surface. Generating in a fresh, minimal browser tab is a reasonable practice; generating in a tab that is being screen-shared is not.
The length of the value is the primary measure of strength, not the character classes. A 32-character alphanumeric password is dramatically stronger than a 10-character one even when the 10-character one has symbols. If a destination system enforces a maximum length, that limit is the real ceiling on the strength of the credential — symbols and mixed case mostly compensate for shorter ceilings.
The three API key samples are not redundant; they are conventional shapes for three different consumer expectations. 32-byte hex (64 hex characters) is the de facto standard for webhook secrets and HMAC keys. 16-byte hex is a smaller key suitable for less-sensitive integrations. 24-byte base64url is URL-safe and shorter than the equivalent hex, which matters when the key has to ride in a query string or header. Pick the format the destination system documents; do not assume they are equivalent.
Once generated, the value should travel through a credential vault, a secrets manager, or a one-time-link service — not Slack, not email, not a ticket comment. Even a value generated with a strong CSPRNG becomes a liability the moment it sits in a chat history searchable by twenty people. The generator is the easy part; the handoff is the part that decides whether the credential stays a secret.
Stack Harbor uses CSPRNG-generated values for every service credential, vault entry, and rotation we manage inside environment management as a service.