A Keyboard Symbols List for the Mac: Reading Shortcut Notation

A menu item reads ⌥⇧⌘V and the question is which four keys that is. The glyphs are not printed on most keyboards, several of them look like something they are not, and two of them are close enough to each other that the wrong guess produces the wrong command. A list solves it in ten seconds, but a list that also names the exact character behind each glyph solves it permanently, because the same characters can then be typed, searched for, and pasted into documentation.

What follows is the notation macOS uses, grouped the way it is actually encountered: the modifiers that stack on the left of a combination, the action keys that end one, and the small set of keys Apple writes out in words instead of drawing.

The modifiers, and what each glyph really is

These are the keys that appear first in a combination and never alone. Apple's shortcut documentation lists the abbreviations used in menus, and the Unicode identity of each one is worth knowing because it settles arguments.

Glyph	Key	Character	Unicode name
⌘	Command, also written Cmd	U+2318	PLACE OF INTEREST SIGN
⌥	Option, also written Alt	U+2325	OPTION KEY
⌃	Control, also written Ctrl	U+2303	UP ARROWHEAD
⇧	Shift	U+21E7	UPWARDS WHITE ARROW
⇪	Caps Lock	U+21EA	UPWARDS WHITE ARROW FROM BAR

Three of those rows catch people out. The Command glyph is not a proprietary Apple character at all: it is the place of interest sign, a looped square used on Nordic road signs long before it reached a keyboard, which is why it can be typed on any system and rendered by any font that covers the range. The Control glyph is an up arrowhead, not a caret and not a circumflex, and pasting a caret into a document that describes a shortcut produces something that looks right and searches wrong. And the Shift and Caps Lock glyphs differ only by the bar under the arrow, which is the single most common misreading in this whole list.

The Function key has no glyph of its own. Apple writes it as Fn, or as Globe on keyboards where it carries the globe legend, and it appears in that written form in menus rather than as a symbol.

The action keys that end a combination

These are the keys that come last. Several have two characters in circulation, and the difference matters when searching for a shortcut rather than reading one.

Glyph	Key	Character	Unicode name
⎋	Esc, Escape	U+238B	BROKEN CIRCLE WITH NORTHWEST ARROW
⇥	Tab	U+21E5	RIGHTWARDS ARROW TO BAR
⇤	Back Tab, Shift with Tab	U+21E4	LEFTWARDS ARROW TO BAR
⏎	Return	U+23CE	RETURN SYMBOL
↩	Return, as drawn in many menus	U+21A9	LEFTWARDS ARROW WITH HOOK
⌤	Enter on the numeric keypad	U+2324	UP ARROWHEAD BETWEEN TWO HORIZONTAL BARS
⌫	Delete, backwards	U+232B	ERASE TO THE LEFT
⌦	Forward Delete	U+2326	ERASE TO THE RIGHT
⇞	Page Up	U+21DE	UPWARDS ARROW WITH DOUBLE STROKE
⇟	Page Down	U+21DF	DOWNWARDS ARROW WITH DOUBLE STROKE
↖	Home	U+2196	NORTH WEST ARROW
↘	End	U+2198	SOUTH EAST ARROW
⏏	Eject	U+23CF	EJECT SYMBOL
␣	Space	U+2423	OPEN BOX

Two rows in that table describe keys most Mac keyboards do not have. Page Up, Page Down, Home and End exist as glyphs and as commands while being absent as physical keys on a laptop, and Apple documents the substitutes: Fn with the up arrow is Page Up, Fn with the down arrow is Page Down, Fn with the left arrow is Home, and Fn with the right arrow is End. Forward Delete is the same story, and Apple states that Fn with Delete performs a forward delete on keyboards without a dedicated Forward Delete key.

The two Return characters are worth a moment. Both appear in documentation, they are different characters, and a search for one will not find the other. The erase pair is the same trap in a nastier form, since ⌫ and ⌦ differ by the direction of a small triangle and mean opposite things.

The arrows, where two conventions coexist

The four arrow keys are the one place where Apple's own materials use more than one set of glyphs, and knowing both prevents a pointless search.

Apple's shortcut documentation abbreviates them as filled triangles: ▲ for Up Arrow at U+25B2, ▼ for Down Arrow at U+25BC, ◀ for Left Arrow at U+25C0 and ▶ for Right Arrow at U+25B6. The plain arrows ↑ at U+2191, ↓ at U+2193, ← at U+2190 and → at U+2192 are separate characters entirely, and they are what most third party documentation and many keyboard legends use. Both sets refer to the same four keys. Neither is wrong, and a document that mixes them is merely inconsistent rather than inaccurate.

