DataToolsLab
Git & Dev Utility Tools

GitHub URL Parser

Extract owner, repository, ref, path, PR or issue number and line range from any GitHub URL.

Loading tool…

What is GitHub URL?

A GitHub URL parser. Paste any link — a file on a branch, a pull request with a line anchor, a compare view, a gist, an SSH clone URL — and it breaks the URL into the fields you need for an API call, a script or a review comment.

How it works

The URL is split into host, owner, repository, path segments, query string and fragment. The URL type comes from the first path segment, then anchors are decoded into line ranges, issue comments, diff ids or in-page sections. Because a branch name may itself contain slashes, the ref/path split is resolved against a list of branch names you provide, and when it is still ambiguous every possible split is listed instead of one being guessed silently.

  1. Paste or fill in the input. Drop in a commit message, a diff, a package.json, a path list or a set of options. The tool reads it locally — nothing is uploaded and no repository is contacted.
  2. Adjust the rules to match your project. Every linter here takes its convention from a setting you can change: allowed commit types, header length, target branch length, known branch names. Set them once to what your team actually uses.
  3. Copy the result. Generated files copy straight to the clipboard or download as a real file with the right name (.gitignore, CODEOWNERS, LICENSE, COMMIT_EDITMSG), and Reset returns every field to its default.

Examples

A commit message that fails CI

"Updated(auth): Fixed the expired-token redirect." is rejected by release automation and reported here with the exact reasons: unknown type, capitalised description, past tense and a trailing period.

A .gitignore that only half works

The Checker shows which rule decides a path — and why `!keep.txt` inside an ignored directory never fires, the mistake that sends people to Stack Overflow.

A dependency bump nobody reviewed

The package.json Diff separates added, removed and changed entries per section, so a caret bump of a runtime dependency does not hide inside a lockfile-sized pull request.

A diff pasted from a code review comment

The Diff Viewer understands several `diff --git` blocks, mode-only changes, renames and binary stubs, and calls out a pasted `--stat` summary instead of rendering an empty box.

Common mistakes

Committing a .gitignore without checking it

Rules look right and behave differently: a pattern containing a slash is anchored to the root, a trailing slash means directories only, and a file inside an ignored directory cannot be re-included. Check the paths that matter before you commit the file.

Rewriting published history

A clean commit history is worth having, but amend, rebase and filter-repo change commit hashes. Only rewrite commits that nobody has pulled; after a rewrite, push with --force-with-lease rather than --force.

Treating a generated file as if it were reviewed

These tools produce a starting point, not a decision. Check the licence text against the canonical source, read the security policy before publishing it, and make sure a CODEOWNERS team actually exists — GitHub silently ignores rules whose owner has no write access.

Putting slow checks in a pre-commit hook

A hook that takes 30 seconds gets bypassed with --no-verify within a week, and then it protects nothing. Keep pre-commit to formatting and linting, move type checks and tests to pre-push or CI.

Frequently asked questions

What are the three dots in /compare/main...feature/x?

A three-dot compare uses the merge base, so it shows only what the feature branch adds. Two dots compare the two endpoints directly, which includes changes that landed on main since the branch was created.

How do I get the raw file contents?

Replace github.com with raw.githubusercontent.com and drop /blob — the parsed result includes the raw URL ready to copy, or use the /raw/ redirect on github.com.

Why is the branch/path split ambiguous?

A URL like /blob/release/v1.4/docs/x.md could mean branch `release` with path v1.4/docs/x.md, or branch `release/v1.4` with path docs/x.md. GitHub resolves it internally; this tool lists the candidates and uses your known branch names when you supply them.

Online