You named it test2. Or NewProject. Or myapp, because it was 11pm and you just needed something to type after git init. Eighteen months later that repo has forty stars and three contributors who found it through your README. And you still type myapp into your terminal every day. It sits in your npm lsoutput next to packages with actual names. You mentioned it once at a meetup and watched someone's eyebrow twitch. We've all got a test2 that became the production app somehow.
Why your repository name matters more than you think
It's tempting to treat a repo name as a placeholder you'll fix later. You won't. And the name does more work than you'd expect.
First, GitHub's own search ranks the repository name heavily. Search for “react query cache” and a repo called react-query-cache-manager surfaces near the top. A repo called project-xyzwith the exact same code, README, and stars does not, GitHub's search algorithm weights the name field far above the description or topics.
Second, your repo name lives in a URL that Google indexes. If you ship GitHub Pages, a wiki, or just rely on people finding the repo through search, a URL like github.com/you/myapp ranks worse for relevant intent than github.com/you/csv-to-json-converterranks for “csv to json converter.”
Third, and this is the one people underrate, the name shows up everywhere, every day. Clone commands. CI config paths. package.json. Docker image tags. Conference slide decks. A bad name is a small tax you pay dozens of times a day for the life of the project.
The universal standard, lowercase kebab-case
There's one naming convention that's become the de facto standard across nearly every popular GitHub repository: lowercase kebab-case. All lowercase letters, words separated by single hyphens, no underscores, no camelCase, no spaces.
^([a-z][a-z0-9]*)(-[a-z0-9]+)*$That regex is roughly what valid kebab-case looks like. The reasons it won are practical, not aesthetic. URLs are case-sensitive on some systems and case-insensitive on others, lowercase sidesteps the ambiguity entirely. Windows treats MyApp and myappas the same path; Linux doesn't, and that mismatch has broken more CI pipelines than anyone wants to admit. Hyphens are also safer in a shell than underscores or spaces, which need escaping or quoting. And GitHub itself follows this convention for nearly every tool it ships.
If you want a shortcut, our GitHub repository name generator will turn a one-line description into compliant kebab-case names, so you don't have to manually convert anything.
The 7 rules for naming a repository
1. Be specific about what the repo does
A repo name should answer “what does this do?” without forcing anyone to open the README. react-table-virtualizedtells you exactly what you're getting. my-apptells you nothing; it could be a todo list or a payments platform. Specificity isn't about being verbose, it's choosing words that describe the function, not the fact that the repo exists.
2. Use hyphens, not underscores or spaces
git clone https://github.com/you/data_analysis_tool.git
git clone https://github.com/you/data-analysis-tool.gitBoth work. But hyphens read faster, match URL conventions everywhere else on the web, and match what most developers expect. Underscores are a holdover from languages where they're idiomatic for variable names, not repo names.
3. Keep it under 3–4 words when possible
Look at the most popular tools in any ecosystem, prettier, husky, lodash, zod, vite, and you'll notice they're almost all one word. Short names are easier to type and easier to say out loud in standup. Once a project gets traction, the README does the explaining; the name just needs to be memorable enough to find again.
4. Match the package or binary name if applicable
If your repo ships an npm package, a Python package, or a CLI binary, the repo name should match it exactly. babel/babel, pallets/flask, and denoland/deno all keep the org, repo, and package name in lockstep, so a developer who finds the package recognizes the GitHub repo instantly, and vice versa.
5. Avoid version numbers in the name
repo-v2 and api-client-2024are anti-patterns. They lock a version into a name that's supposed to outlive it. When v3 ships, you're stuck renaming again or living with a number that's permanently wrong. Git already has tags and releases for this, use v2.0.0 as a tag, not as a name suffix.
6. Think about GitHub search keywords
GitHub's search treats the repo name as one of its strongest ranking signals. Before committing to a name, think about what someone would actually type to find a tool like yours, “rate limiter,” “csv parser,” “auth middleware,” and work those real terms in. A clever or abstract name might feel unique, but it's invisible to anyone searching for what the tool does.
7. Be consistent across your organization
If you maintain multiple repos under one org, pick a pattern and stick to it, {org}-{service}, e.g. acme-billing-api, acme-auth-service. Consistency makes your repo list scannable and saves new contributors from guessing which repo handles what.
Good and bad GitHub repo names: real examples
Abstract advice is easy to nod along to and hard to apply at 11pm when you just want to ship. Here are seven real before/after examples and what makes the “after” version work.
| Bad | Good | Why |
|---|---|---|
| my-app | note-sync-api | Describes the actual function instead of just existing |
| NewProject | browser-extension-boilerplate | States what kind of project it is, ready to scaffold from |
| test2 | react-form-validator | Replaces a meaningless placeholder with the library's actual purpose |
| api-client-v2 | stripe-webhooks-handler | Drops the version, names the integration it actually handles |
| sams-api-2021 | csv-to-json-converter | Removes the personal name and date, keeps what matters to a stranger |
| repo-2 | markdown-preview-cli | Swaps a counter for a description of the tool's interface |
| myFirstApp | auth-middleware-express | Drops camelCase and personal framing, states the framework and function |
Notice the pattern: every “bad” example describes the author's relationship to the project (my, sams, First) or its lifecycle (v2, 2021, 2) instead of its function. The “good” column never mentions who built it or when, it only answers what does this do and, where relevant, what stack it's built for. If you're staring at a blank “repository name” field, try finishing this sentence first: “this repo lets you ___.” Whatever fills the blank is probably your name, just add hyphens.
When and how to rename an existing repository
Renaming a repo feels riskier than it is. GitHub automatically redirects the old URL to the new one, clones, web links, and git pushto the old remote keep working for a long time after the rename. That safety net is real, but it's not a reason to skip the cleanup.
- 01Rename the repo in GitHub settings.
- 02Update your local remote so you're not relying on the redirect indefinitely.
- 03Update any file that hardcodes the old name, package.json, Cargo.toml, go.mod, Dockerfiles, and CI/CD configs.
- 04Update README badges and documentation links that point to the old URL directly rather than through the redirect.
git remote set-url origin https://github.com/you/new-name.gitDo this in a normal PR, not a panic. The redirect buys you time, it doesn't mean you can ignore the references forever, since GitHub can eventually reassign a stale redirected name if it's ever freed up.
Naming conventions for monorepos
A monorepo has exactly one repository name but can contain dozens of individual packages, so the naming problem splits into two layers.
The repo itself gets named after the org or top-level project, facebook/react, vercel/next.js. No need to over-engineer this part; it's the umbrella name people will recognize.
The packages inside get scoped names instead, typically using your package manager's namespace feature, @org/package-name in npm, or a directory path like packages/auth, packages/ui. The scoping does the disambiguation work the repo name doesn't need to.
As for the -monorepo suffix: babel/babeldoesn't use it, but you'll see it on projects that started as a single package and later merged others in, like microsoft/fluentui. If the monorepo nature is core to how people find and understand the project, the suffix earns its place. If it's incidental, skip it.
Name your next repository the right way
Lowercase, kebab-case, and specific enough that it answers “what does this do?” without anyone opening the README. Match your package or binary name if you have one, skip the version numbers, and keep it short enough to type without thinking.
If you'd rather skip the brainstorming, our GitHub Repository Name Generator turns a one-line description into eight ready-to-use, convention-following names in a few seconds.
Frequently asked questions
Should GitHub repository names be lowercase?
Lowercase isn't enforced by GitHub, but it's the convention nearly every project follows for good reason. Kebab-case, all lowercase, words joined by hyphens, is URL-safe, shell-safe, and avoids the case-sensitivity mismatches between Linux and Windows/macOS that have broken more than a few CI pipelines.
What is the best format for a GitHub repo name?
Lowercase kebab-case is the standard: words in lowercase, separated by single hyphens. Avoid spaces, underscores, camelCase, and PascalCase, and skip version numbers entirely. If the repo ships a package or binary, match that name exactly so the repo and the package are easy to connect.
Can you have spaces in a GitHub repository name?
GitHub will automatically convert spaces to hyphens when you create the repo, but don't rely on that behavior. Spaces break terminal commands, CI/CD config references, and documentation links the moment anyone uses the literal name instead of the auto-converted one.
How long should a GitHub repository name be?
Two to four words is the sweet spot. Many of the most-starred repos on GitHub, vite, zod, prettier, husky, are just one to three words long. If your name needs more than four words to make sense, that's usually a sign the project's scope needs narrowing, not that the name needs more detail.
Is it bad to rename a GitHub repository?
No, GitHub automatically redirects the old URL to the new one, so existing clones and links keep working. You'll still want to update your local git remote, CI/CD configs, package.json references, and README badges, but that's a five-minute cleanup, not a risky migration.
What are good GitHub repository name examples?
react-form-validator, csv-to-json-converter, auth-middleware-express, and browser-extension-boilerplate are all solid examples, each one tells you exactly what the project does without requiring anyone to open the README first. That's the bar every repo name should clear.