The practical consequence is for anyone writing instructions for other people. Pick one set, use it everywhere, and prefer the form that matches whatever the reader will see on screen.

How to read a stack of modifiers

Order is not decoration. Apple's documentation writes multi modifier combinations in a consistent sequence, and the examples make the rule visible: Control with Shift and Command for adding a Finder item to the Dock, Option with Shift and Command for emptying the Trash without a confirmation dialog, Control with Option and Command for the power button combinations. Control comes first, then Option, then Shift, then Command, with the ordinary key last.

Reading ⌥⇧⌘V therefore gives Option, Shift, Command and V, in that written order, which is a paste variant in many applications. The order is for reading only. Apple's instruction for using any of them is the same: press and hold the modifier keys, then press the last key of the shortcut, then release everything. The example given is Command-C, where Command is held down first and C follows.

One rule constrains what can be built rather than read. When creating a shortcut in System Settings, a key can be used only once in a key combination, so a combination that asks for the same key twice is not expressible.

The keys Apple spells out instead of drawing

A surprising number of documented shortcuts use keys that have no glyph, and Apple writes these in words with the character in brackets. Recognising the pattern makes the official shortcut list searchable.

The space bar is written as Space bar, as in the combination that shows or hides the Spotlight search field. The key above Tab is written as Grave accent with the backtick in brackets, and Apple adds that the character on that key varies by keyboard. Brackets are written as Left Bracket and Right Bracket for moving between folders in the Finder. Punctuation is written out as Comma for opening the settings of the front app, Semicolon for finding misspelled words, Slash for showing or hiding the status bar in Finder windows, and Colon for the spelling and grammar window.

The top row is its own category. Apple describes the keys along the top of many Apple keyboards as carrying special symbols and functions such as brightness and Mission Control, and states that combining them with the Fn or Globe key makes them behave as F1, F2, F3 and the other standard function keys. Some of them, combined with Option, open the matching pane of system settings.

Typing these symbols yourself

Anyone writing documentation, a support reply or a team wiki needs to produce these characters rather than only read them.

There is a second reason to care about the exact code point. Support requests, bug reports and internal runbooks are all searched later, usually by someone who was not there when they were written. A runbook that says to press the up arrowhead, spelled with a caret, will not be found by a colleague searching for the Control glyph, and the shortcut that mattered stays buried in a document that technically contains it.

The Character Viewer is the supported route, and Apple documents three ways to open it: Control with Command and the space bar, Fn with E, or pressing Fn twice. From there the symbols can be searched by name, which is exactly why the Unicode names in the tables above are useful. Searching for the words in the name finds the character faster than scrolling a category.

Copying from a reference table is the other route, and it has one advantage worth noting: it guarantees the same character every time, which matters for a document that will be searched later. A glyph that looks correct but carries a different code point will not match, and that is the most common reason a search for a shortcut inside internal documentation comes back empty.

One more place the glyphs appear

Menu items are not the only surface using this notation. Keyboard shortcut lists inside applications, tooltips, onboarding overlays and printed keyboard covers all draw from the same set, and they do not always agree with each other. When a third party application shows a glyph that does not match what its own menu shows, the menu is the one to trust, because that is the string macOS itself renders from the shortcut attached to the command.

Where the notation stops describing the machine

The symbols describe keys, and keys reach menu commands. That covers the whole of macOS and every native application, and it stops at the edge of the browser.

A shortcut that belongs to a web service has no menu item behind it, so it has no notation in any menu and does not appear in any system list. It also collides: Apple documents that in Safari Command-1 to Command-8 select the first eight tabs and Command-9 selects the last one, which means the same keystroke means one thing to the browser and something else to the service loaded inside it. A person running four web services in one window has one set of tab shortcuts and four sets of application shortcuts fighting over the same keys, and no symbols list can untangle that, because the conflict is structural rather than notational.

Giving each web service its own window changes the arithmetic. The service becomes a target the system can address, its own shortcuts stop competing with tab selection, and the account signed in to one service stays separate from the account signed in to another. The way those separate spaces are arranged is set out in Workspaces, and which services are handled that way is listed in Supported apps.

What to change first

Keep one reference open while reading menus, and learn the two pairs that actually cause mistakes: ⇧ against ⇪, and ⌫ against ⌦. If shortcuts are being written for other people, copy the characters from a table rather than typing lookalikes, and pick one arrow convention for the whole document. If the collisions are coming from several web services sharing one browser window, the fix is separate windows rather than a better list, which is what a browser like SpaceDeck provides.