/^/
MediumWeb5 min read

GitHub URL Regex

Matches a GitHub repository URL and captures the owner and repository name, optionally allowing a deeper path like a file or branch.

#url#github#web#validation#developer-tools

Regex Pattern

^https?:\/\/(?:www\.)?github\.com\/([\w.-]+)\/([\w.-]+)(?:\/.*)?$

Pattern Breakdown

Hover over a token to see what it does.

^https?:\/\/(?:www\.)?github\.com\/([\w.-]+)\/([\w.-]+)(?:\/.*)?$
TokenMeaning
^Anchors the match to the start of the string
https?Matches http or https
:\/\/Literal :// scheme separator
(?:www\.)?Optional www. subdomain prefix
github\.com\/Literal github.com host followed by a slash
([\w.-]+)Capture group 1: the repository owner (user or organization) name
([\w.-]+)Capture group 2: the repository name
(?:\/.*)?$Optional trailing path such as /blob/main/file.js, then end of string

Detailed Explanation

What it does

This pattern validates that a string is a GitHub repository URL of the form https://github.com/owner/repo, capturing the owner and repository name, and optionally allows any additional path such as a branch, file, or issue reference.

Why it works

The owner and repository segments are matched with [\w.-]+, which covers the characters GitHub permits in usernames, organization names, and repo names (letters, digits, underscores, dots, and hyphens). Requiring exactly two slash-separated segments after the host, followed by an optional trailing (?:\/.*)?, distinguishes a real owner/repo URL from a bare user profile URL (only one segment) while still accepting deep links into a repo's file tree or history.

Common use cases

  • Validating a 'repository URL' field in a project submission or portfolio form
  • Extracting the owner and repo name from a pasted GitHub link to call the GitHub API
  • Filtering a list of URLs to find only those that reference a specific repository
  • Normalizing GitHub links before storing them, stripping deep paths down to the repo root

Edge cases

  • Deep links like https://github.com/facebook/react/blob/main/README.md are matched, with the extra path captured by the trailing optional group
  • URLs with only an owner and no repository, like https://github.com/torvalds, are rejected because a second path segment is required
  • The bare host with no path, https://github.com/, is rejected since neither capture group has any characters to match
  • www.github.com is accepted alongside the bare github.com host
  • GitHub Enterprise or self-hosted GitHub instances on other domains are not matched since the host is hardcoded to github.com

Limitations

  • Does not verify that the referenced repository actually exists or is publicly accessible
  • Does not distinguish between organization and personal accounts, since GitHub uses the same URL shape for both
  • Repository names containing characters GitHub itself would reject are not filtered out, since the pattern is permissive about valid-looking characters

Interactive Tester

Edit the pattern or text below — matching runs live in your browser.

https://github.com/facebook/react https://github.com/torvalds/linux http://github.com/user/repo/blob/main/file.js

Test Cases

Editable — add your own inputs to see if they pass.

InputExpectedResult
Pass
Pass
Pass
Pass
Pass
Pass
Pass

Language Variants

Production-ready examples in 12 languages.

const githubUrlRegex = /^https?:\/\/(?:www\.)?github\.com\/([\w.-]+)\/([\w.-]+)(?:\/.*)?$/;
const m = 'https://github.com/facebook/react'.match(githubUrlRegex);
console.log(m[1], m[2]); // 'facebook' 'react'

Common Mistakes

Matching only github.com/owner and treating it as a valid repository URL

Fix: Require two path segments so profile URLs (owner only) are distinguished from repo URLs (owner/repo)

Hardcoding the trailing path to a specific format like /blob/branch/path, breaking on issue or pull-request URLs

Fix: Use a generic (?:\/.*)? to accept any trailing path rather than a specific sub-pattern

Forgetting gist.github.com and raw.githubusercontent.com are different hosts that this pattern won't match

Fix: Write separate patterns for GitHub's other subdomains if those URL types need to be recognized

Performance Notes

  • The two [\w.-]+ capture groups are bounded by the surrounding slashes, so backtracking is minimal even for long owner or repo names
  • The optional trailing (?:\/.*)? uses . which can be slow on very long paths with many slashes, but is safe since it's the last thing checked before $
  • Anchoring with ^ and $ avoids scanning arbitrary substrings for a match when validating a full URL string

Browser Compatibility

EngineSupportedNotes
ChromeYes
FirefoxYes
SafariYes
EdgeYes
Node.jsYes