Keyboard Shortcut for Word Finder: Which Key Does What

Asking for the keyboard shortcut for word finder gets a different answer depending on which of three jobs is meant. Finding a word inside the document that is open. Finding a word somewhere on the Mac, in a file that is not open and whose name is not remembered. Or looking up what a word means without leaving the page. All three have keys, they are not the same key, and one of them changes meaning entirely depending on which window is in front. Sorting that out first is faster than trying combinations until something happens.

The same key, two completely different behaviours

Command-F is documented as the shortcut to find items in a document or open a Find window. In a text editor, a browser, or a PDF viewer, it opens a search field scoped to what is on screen.

Put a Finder window in front and press the same keys, and something else happens. Apple lists Command-F under Finder shortcuts as: start a Spotlight search in the Finder window. Nothing is being searched inside a document, because there is no document. The window becomes a file search across whatever scope Finder is configured to use.

This is the single most common source of confusion around this shortcut. A key learned in one app appears to break in another, when in fact it is doing exactly what it is documented to do in each. The rule is simply which window is frontmost.

Two related keys are worth having at the same time. Command-Space shows or hides the Spotlight search field, and Option-Command-Space performs a Spotlight search from a Finder window. The second is the one that gets forgotten, and it is the fastest route from anywhere on the system into a file search.

Finding a word inside what is already open

Once the Find field is open, the useful part is moving through the matches rather than reopening the field for each one. Command-G finds the next occurrence of the item previously found, and Shift-Command-G finds the previous one. Both work with the Find field closed, which is the point: search once, then walk the document with two fingers.

Two more keys are worth knowing and are easy to miss. Control-Command-D shows or hides the definition of the selected word, which answers the reading of word finder that has nothing to do with searching. Command-Semicolon jumps through misspelled words in the document, which is a different kind of word hunting and the fastest way to sweep a draft.

The Find submenu under Edit is where the rest lives. Apps built on the standard macOS text system usually list several commands there, including one that takes the currently selected text and uses it as the search term, so a word can be highlighted and searched without retyping it. The key next to each command in that menu is the authoritative answer for that specific app. Reading it takes two seconds and is more reliable than any list, because every app is allowed to differ. Microsoft Word, for example, keeps Command-F for Find but puts Find and Replace on a different combination than the one used by Apple's own apps.

Reading the key off the menu instead of memorising it

Every list of shortcuts, including this one, is out of date for some app on some Mac. The menu bar is not. Any command that has a key shows that key on the right of its menu item, written with the modifier symbols: ⌘ for Command, ⌥ for Option, ⌃ for Control, ⇧ for Shift. Opening Edit and hovering over Find takes less time than searching for an answer.

The Help menu makes this faster still. Typing part of a command name into the Help menu search field lists matching menu items, and hovering over a result opens the menu it lives in and points at it. That works for commands buried three submenus deep, and it works in apps whose menus are organised unusually. For anyone trying to establish what a specific app calls its find command, which matters later when assigning a custom key, this is the reliable route.

One caveat applies to both. A menu item that is dimmed has no key that will do anything, because the command is unavailable in the current context. A Find command dimmed in a PDF viewer usually means the document has no searchable text, not that the key is wrong.

What the key cannot reach

The Find field searches what the app has loaded. That sounds obvious until it is not.

A PDF opened in a viewer is searchable only if it contains a text layer. A scanned page is an image, and no Find key will match a word printed on it unless text recognition has been run over it first. A long web page that loads content as it scrolls will only match what has actually loaded. A log file opened in an editor that streams from disk may only search the portion in memory.

In each of those cases the key is working correctly and the content simply is not there to be matched. The check is always the same: if a word is visible on screen and Find does not match it, the text is not text.

There is a subtler version of the same failure. Some Find fields match only whole words, some match any substring, and a few ignore accents and case while others do not. A search for a name with a diacritic can return nothing in one app and everything in another, on the same file. Where an app offers options next to the search field, such as ignore case or whole word, they are worth setting once rather than being blamed later for a missing match.

Composed characters cause the same effect at the system level. The same visible character can be stored either as one code point or as a base letter plus a combining mark, depending on which device or service produced the file. Text typed by hand will match one form and not the other, which is why a word that clearly exists in a filename sometimes refuses to be found.

Finding a word across files rather than inside one

This is the second job, and the keys are different because the question is different. Nothing is open, so nothing can be scanned.

Goal	Key or command	What it searches
Word in the open document	Command-F	The loaded document only
Next match in the same document	Command-G	The loaded document only
Word in files on this Mac	Command-Space	The Spotlight index
Word in files, from a Finder window	Option-Command-Space	The Spotlight index, in a window
Word in a folder tree, right now	grep -rn	The files themselves

The first four all rely on the index. When a word is typed into a Finder search field, a menu appears offering to match it against the filename or to treat it as a general term, and the general term includes the text content of indexed formats. Choosing filename when the word is inside the document, or the reverse, is why the same search can return four hundred results one time and zero the next.

There is a third option in that menu that gets missed. Adding a criteria row and setting the attribute to Contents restricts the match to the text inside files, ignoring names entirely. That is the setting to reach for when a word appears in dozens of filenames and the goal is the one document that discusses it. The reverse case, where the word is in the name and the contents match is noise, is handled by choosing the Name option instead.

The last row is the one that does not use the index at all. grep -rn word . reads the files directly, so it finds text in formats the indexer never learned, in files that were excluded from indexing, and in anything written seconds ago. It is slower on large trees and it has no idea what a PDF is. The two approaches fail in opposite directions, which is why keeping both is worth more than choosing one.

When an app has no Find key of its own

Some apps do not expose Find on a key, or bind it to something that collides with an input method. macOS allows a key to be attached to any existing menu command.

The route is System Settings, then Keyboard, then Keyboard Shortcuts, then App Shortcuts. Pick the application, or All Applications for a command that appears in many of them, then type the menu command exactly as it is written in the app. Exactly matters: an ellipsis has to be entered as three periods with no spaces, and a submenu path is typed with -> between the levels. A command written as File then Export as PDF becomes File->Export as PDF... in that field.

The limitation is stated plainly in Apple's documentation: shortcuts can only be created for menu commands that already exist. If an app has no Find item in any menu, no key can be assigned to it. Some apps also decline to accept custom shortcuts at all.

This is also the fix for a shortcut that stops working after adding a second input language, since some system combinations get taken over for switching input sources. Reassigning the conflicting one is quicker than living with it.

Where the key stops paying off

Finding the word is rarely the end of the task. The word was a way of locating something, and what follows is the actual work: opening the file, checking whether it is the right one, doing the same thing to the eleven other files that also matched, and moving them somewhere.

That part has no shortcut, and it is where the time goes. A search that returns forty hits across a project tree turns into forty small acts of carrying, since the result list is in one place, the shell command that would process them is in another, and paths get moved between the two by hand. Cutting that carry is the whole reason a directory listing and a terminal in the same window exist, which is the case set out in Features and measured against the alternatives in Compared with other file managers. Details on which interface languages are covered are in Languages.

The second limit is one of scale. Keys make one repetition faster. They do not make forty repetitions into one operation. Once the same find and act sequence is being repeated more than a handful of times, the answer is a command that takes a list, not a faster finger.

What to change first

Learn Command-G and Shift-Command-G, since walking matches without reopening the Find field is the change with the highest ratio of benefit to effort. Then decide deliberately whether a given search is inside one document or across many files, because picking the wrong one wastes more time than any key saves. If the answer is usually across many files and the next step is usually a shell command, a file manager with a terminal in the same window such as Atriens removes the step that no shortcut can.