Refined GitHub: a DOM-level patch layer for GitHub's own interface

The annoyances Refined GitHub targets, and who feels them

The README opens with a blunt statement of intent: the maintainers use GitHub a lot, notice annoyances, and fix them. That is the whole scope. Refined GitHub is not a GitHub client, not a CLI wrapper, and not a replacement for the API. It is a set of edits applied to pages GitHub already serves.

The people who benefit are the ones who live in the web interface. Reviewers who need to see how far behind a PR head branch is get pr-base-commit. People triaging noisy threads get conversation-activity-filter, which the README describes as hiding every event except comments or unresolved comments in issues and PRs. Maintainers who want to know whether they are looking at the latest version of a repository get unreleased-commits. None of these are workflow rewrites. They are small, repeated moments of friction, and the extension removes them one at a time.

The README also states the project's larger hope: that GitHub will notice these improvements and implement some of them itself. That framing matters when you evaluate the project. The maintainers treat the extension as a lobby as much as a product, and the README asks users who like a change to raise it on GitHub feedback or with GitHub support. So the feature list is not a roadmap toward a permanent product. It is a list of gaps the maintainers would rather not have to fill.

How the extension patches the page

Refined GitHub is written in TypeScript and distributed as a browser extension for Chrome and other Chromium browsers, Firefox including Firefox Android, and Safari on Mac, iOS and iPadOS. The repository topics list browser-extension, chrome-extension, firefox-addon, safari-extension and userstyle, and the README's feature entries carry short identifiers such as show-whitespace, repo-age and clean-repo-filelist-actions.

That naming pattern is the clearest signal about the mechanism. Each feature has an identifier, a description of the visible change, and a screenshot or recording. The features operate on GitHub's rendered interface: for example, default-branch-button adds a link to the default branch on directory listings and files, and swap-branches-on-compare adds a link to swap branches in the branch compare view. These are additions to or rearrangements of elements GitHub already renders, not calls to a separate backend.

Because the extension ships as a browser add-on rather than a userscript, the browser controls installation, updates and permissions. The README links a separate tool, webext-permission-toggle, for enabling the extension on GitHub Enterprise, which implies the extension requests host access per site rather than assuming github.com only. The practical consequence is that the extension's correctness depends on GitHub's markup. When GitHub changes a page, a feature that targets that page can stop matching. Nothing in the README describes a stability layer between the extension and the DOM, so treat each feature as coupled to the interface it edits.

Installing it on Chrome, Firefox and Safari

There is no build step for users. The README lists three store links: the Chrome Web Store entry for hlepfoohegkhhmjieoechaddaejaokhf, the Mozilla Add-ons listing for refined-github-, and the Mac App Store app id 1519867270. Chromium browsers are covered by the Chrome listing, Firefox Android is covered by the Mozilla listing, and Safari on Mac, iOS and iPadOS is covered by the App Store listing.

The one configuration step the README documents is for GitHub Enterprise. It points to a page at fregante.github.io/webext-permission-toggle with the extension name and icon passed as query parameters, described as how to enable Enterprise support. That page exists because the extension needs permission for the Enterprise host before it can act on those pages. If you are on github.com, the store install is the whole procedure.

There is no documented config file, no environment variable, and no settings schema in the README. Feature toggles are not described here beyond the feature identifiers themselves, so anyone who needs per-feature control should check the extension's own options UI after installing rather than assume a documented configuration surface. I could not confirm from the README how individual features are enabled or disabled.

The version scheme tells you how tightly it tracks GitHub

Releases are dated rather than semantic. The three most recent are 26.9 on 2026-09-02, 26.8.8 on 2026-08-08 and 26.7.26 on 2026-07-26. The pattern reads as year plus month plus an increment, with the most recent push to the repository on 2026-09-10, eight days after 26.9.

A month-based version number is a reasonable choice for software whose main dependency is someone else's website. It does not promise API stability, because there is no API. It promises that a build exists for roughly every month, which is what you want when your code breaks because a button moved.

The cost is on the other side of the ledger. Users do not choose when to upgrade if their browser auto-updates extensions, and the README's own framing, that the project fixes annoyances GitHub has not fixed, means the extension is always chasing a moving target. If a feature you depend on disappears after a GitHub deploy, the fix arrives in the next dated release, not on your schedule. The repository was not archived at the time of writing, and the release cadence suggests active maintenance, but the cadence is the only maintenance signal available in this material.

