GitHub Repo Name Generator
Generate clear repository-name ideas designed to work well as lowercase, hyphenated slugs.
$ Fill in the fields above and hit Generate
A GitHub repo name generator is an AI tool that suggests clean, descriptive repository names based on what your project does, its language, and its type. It follows GitHub's own conventions — lowercase, hyphen-separated — so the result is ready to drop straight into git init without reformatting.
How to approach naming a repository
A repository name lives in more places than most people account for: the clone URL, every terminal command run against it, the browser tab when it's open, the search results when someone looks for it, and every conversation where a teammate mentions it by name. Optimize for the version of the name that gets typed and said most often, not the version that looks best in a slide deck.
If the repo is part of a larger organization or a monorepo split across services, think about the naming pattern before the individual name. A consistent convention across repos pays off every time someone browses the org's repo list looking for the right one.
Repository naming strategies
Readable, lowercase slugs
GitHub repo names get typed into a terminal far more often than they're read on a page — in git clone, in npm install, in a CI config. Lowercase words separated by single hyphens, with no double hyphens or trailing punctuation, are the fastest to type correctly and the easiest to remember exactly.
- ›next-auth-starter — reads clearly, types cleanly
- ›json-schema-to-ts — descriptive without extra punctuation
Tech-scoped prefixes for discoverability
Prefixing a repo with its language or framework — go-, react-, eslint-plugin- — helps it read correctly when browsing an org's full repo list, and matches conventions some ecosystems actively expect (an ESLint plugin, for instance, is commonly expected to start with eslint-plugin-). Use this deliberately, not on every repo, or the prefix stops adding information.
- ›go-http-router — signals language and purpose immediately
- ›eslint-plugin-import — matches an ecosystem-specific naming convention
Consistent conventions across an org or monorepo
If the repo is one of several related services under the same organization, a shared naming pattern — service-auth, service-billing — makes the whole repo list easier to scan than a set of ad hoc names invented independently by whoever created each one.
- ›service-auth, service-billing, service-notifications — one pattern, easy to scan
- ›authservice, Billing_API, notifs-svc — inconsistent, harder to navigate
Alignment between repo, package, and command names
If the repo will be published as a package or exposes a CLI binary, keep the repo name, the package name, and the command someone types either identical or predictably related. A mismatch means someone who finds the GitHub repo has to guess what to actually install or run.
- ›repo create-react-app → package create-react-app → command npx create-react-app
- ›repo json-to-ts → package json-to-ts → command jsontots (documented clearly)
Common repository naming mistakes
Mixing hyphens and underscores inconsistently
A name like my_project-utils looks unprofessional and is genuinely harder to type correctly, since the two separators aren't interchangeable in a URL or a shell. Pick hyphens and use them everywhere in the name.
Over-abbreviating for length
A repo name like jstts-cvtr-v2 saves a few characters but only makes sense to the person who wrote it. It's harder to search for, harder to remember, and harder for contributors to explain to someone else.
Choosing a name so generic it collides constantly
Names like utils, helpers, or my-app exist thousands of times over across GitHub. They're impossible to search for reliably and get confused with unrelated projects the moment anyone tries to reference yours by name alone.
Forgetting the name lives inside a clone command
The repo name becomes part of every git clone command and every terminal history entry anyone who works on it will ever type. An overly long or awkward name creates friction that compounds across the life of the project.
Before you create the repository
- ›Search the exact name, and close variants, on GitHub before creating the repo.
- ›Check GitLab and Bitbucket too, in case the project ever mirrors or moves.
- ›Search the relevant package registry — npm, PyPI, crates.io, Packagist — for the same or a similar name.
- ›Search a trademark database if this will be a branded, commercial project.
- ›Check whether an established project in the same ecosystem niche already uses the name.
- ›Type the full clone command once to see how it reads and feels in practice.
NameKit does not check GitHub, GitLab, Bitbucket, or any package registry for availability. Examples above are illustrative, not a claim that a specific slug is unused. Search for the name yourself before creating the repository.
How it works
Describe your repository
Enter what your project or tool does, any relevant keywords, and the language or framework it uses.
AI generates repo names
The model produces 8 lowercase, hyphenated name suggestions that follow GitHub conventions and reflect your project's purpose.
Check before you create the repo
Copy your preferred name, then search GitHub and your package registry for conflicts — see the checklist below before you push your first commit.
Related tools and guides
If you're naming the project itself rather than just the repo slug, start with the project name generator and derive the repo name from there. For the full set of conventions GitHub repos are expected to follow, see NameKit's guide to GitHub repository naming, and if you'll be publishing a package from this repo, cross-check it against the npm package naming rules.
Frequently asked questions
Should I use hyphens or underscores in a GitHub repo name?
Hyphens are the standard convention — my-project, not my_project. They're easier to read at a glance, match how most package registries expect names to look, and avoid the visual ambiguity of underscores in some fonts and terminals.
Does the repo name need to match the package I publish from it?
Not strictly, but it should be close. If the repo, the published package, and any CLI command it exposes all use different names, people who find one have to guess at the others. Keeping them identical or predictably related — repo json-to-ts, package json-to-ts, command jsontots — removes that guesswork.
Will NameKit tell me if a repository name is already taken on GitHub?
No. NameKit does not check GitHub, GitLab, Bitbucket, or any package registry for existing names. A suggested slug may already be in use as a repository or a published package — search for it directly before you create anything.
How long should a repository name be?
Roughly 10–30 characters is a practical range. Long enough to be descriptive and to avoid collisions within your own organization or profile, short enough that it doesn't get visually truncated in a terminal, a clone URL, or GitHub's own repo list UI.