Username Generator

Three modes, three trade-offs

A username is a different problem from a password. You give it out. People type it back at you. It shows up in URLs, email-style mentions, leaderboards, indexed comments. The three modes here cover the three things you might reasonably want from that identifier.

Random mode draws character by character from your selected character classes. The 12-character default across uppercase, lowercase, and digits (62-symbol alphabet) clears ~71 bits — much more than a username needs against collision, and the right pick for burner accounts, throwaway test logins, or any context where the username is allowed to look like noise. The likelihood-taken chip will read very low almost every time.

Words mode picks from a 2,048-word curated list — about 11 bits per word, 22 bits for the default two-word draw. That’s nowhere near a secret’s bar, but it’s well past the scarcity threshold: a two-word handle like silver_kestrel rarely collides with the common-name space on social platforms. Word mode is the right pick when the handle has to be memorable and dictate-able. Each locale ships its own curated wordlist; pick the one the platform you’re registering on actually accepts.

Blend mode stitches a word (yours or one we picked), an optional prefix, an optional leet substitution, and an optional number suffix. It targets the gamer/streamer aesthetic — the_dr490n_2024, i_am_lynx7 — without devolving into the kind of pattern an attacker’s rule engine has memorised. The bit count lands somewhere between ~25 (two words + year suffix, no leet) and ~40 (two words + heavy leet + year suffix); user-supplied seed words contribute zero entropy because they’re publicly knowable, but the structural variety beats the “name + birth year” pattern most leaked-handle datasets show.

What the likelihood chip actually means

Each result carries a five-tier coloured chip — very high to very low — and the colour scale is the opposite of the password strength bar. Red here means likely already taken; teal means likely still available. The semantics inversion is deliberate. For a password, red is bad because it signals low entropy. For a username, red is bad because it signals low scarcity — the handle is probably already someone’s on the platforms that matter.

The chip is a heuristic, not a check. It combines the entropy of the construction, the length of the result, whether it’s a single dictionary word, whether decorations like leet or a number suffix landed, and a small bonus for random-mode draws (which sample a much larger search space than any wordlist). A one-character username pegs very high regardless of platform; a sixteen-character random string pegs very low; a single common dictionary word with no decoration lands on high. The mapping is calibrated against the structural patterns attackers and scrapers find easiest to enumerate, not against any platform’s actual name database.

Why we don’t check live platforms

Four reasons. First, there’s no clean API across the platforms a username actually matters on (Twitter, Instagram, Discord, GitHub, Reddit, every game launcher); the scraping workarounds break weekly and would push our infrastructure into terms-of-service grey zones. Second, availability changes second to second — by the time you copy the handle, the answer can flip. Third, platforms apply different rules: length caps, allowed characters, reserved words, locale-specific prohibitions. A blanket “available” signal would lie about half of them. Fourth, and most importantly, probing live platforms with arbitrary candidate strings looks a lot like reconnaissance.

Instead, the chip tells you what we can know — structural scarcity. When you’ve settled on a candidate, take it to namechk.com or to the actual signup page and confirm. Treat the chip as a triage hint, not as ground truth.

Common mistakes to avoid

Most leaked-handle analyses converge on the same patterns. None of them are security catastrophes by themselves; together they collapse the privacy of an online identity faster than people expect.

• Reusing the same handle across platforms. One handle on Twitter, GitHub, and Discord lets anyone with a search bar reconstruct a full cross-platform identity. Use a different handle per context — at minimum, separate the work-adjacent identity from the personal one.
• Sequential numbers. user123, user124, and user125 are the same identity to anyone who notices the pattern. Number suffixes only help if they’re drawn randomly (or, for blend mode, from a constrained set like “year”).
• Date of birth in the handle. name1989 hands an attacker a free demographic signal — useful for password-reset social engineering and for correlation across data breaches that include DOB.
• Real name verbatim. If the username equals your legal name, you haven’t picked a username — you’ve picked a search query. Acceptable for professional handles where that’s the point; reckless for anything else.

The privacy angle

A consistent handle across platforms is the cheapest possible cross-site correlation vector. No special tools, no breach data — just a Google search. Pseudonymity is a legitimate, normal practice, and the threat model that makes unique-per-platform handles worth the friction isn’t state-actor surveillance; it’s the much more common case of a recruiter pulling up your GitHub from your Discord username, or a stalker mapping a personal photo dump from your gaming handle.

The point of generating usernames in batches and rolling them frequently isn’t paranoia. It’s recognising that the cost of changing a handle on most platforms is higher than the cost of picking a good one once. Username scarcity is one of the few security problems where the right move is upstream: pick well, write it down in your manager, move on.