Finicky: rule-based browser routing on macOS

What Finicky does with the default-browser slot

Every macOS install has one default browser, and the system hands it every link from every app. Finicky takes that slot and turns it into a dispatcher. The README describes it plainly: "Finicky is a macOS application that allows you to set up rules that decide which browser is opened for every url." Once it is the default browser, clicking a Bluesky link and clicking a LinkedIn link no longer have to land in the same place.

The target user is someone who already runs two or three browsers deliberately. Work in one, personal browsing in another, a third for sites that misbehave under a particular engine. Without a dispatcher that split is maintained by hand: copy the URL, switch apps, paste. Finicky moves the decision into a file you write once and edit when your habits change. It is not a tab manager, not a session tool, and not a browser. It only picks the destination.

Handlers, rewrites and the order they run in

A configuration is a single object with three moving parts. `defaultBrowser` is the fallback when nothing matches. `handlers` is a list of match-and-browser pairs. `rewrite` is a list of match-and-transform pairs that edit the URL before it is opened.

The README's example shows the shape: a rewrite that sends `x.com/*` to `xcancel.com` by mutating `url.host`, and handlers that send `bsky.app/*` to Firefox and both `google.com/*` and `*.google.com*` to Google Chrome. Two details matter here. First, `match` accepts either a string or an array, so one handler can cover several patterns. Second, the rewrite functions receive a URL object and return it, which means the transformation is arbitrary code, not a fixed list of options.

The README states that rules can be written in JavaScript or TypeScript and can use regular expressions and custom functions. That is the real mechanism: Finicky evaluates your file, runs the matching logic, applies rewrites, and then launches the chosen browser or app with the resulting URL. The README points to the wiki for the full configuration documentation, which is where the matching semantics and the available APIs are actually specified. If you want to reason about precedence between two overlapping patterns, the README alone will not settle it.

Installing Finicky and writing a first working rule

The README gives two installation routes: download from the releases page, or install the cask through Homebrew.

brew install --cask finicky

After that, create a configuration file at `~/.finicky.js`. The README's basic example is a good starting point because it exercises both a rewrite and a handler. A minimal version that routes one site and leaves everything else alone looks like this.

// ~/.finicky.js
export default {
  defaultBrowser: "Google Chrome",
  handlers: [
    {
      match: "bsky.app/*",
      browser: "Firefox",
    },
  ],
};

With that file in place, start Finicky from Applications, Spotlight, Alfred or Raycast and allow it to be set as the default browser. The README notes that starting Finicky manually opens the configuration and troubleshooting window, which is where you confirm the file parsed and see what it decided. Click a `bsky.app` link and Firefox should come forward; click anything else and Google Chrome should.

The README also mentions an `example-config` folder in the repository and a wiki page of configuration ideas, which are the right places to look once the first rule works.

Where the configuration model gets thin

The README is an introduction, not a specification. It explicitly defers to the wiki for "available, APIs and options as well as detail information on how to match on urls." That means the most important questions a new user has, such as how a wildcard like `*.google.com*` is interpreted, whether the first matching handler wins, and how a rewrite interacts with a handler that also matches, are answered somewhere other than the README. Plan on reading the wiki before writing anything non-trivial.

The second limitation is structural. Because rules are code, a mistake in `~/.finicky.js` is a mistake in a program that runs every time you open a link. The README does not document rollback, and it does not describe what happens when the configuration file fails to parse. The troubleshooting window is the stated place to look, but there is no documented safe mode and no documented way to bypass Finicky for a single link from the configuration side. If your routing logic is wrong, the symptom appears as the wrong browser opening, which is easy to notice and easy to misdiagnose.

Third, this is macOS only. The README describes a macOS application, and the Homebrew cask is a macOS cask. Nothing here suggests another platform is supported.

Finicky versus a browser prompter

The README itself points at Browserosaurus by Will Stone, "an open source browser prompter for macOS," and says the two "work really well together." The difference in approach is the whole point of choosing between them.

Browserosaurus asks. You click a link, it shows you a list of browsers, you pick one. That is the right tool when the decision depends on context you only know at the moment of clicking, and it costs you a keystroke every time. Finicky decides. You encode the rule once and the link opens without a prompt, which is the right tool when the decision is stable: this domain always goes there. The failure modes are mirror images. A prompter is slow but never wrong about intent. Finicky is fast but only as correct as the rules you wrote, and a rule that is subtly too broad will quietly send the wrong things to the wrong browser until you notice.

Maintenance, licence and what the release line tells you

The repository is not archived, and the last push was on 2026-09-16, so the project is being worked on. The release history is worth reading carefully rather than skimming. The most recent tagged release in the list is v4.4.0-alpha from 2026-04-26, described as "Rules UI, Firefox profiles & window-aware routing." Before that, v4.3.0-alpha from 2025-11-19 and v4.2.2 from 2025-10-03. The alpha label on the newest line means the features named there are not presented as stable, and the README's configuration documentation is written for version 4.

That shape has a cost. If you build on the version 4 configuration format, you are building on the current line, and the README provides a migration page for people coming from Finicky 3, which tells you the two formats are not interchangeable. Read that page before copying an old configuration from a blog post.

The licence is MIT. In practical terms that is a permissive licence, and the repository ships a LICENSE file at the root. This is not legal advice; if you intend to redistribute Finicky or bundle it into something you ship, read the LICENSE file yourself rather than relying on a summary. For individual desktop use the licence question is largely academic.

Editorial conclusion

Adopt Finicky if you keep several browsers open for work and personal accounts and you are comfortable keeping a JavaScript file in ~/.finicky.js. Do not adopt it if you want to choose a browser per link by hand, or if you are not on macOS, since it is a macOS application only. Before committing, verify that Finicky can match the URLs you care about by adding one handler and checking that the intended browser opens, and confirm which Finicky version your configuration targets, because version 4 configurations differ from version 3 and the wiki covers the migration separately.

Frequently asked questions

Official sources

1. Issues
2. johnste/finicky on GitHub
3. License: MIT
4. README
5. Releases