Where Refined GitHub is the wrong tool

The clearest limitation is structural. Refined GitHub edits pages it does not own. Every feature listed in the README describes a change to GitHub's rendered output, and GitHub can change that output without notice. A feature that adds a link to a directory listing depends on the directory listing existing in a recognisable shape. When it does not, the feature is simply absent, and there is no documented fallback.

The second limitation is scope. The README's own framing is that the maintainers hope GitHub implements these improvements natively. That is an admission that the extension is a holding pattern. If you are evaluating it as a long-term platform to build internal tooling on, you are building on a layer the maintainers themselves expect to shrink.

The third is permissions. A browser extension that modifies GitHub pages needs access to those pages, which means it reads and rewrites content in your authenticated session. The README does not describe the extension's data handling, so I cannot say what it does or does not transmit. Organisations with extension allowlists should treat that as an open question to resolve before rollout, not as something the README answers.

Finally, the README's Enterprise note is a pointer, not documentation. If your team runs an older GitHub Enterprise Server, the extension's features may target markup that version does not produce. Nothing in the README states a supported Enterprise version range.

Compared with installing userscripts yourself

The obvious alternative is a userscript manager such as Tampermonkey or Violentmonkey, with scripts you pick and maintain individually. The repository's own topic list includes userstyle, which shows the maintainers think in the same vocabulary.

The difference is curation and coupling. With a userscript manager you choose each script, you own each script's breakage, and you decide what runs on which site. With Refined GitHub you install one extension, and the feature set moves as a unit under the project's release cadence. The trade is control against coordination: a userscript setup lets you pin a working version of one specific fix and ignore the rest, while Refined GitHub gives you a maintained bundle but no documented per-feature versioning.

A second difference is the permission model. A userscript manager typically holds broad access and delegates to scripts, so the trust boundary is the manager plus whatever you paste in. Refined GitHub asks the browser for access to GitHub hosts directly, and the README's Enterprise instructions exist precisely because that access is scoped per host. Which model you prefer depends on whether you would rather audit one extension or a folder of scripts. Neither is inherently safer; they fail in different places.

Licence, maintenance and what to verify before rolling it out

The project is MIT licensed. That is permissive: you can read the source, fork it, and ship a modified build, provided you keep the licence notice. Two things sit outside that grant. The README states that the GITHUB and REFINED GITHUB trademarks are owned by GitHub, Inc. and used under license, so a fork cannot simply reuse the name. And the README's sponsor section names Prisma and Frappe as supporters, with a link to sponsor or hire the maintainer, which tells you the project's sustainability rests on one person's work plus sponsorship rather than a foundation or a company. This is not legal advice; check the licence text and your own policy before redistributing anything.

Maintenance cost for a user is close to zero if you accept automatic updates, and non-trivial if you do not, because the extension's value depends on tracking GitHub's markup. The dated releases and the recent push activity suggest the project is being kept current, but the README gives no deprecation policy, no supported browser version floor, and no Enterprise compatibility matrix.

What to verify first, concretely: open the store listing for your browser and confirm it is the one the README links (Chrome Web Store id hlepfoohegkhhmjieoechaddaejaokhf, the Mozilla Add-ons refined-github- listing, or Mac App Store id 1519867270). Then check the permission prompt. If you are on GitHub Enterprise, run the webext-permission-toggle link from the README before expecting any feature to work there. If you are not on Enterprise and you only want one or two of the listed fixes, a userscript manager is the smaller commitment.

Editorial conclusion

Adopt Refined GitHub if you spend most of your day inside github.com and want concrete UI fixes such as restore-file, pr-base-commit or select-notifications, and you accept that each release tracks GitHub's markup. Do not adopt it if you need a supported API contract, if you are locked to an older GitHub Enterprise version, or if your organisation forbids extensions that read page content. Before installing, check the extension's permission prompt for the GitHub Enterprise toggle linked in the README, and confirm the version published on your browser's store matches the release you expect, since the three stores ship independently.

Official sources

1. Issues
2. License: MIT
3. README
4. refined-github/refined-github on GitHub
5. Releases