Middle click on a Mac trackpad: what actually works

macOS has no middle click. Not a hidden setting, not a defaults write, not a checkbox in System Settings. A trackpad has one physical click and a two-finger click for the secondary button. Button 3 exists in the event model, but nothing maps a trackpad contact to it.

That surprises people coming from Linux or from a mouse with a wheel, because middle click is load-bearing in those environments: open a link in a new tab, close a tab, paste a selection, pan a canvas.

If you want it on a Mac, something has to synthesize the event. Here is what actually works, what fails, and how the plumbing looks if you are building it yourself.

The three approaches

There is no fourth option. Apple has never shipped a middle-click mapping for the trackpad.

What most people actually wanted

Before installing anything, check which job you were doing:

• Open a link in a new tab: Command-click does it in Safari, Chrome, Arc, Firefox, and Orion.
• Close a tab: Command-W. Reopen: Command-Shift-T.
• Paste a selection: macOS has no primary-selection buffer. This is the one that genuinely needs button 3 or a clipboard manager.
• Pan a canvas: most Mac apps use space-drag or a two-finger scroll, not middle-drag.

Two of those four have native shortcuts. If the habit is the only thing missing, the shortcut is cheaper than a utility.

How the event actually works

If you are writing the app, the relevant AppKit entry point is otherMouseDown. The button number for the middle button is 2:

override func otherMouseDown(with event: NSEvent) { if event.buttonNumber == 2 { // middle button } } 

To synthesize one, build a CGEvent and post it:

let down = CGEvent(mouseEventSource: nil, mouseType: .otherMouseDown, mouseCursorPosition: point, mouseButton: .center) let up = CGEvent(mouseEventSource: nil, mouseType: .otherMouseUp, mouseCursorPosition: point, mouseButton: .center) down?.post(tap: .cghidEventTap) up?.post(tap: .cghidEventTap) 

Two things bite immediately.

Permission. Posting events into other apps requires Accessibility access. A global monitor for the gesture that triggers it usually needs it too. Without the grant, your code runs and nothing happens, which is the worst failure mode to debug.

Targets that ignore synthetic input. Secure input fields suppress event taps, some games read HID directly, and a few apps filter events by source. Your middle click will work in Safari and do nothing in the app you actually cared about. Test there first, not in a demo.

If you are choosing a utility

Pick the gesture last. The trigger is the easy part; the conflicts are what make a trackpad utility annoying.

A three-finger tap is the usual choice, and it is also the gesture macOS uses for Look Up, and the one many apps use for drag or navigation. A corner click is less discoverable but far less likely to fire while you are selecting text. Whatever you pick, give the gesture exactly one owner: one app, one action.

Test in three places before you trust it: a browser link, a text field, and the app where you originally wanted it. If it fails in the third, the utility is not the problem; the target is.

The honest summary

• Need button 3 specifically: an input utility or a mouse.
• Want fewer reaches in the browser: Command-click and Command-W cover most of it.
• Want the trackpad to do more in general: a surface app is a better shape than a single mouse button.

I make TrackStudio, a Mac trackpad control surface with edges, corners, custom areas, per-app scenes, and haptics. It deliberately does not emulate a middle click, because that is a different job. The longer version of this post, including the settings paths and the failure cases, is here: https://trackstudio.xyz/blog/middle-click-mac-trackpad