Fix Home and End Keys on Mac to Work Like Windows

Coming from Windows, the first thing your fingers notice on a Mac is that Home and End don't go to the start and end of the line — they scroll to the top and bottom of the whole document, without even moving the cursor. Nothing is broken; macOS just assigns those jobs to different keys. You have two options: learn the Mac equivalents (five minutes) or remap Home and End system-wide with a small text file (also five minutes, no third-party software).

What Mac keys do the same job

• Cmd+Left / Cmd+Right — start and end of the line. This is the direct Home/End replacement.
• Cmd+Up / Cmd+Down — start and end of the document, cursor included (what Ctrl+Home/End does on Windows).
• Add Shift to any of those to select as you jump — Shift+Cmd+Right selects to the end of the line.
• On a MacBook keyboard, Fn+Left and Fn+Right are Home and End — which means they scroll without moving the cursor, exactly like the dedicated keys on a full-size keyboard.

If you can retrain the habit, the native shortcuts are worth it: they work in every app with zero configuration. If you switch between a Mac and a PC all day, remap instead.

The scroll-without-moving behavior isn't a bug, incidentally — macOS treats Home/End and the paging keys as viewing keys and reserves cursor movement for the Cmd and Option combos. Once you know the split exists, both halves are predictable.

Remap Home and End system-wide

macOS's text system reads custom key bindings from ~/Library/KeyBindings/DefaultKeyBinding.dict. The file doesn't exist by default — you create it once and it applies to every app built on the standard text system.

# create the folder, then open the new file in TextEdit
mkdir -p ~/Library/KeyBindings
touch ~/Library/KeyBindings/DefaultKeyBinding.dict
open -e ~/Library/KeyBindings/DefaultKeyBinding.dict

Paste this in and save:

{
    "\UF729"  = moveToBeginningOfLine:;
    "\UF72B"  = moveToEndOfLine:;
    "$\UF729" = moveToBeginningOfLineAndModifySelection:;
    "$\UF72B" = moveToEndOfLineAndModifySelection:;
}

\UF729 is the Home key, \UF72B is End, and $ means Shift — so the last two lines give you Windows-style Shift+Home/Shift+End selection. (The file format also understands ^ for Control, ~ for Option, and @ for Command, if you ever want to bind other combos.) Apps read the file when they launch, so quit and reopen anything you're testing in — no restart or logout needed.

If a binding seems ignored, the usual culprit is a formatting slip: every line inside the braces ends with a semicolon, and the key codes keep their quotes exactly as shown. Fix the file, save, and relaunch the app again.

To undo, delete the file and restart your apps:

# undo the remap
rm ~/Library/KeyBindings/DefaultKeyBinding.dict

Where the remap works — and where it won't

DefaultKeyBinding.dict covers apps using the native Cocoa text system: TextEdit, Notes, Mail, Safari and most text fields in Mac apps. It does not reach apps that implement their own text engines:

• Terminal — set key mappings in Terminal's own Settings → Profiles → Keyboard instead.
• Microsoft Office — Word and Excel handle Home/End themselves (and already behave Windows-style in most views).
• VS Code, JetBrains IDEs, and other Electron or Java apps — each has its own keymap settings, and most already treat Home/End the Windows way.

In practice that split works out fine: the apps that ignore the file are mostly the ones that already do what Windows switchers expect.

Switching from Windows?

Home and End are usually the first friction point, not the last. See how to use a Windows keyboard on a Mac for remapping Ctrl/Alt/Win to their Mac counterparts, and Page Up and Page Down on a Mac for the rest of the navigation cluster.