macOS app · free
Work links to the work profile. Client links to the client one. Everything else wherever you like. BrowserRouter sits where your default browser used to and sends each link on, by a table you can read.
Free · macOS 14+ · signed and notarized by Apple
BrowserRouter never opens a page itself. It reads the link, decides, and hands it to a real browser — which is why it works with whatever you already use.
How it works
macOS sends every link to your default browser. BrowserRouter takes that job, looks the link up in your rules, and passes it to the browser that should have had it — before anything has rendered.
The obvious one, and the one most rules are.
github.com covers gist.github.com too, because
subdomains are almost always what people mean.
A substring anywhere in the link for the paths that matter —
/pull/, /admin — or a full regular expression when
a site needs splitting more finely than that.
Links from Slack to one browser, the same links from Mail to another. The app the link was clicked in is part of the rule, not a separate mode.
Any rule can open a chooser instead of deciding. Answer once with “always open this site this way” and the answer becomes a rule.
Profiles
If you keep a work profile and a personal profile in Chrome, “open it in Chrome” was never the whole answer — the link still landed in whichever window you last touched.
A rule can name the profile as well, and the link opens as the right person. Chrome, Edge, Brave, Vivaldi and other Chromium browsers list their profiles by the names you gave them.
Safari has profiles but no way to choose one when opening a link, and Firefox can only switch profiles when it is not already running. The same goes for browsers built on them — Orion follows Safari here, Zen follows Firefox. Links still route to all of them; BrowserRouter just lists profiles for the browsers where choosing one genuinely works, and none for the ones where it would only work sometimes.
http://example.com/post?utm_source=newsletter&fbclid=IwAR2…&id=7
https://example.com/post?id=7
Optional
Two switches, both off until you turn them on: drop the campaign and click
identifiers that get stapled to links, and upgrade http to
https.
Neither can change which page opens — only the scheme and the query string,
never the site, the path or the anchor. Local addresses on
.test, .local and localhost are left
alone, because a development server usually has no certificate to upgrade to.
And when a rule would send one particular link to the wrong place, hold ⌥ as you click it and pick by hand instead.
For the terminal
The rules are a file. The window is one way to edit it, and not the fastest one when the change touches twenty rules at once.
# where would this link go, and which rule decided? $ browserrouter resolve https://github.com/acme/app/pull/128 Google Chrome — Work matched: URL contains /pull/ 70dbfc33 # add a rule, at the top so it beats the general one below $ browserrouter add figma.com --browser Firefox --at 1 # bring your Finicky config across $ browserrouter import-finicky
# an MCP server, so an assistant can read and edit the table $ browserrouter mcp # eleven tools, including the one that matters: resolve_url where a link would go, without opening it move_rule reorder, because position decides which rule wins add_rule with a browser, a profile and a source app
tell application "BrowserRouter" resolve "https://figma.com/file/9Xk" --> "org.mozilla.firefox" make new rule with properties ¬ {pattern:"asana.com", browser:"com.google.Chrome"} end tell
Coming from Finicky
Point BrowserRouter at your .finicky.js and it reads it —
hostname lists, globs, regular expressions and profiles, in the order you
wrote them.
The two things it cannot express — a match written as a function,
and URL rewrites beyond the two switches above — are reported rather than
quietly dropped, so you know what to look at. It exports back the same way,
which is the honest version of asking you to switch.
Imported 26 rules from ~/.finicky.js 1 URL rewrite was skipped — BrowserRouter routes links, it does not change them.
The rest of it
It lives in the menu bar by default and never takes focus when it routes a link — which is also how it knows which app the link came from.
A JSON file in Application Support, editable in the window, in your editor, or from the terminal. Change it anywhere and the app picks it up.
No account, no server, no analytics. Recently opened links are kept in memory only and go away when you quit.
Set any browser as the default again from inside Settings. Taking over every link on your Mac should be as easy to undo as it was to do.
It’s free. Set it as your default browser, and the first link you click goes where it should have gone all along.
Download BrowserRoutermacOS 14+ · Apple silicon & Intel · signed and notarized
It decides before a page has started loading — reading a link and handing it on is the whole of the work. What you notice is the browser opening, the same as it would have anyway.
Any of them. It asks macOS which apps can handle a web link rather than carrying a list of names, so Orion, Zen, Arc or a browser you installed this morning shows up without BrowserRouter having heard of it. Profiles are the one part that depends on the engine: they work for Chromium browsers — Chrome, Edge, Brave, Vivaldi and the rest.
The link still opens. It falls through to your fallback browser, and the rules window marks the broken rule so you can fix it when you get to it.
It’s signed with a Developer ID and notarized by Apple, so it opens with a double-click — no right-click-to-open workaround.
Its whole job is launching other applications and reading the list of browsers you have installed, and neither works from inside the App Store sandbox. It is a notarized direct download instead.
Yes. Settings has a “hand back to” menu that makes any browser the default again, and uninstalling is dragging the app to the Trash.
I built BrowserRouter with heavy use of AI coding tools.
Saying so seems more useful than leaving you to guess.