# Refined GitHub: what the extension changes, and how to install it > Refined GitHub is an MIT-licensed browser extension that rewrites parts of the GitHub interface with a few hundred small features. It installs from the Chrome Web Store, Mozilla Add-ons or the Mac App Store, and every feature can be switched off individually. **refined-github/refined-github** — :octocat: Browser extension that simplifies the GitHub interface and adds useful features - Repository: https://github.com/refined-github/refined-github - Stars: 32,200 · Forks: 1,912 - Language: TypeScript - License: MIT - Published: 2026-09-10 · Updated: 2026-09-10 · Language: en - Canonical page: https://hysenlabs.com/projects/refined-github-refined-github ## The problem Refined GitHub picks at The README states the motivation plainly: "We use GitHub a lot and notice many annoyances we'd like to fix. So here be dragons." That sentence carries the whole project thesis. GitHub's web interface is designed for the median user, and the median user is not someone who reads diffs for a living. The gaps Refined GitHub fills are small and concrete rather than architectural. Whitespace characters are invisible in code review until you turn them on. A directory listing does not tell you how far you are from the default branch. A long issue thread mixes comments, label changes, assignments and cross-references into one stream. None of these are bugs. They are defaults that cost a specific kind of user a few seconds, several dozen times a day. The audience follows from that. This is for people whose working day happens inside github.com in a browser tab: reviewers, maintainers, and anyone triaging issues. It is not a Git client, not a CI tool, and not a replacement for the CLI. If you mostly interact with repositories through git commands and your editor, the extension has little to offer you. The README also notes that GitHub Enterprise is supported, with a link to a separate permission-toggle page, which matters for anyone working inside a company instance rather than github.com. ## How the extension actually modifies the page The repository layout tells you most of the mechanism. The source lives in source/, the build is driven by rollup.config.js and vite.config.ts, and the interface components are Svelte files (svelte.config.js is present at the top level). The dependency list is a giveaway about the technique: dom-chef, dom-loaded, element-ready, delegate-it, doma, filter-altered-clicks. Those are DOM construction and observation helpers, not a framework for talking to an API. Refined GitHub does not proxy GitHub's data through a server of its own. It runs as a content script inside the page, waits for elements to exist, and injects or rearranges nodes. That architecture explains both the strengths and the fragility. Because the extension works against the rendered DOM, it can add a button next to an existing one without any cooperation from GitHub. It also means every feature is coupled to GitHub's markup. Two other dependencies point at the same design: github-url-detection decides which page you are on before a feature runs, and github-reserved-names keeps the extension from treating reserved paths as user or repository names. The README's feature list is organised as one entry per feature, each with a name in quotes such as "repo-age" or "default-branch-button", and each entry describes a single visible change. Features are individually addressable, which is why the extension has a settings surface at all. ## Installing Refined GitHub and turning a feature on There is no build step for normal use. The README's Install section links to three distribution channels: the Chrome Web Store for Chrome and other Chromium browsers, Mozilla Add-ons for Firefox including Firefox Android, and the Mac App Store for Safari on Mac, iOS and iPadOS. Pick the one matching your browser and install from there. The repository is the source, not the delivery mechanism. If you want to build it yourself, the repository states the toolchain requirements in package.json. Node 24 or newer is required, and the package manager is pinned. ```bash npm install npm run build ``` The build script runs several steps in parallel: svelte-check, tsc --noEmit, and the rollup bundle. For iterative work the repository provides a watch mode, which is also what npm start maps to. ```bash npm start ``` Adding a new feature has its own scaffolding script, which is the clearest sign of how the project expects contributions to arrive. ```bash npm run new ``` Once installed in the browser, the extension exposes a settings page where the feature list from the README appears as individual toggles. The README's feature entries carry stable names in quotes, for example "show-whitespace", "unreleased-commits", "pr-base-commit" and "conversation-activity-filter". Those names are what you look for when deciding what to keep. The README does not document a global on/off switch that disables everything at once, so the practical first step is to leave the defaults and disable the handful of features that get in your way. ## Where the DOM-patching approach breaks down The honest limitation is structural, and the README says it out loud in the same breath as the motivation. The project exists because GitHub has not implemented these improvements, and the stated hope is that "GitHub will notice and implement some of these much-needed improvements". Read that as a maintenance risk rather than modesty. Every feature depends on markup the project does not control. When GitHub ships a redesign, features can stop working or, worse, render something wrong in the middle of a page you are relying on for a review. The second limitation is that the extension is not a supported interface. It is not affiliated with GitHub in any operational sense; the README carries a trademark note stating that the GITHUB and REFINED GITHUB trademarks are owned by GitHub, Inc. and used under license. If your organisation has rules about which browser extensions may run against internal tooling, a DOM-rewriting extension on an enterprise GitHub instance is a conversation you need to have before rollout, not after. Third, it is the wrong tool for anything outside the browser. If your complaint is that cloning is slow, that CI is opaque, or that review requires a local checkout, Refined GitHub will not help. It only changes what you see on a github.com page. ## Refined GitHub versus a userscript manager The obvious alternative approach is a userscript manager such as Tampermonkey or Violentmonkey, where you collect small scripts that each patch one page. The difference is in packaging and maintenance, not in technique. Both approaches rewrite the DOM. A userscript setup gives you total control: you choose every script, you can edit any of them, and nothing updates behind your back. It also means you own every breakage. When GitHub changes its markup, you are the one reading the diff and fixing the selector. Refined GitHub inverts that trade. You get a curated set of features with a shared release cadence (the recent releases list shows 26.9 on 2026-09-02, following 26.8.8 and 26.7.26), a single settings page, and a maintainer who absorbs the markup churn for you. What you give up is granular control over the internals and any guarantee that a given feature matches how you would have written it. The repository also carries its own conventions: eslint-rules/, biome.jsonc, dprint.json and a CLAUDE.md and agents.md at the top level, which suggests a tightly governed codebase rather than a loose script collection. If you have exactly one annoyance to fix, a userscript is less machinery. If you want the whole set and no maintenance, the extension is the smaller commitment. ## Maintenance, releases and the MIT licence The repository is not archived, and the last push was on 2026-09-10, which is recent relative to the release cadence: 26.9 on 2026-09-02, 26.8.8 on 2026-08-08, 26.7.26 on 2026-07-26. Version numbers track the calendar, so a two-digit year and month appear in each release. That cadence is the upgrade story. Browser extensions installed from a store update themselves, so the practical maintenance cost for a user is near zero until a feature you depend on changes behaviour. For anyone building from source, the cost is different. The engines field requires Node 24 or newer, and packageManager pins npm@12.0.2, so a stale Node install will fail before anything else does. The test script runs vitest, eslint and biome alongside the build steps, which is a real gate if you intend to send patches. Note the --continue-on-error flag on the build and test scripts: a failing step does not stop the others, so read the full output rather than the exit code. The licence is MIT. In practical terms that permits use, modification and redistribution with the licence and copyright notice preserved, and it disclaims warranty. That is the standard permissive position and it is compatible with internal corporate use, but the trademark note is separate from the licence: the project states that the GITHUB and REFINED GITHUB trademarks are owned by GitHub, Inc. and used under license. If you fork and redistribute, the name is not yours to use freely. This is a description of what the repository says, not legal advice. ## Conclusion Refined GitHub suits people who live in the GitHub web UI all day and want the small annoyances gone: whitespace made visible, a link back to the default branch, a way to filter issue noise. It is the wrong tool if you need a supported, vendor-backed interface, because it patches a page GitHub can change at any time and the README itself frames the project as a request for GitHub to adopt these ideas. Before adopting it across a team, verify three things: which browser you are on, whether your organisation runs GitHub Enterprise, and which individual features you actually want enabled, since each one has its own toggle. ## FAQ ### What does Refined GitHub do? It is a browser extension that simplifies the GitHub interface and adds features, in the README's own words. The feature list includes things like making whitespace characters visible, showing how far a PR head branch is behind, and letting you hide every event except comments in an issue. ### Is Refined GitHub safe? The repository is public, MIT-licensed, and the source is in the source/ directory, so the code can be read before installing. The extension runs as a content script that modifies the GitHub page DOM rather than routing your data through a server of its own, based on the dependency list and repository layout. ### Is Refined GitHub safe to use? The README does not make a security claim, and it is not affiliated with GitHub beyond a trademark note stating that the GITHUB and REFINED GITHUB trademarks are owned by GitHub, Inc. and used under license. If your organisation restricts extensions on an enterprise instance, that is a policy question the README does not answer. ### What is refined github? It is a TypeScript browser extension published for Chrome and other Chromium browsers, Firefox including Firefox Android, and Safari on Mac, iOS and iPadOS. Its stated purpose is to fix annoyances in the GitHub interface and add useful features. ## Sources - [Issues](https://github.com/refined-github/refined-github/issues) - [License: MIT](https://github.com/refined-github/refined-github/blob/main/LICENSE) - [README](https://github.com/refined-github/refined-github/blob/main/README.md) - [refined-github/refined-github on GitHub](https://github.com/refined-github/refined-github) - [Releases](https://github.com/refined-github/refined-github/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/refined-github-refined-github