The keyboard shortcut commonly used to underline selected text is Ctrl+U on Windows and Linux, and Command+U on macOS. Select the text, press the combination once, and the underline formatting toggles on; press it again and the underline is removed. In most rich-text editors the change applies instantly to the highlighted span only, leaving surrounding text untouched.
That single keystroke hides a surprising amount of engineering. The shortcut is a thin interface over a character-formatting model, a text-selection model, and an undo stack that all have to agree about what “selected text” means at the moment you press it. Understanding that machinery explains why the shortcut behaves differently across browsers, word processors, and code editors, and why a key that works perfectly in one app can do nothing in another.
What happens at the moment of the keystroke
When you press Ctrl+U, the operating system delivers a key event to the focused application. The application checks whether a text field or editable document has focus and whether a selection exists. If both conditions hold, it dispatches an underline command to the document model rather than inserting a literal character. This is a formatting operation, not a typing operation, which is why the underline appears under existing glyphs instead of shifting them.
Under the surface, most document models treat underline as a run-level attribute. A “run” is a contiguous stretch of text sharing identical formatting. Applying underline to a selection splits runs at the selection boundaries, sets the underline flag on the interior runs, and merges adjacent runs that now share identical attributes. A word processor may perform this split-flag-merge sequence in milliseconds, but the logic is what lets you underline the middle three words of a sentence without disturbing the rest.
The toggle behavior matters more than it appears. The application reads the underline state of the selection’s starting point: if that first character is already underlined, the command clears underline across the whole selection; if it is not, the command applies underline everywhere. Mixed selections therefore resolve to a single state based on the anchor, not on a majority vote. A plain-language way to say it: the app looks at where your selection begins and makes everything match that.
The modifier key and why it differs by platform
The Ctrl versus Command split is a legacy of two different user-interface lineages. Apple standardized the Command key as the primary shortcut modifier in the early Macintosh era, reserving Control for terminal-style and secondary commands. Microsoft’s Windows line inherited Control from the IBM PC convention. Both platforms settled on U as the mnemonic for underline, which is why the letter is stable even when the modifier is not.
This creates a predictable failure mode for people who switch platforms. A macOS user on a Windows machine will press Command+U out of habit, and nothing happens because Windows does not map the Command key. The reverse also holds. Some applications add a compatibility layer that accepts either modifier, but that is an application-level courtesy, not an operating-system guarantee.
The convention extends beyond word processors. Browsers, email clients, note apps, and even some spreadsheet cell editors honor Ctrl+U or Command+U for underline. The consistency is strong enough that the shortcut is one of the few formatting commands most users learn without consulting a menu.
Where the shortcut works and where it silently fails
Behavior diverges sharply once you leave rich-text contexts. In a plain-text field, there is no underline attribute to set, so the command either does nothing or triggers an unrelated browser action. In many browsers, Ctrl+U on a normal web page opens the page source rather than formatting anything, because the shortcut is bound to “view source” when no editable element has focus. That collision is one of the most common sources of confusion.
Code editors present another case. Most treat underline as a text-style attribute for syntax themes rather than a user-facing format, so Ctrl+U may be unbound, may map to a different command, or may be repurposed by a plugin. Terminal emulators frequently use Ctrl+U to delete from the cursor to the start of the line, a readline convention that predates modern text formatting. Pressing it in a terminal expecting an underline will delete your input instead.
Warnings worth keeping in mind:
Ctrl+U in a focused terminal often erases text to the left of the cursor, not underline. Ctrl+U on a web page with no editable focus may open page source in some browsers. Command+U behavior varies by app on macOS and is not universal across all editors. Shortcut remapping in IDEs and browser extensions can override the default binding silently. Underline applied in one app does not transfer as formatting when pasted into a plain-text target.
How selection state determines the result
The word “selected” in the question carries real weight. With no selection, most editors apply the underline attribute to the insertion point so that subsequently typed characters are underlined. That is a different behavior from underlining existing text, and it persists until you toggle it off or move the cursor into differently formatted text. Users who press the shortcut expecting nothing to change, then type, are often surprised by underlined new text.
Selection direction also matters in subtle ways. A selection made right-to-left anchors at the right edge, and some applications evaluate the toggle state from that anchor rather than the leftmost character. The visible result is the same in single-state selections but can differ for mixed formatting. Documented behavior varies by vendor, so the safe assumption is that the anchor character governs the toggle.
Undo handling is another area where the mechanism shows through. The underline command is recorded as a single undoable action in most editors, so one undo reverses the whole selection change rather than peeling it back character by character. That is a deliberate design choice: formatting operations are treated as atomic so users do not have to undo a hundred times after a stray keystroke.
Comparing underline shortcuts across common environments
| Environment | Shortcut | Notes |
|---|---|---|
| Windows word processors | Ctrl+U | Standard toggle for selected text |
| macOS word processors | Command+U | Same toggle, different modifier |
| Web browsers, no editable focus | Ctrl+U / Command+U | Often opens page source, not formatting |
| Terminal emulators | Ctrl+U | Commonly deletes to line start |
| Code editors | Varies | Often unbound or remapped by plugins |
| Linux desktop apps | Ctrl+U | Follows Windows convention in most toolkits |
The table makes the core point: the shortcut is standardized at the application-category level, not globally. The letter U is remarkably consistent, but its effect depends entirely on what has focus.
Misconceptions and the accessibility caveat
The most persistent misconception is that underlined text is a neutral styling choice. In web and document design, underline is strongly associated with hyperlinks, and using it for emphasis creates ambiguity for every reader. The professional caveat is sharper than most guides admit: underlining for emphasis is discouraged in accessible documents because it competes with the link convention and can confuse screen-reader users navigating by link.
A second misconception is that the shortcut and the toolbar button are interchangeable in every context. They usually are within a single application, but keyboard shortcuts can be remapped while toolbar buttons cannot, and some applications expose underline in the toolbar without binding a default key. If the shortcut seems dead, check the menu first to confirm the command exists before assuming a hardware problem.
A third is that Ctrl+U underlines everything you can see. It does not. It affects the current selection or the insertion point in the focused editable region. Selecting across a table, a text box boundary, or a protected section may apply formatting to only part of the apparent selection, because the document model treats those regions as separate editing contexts.
Practical actions for reliable results
Confirm focus first: click inside the editable text so the caret is visible before pressing the shortcut. Select precisely, then press Ctrl+U once; press again to verify the toggle removes the underline. On macOS, use Command+U and check the application’s Edit or Format menu if nothing happens. If Ctrl+U opens page source in a browser, click into an editable field before retrying. Prefer a dedicated emphasis style over underline in shared documents to avoid link confusion. Verify the result after pasting into another app, since formatting may not survive the transfer.
These steps resolve the large majority of “shortcut not working” cases, because they target focus and selection, the two conditions the command actually checks.
Limits of the shortcut and what it cannot tell you
The shortcut sets a formatting attribute; it does not encode meaning. An underlined word is visually marked but carries no semantic tag that a screen reader or a search engine can interpret as emphasis. That distinction matters for documents meant to be parsed by software, where true emphasis should use the appropriate structural markup rather than a visual attribute.
Platform behavior also changes across versions and applications, and vendor documentation is the only reliable source for a specific app’s binding. The general pattern described here, a Ctrl or Command modifier plus U toggling underline on a selection, is stable and widely observed, but exceptions exist and are not exhaustively catalogued in any single authority. Treat the shortcut as a strong default rather than a universal law, and verify in the application you actually use.