Keyboard Shortcuts Reference
Searchable shortcuts for VS Code, JetBrains, Vim, and Terminal. Click any shortcut to copy it.
Last reviewed: April 2026New to this tool? Click here for instructions
| Shortcut | Description | Category |
|---|
How to Use the Shortcuts Reference
To use the Keyboard Shortcuts Reference, start by selecting your IDE from the option chips (VS Code, JetBrains, Vim, or Terminal). Toggle your OS to see the correct modifier keys (Ctrl vs. Cmd). You can filter by category and search by typing in the search box. Click any shortcut key string to copy it to your clipboard.
When to Use the Tool in Real Workflows
The Keyboard Shortcuts Reference is ideal for power users who want to increase their productivity. It's particularly useful when you need to quickly access and use keyboard shortcuts in various IDEs and editors. Whether you're working on a large codebase in VS Code or navigating through files in Vim, knowing the right shortcuts can save you time and increase your efficiency.
How It Works
The Keyboard Shortcuts Reference is a free online tool that provides a searchable list of keyboard shortcuts for popular IDEs and editors. It allows you to filter and search for shortcuts based on your needs. The tool is designed to be user-friendly and accessible, making it easy for users to find and copy the shortcuts they need.
Tips, Edge Cases, or Limitations
The Keyboard Shortcuts Reference is a great resource for power users, but it's important to remember that it's not a substitute for learning the underlying commands and concepts. While the tool can help you quickly access shortcuts, it's still important to understand how they work. Additionally, the tool is limited to the shortcuts available in the IDEs and editors it covers, so it may not include all possible shortcuts.
Frequently Asked Questions
A searchable, cross-platform reference for keyboard shortcuts across editors (VS Code, JetBrains, Vim, Emacs), terminals (bash, zsh), browsers, and the three major desktop operating systems — with the per-platform modifier differences spelled out and one-click clipboard copy for every keybinding.
What This Tool Does
This is a unified keyboard shortcut reference covering four primary domains that developers move between dozens of times per day: code editors, terminal shells, web browsers, and the operating system itself. Each shortcut entry stores both its Windows/Linux form and its macOS form, so when you toggle the OS selector at the top of the page the entire table re-renders with the correct modifier keys — Ctrl on Windows/Linux, Cmd on macOS — without losing your category filter or active search query.
The coverage spans VS Code (command palette, multi-cursor, navigation, debug, integrated terminal), JetBrains IDEs (Search Everywhere, Find Usages, refactoring chords), Vim (Normal/Insert/Visual mode with mode badges on every entry), and the GNU Readline bindings shared by bash and zsh in interactive mode. Beyond those listed in the searchable table, the prose sections below document browser shortcuts (Ctrl+T for new tab, Ctrl+L to focus the address bar, F12 for DevTools), OS-level window management (Cmd+Tab on macOS, Alt+Tab on Windows, Super+Tab on most Linux DEs), and the modifier-key conventions that differ between platforms.
Every keybinding in the searchable table is also a copy-to-clipboard button: click the key string and it lands on your clipboard in plain-text form (for example, Ctrl+Shift+P) suitable for pasting into a chat message, a runbook, or a keymap configuration file. The tool runs entirely client-side — no shortcuts you copy, no searches you type, and no OS preferences you select are uploaded anywhere outside your browser session.
How to Use It
Filtering by Application
The four green option chips immediately above the search input — VS Code, JetBrains, Vim, Terminal — switch between application contexts. Each context has its own command set; switching contexts resets the category filter to All so you can see the full shortcut list for the newly selected application without leftover narrow filters from your previous context confusing the results.
Searching by Action
The search box matches both the keybinding column and the description column, case-insensitive, with a 150ms debounce so the table doesn't thrash while you type. Type save to find every save-related shortcut across the active application. Type find to surface Ctrl+F, Find in Files (Ctrl+Shift+F), Find Next (F3 or Cmd+G), and Find All References (Shift+F12) — useful when you remember the action verb but not the chord. Type delete word to compare how Vim (dw in Normal mode), the terminal (Ctrl+W deletes the previous word, Alt+D deletes the next), and VS Code (Ctrl+Backspace / Cmd+Backspace) each handle the same underlying intent.
Toggling the OS
The Windows / macOS toggle on the right side of the controls row swaps modifier keys for every visible row simultaneously. The toggle affects the displayed keys, the clipboard payload when you click to copy, and the per-row CSV export — so if you're writing a Mac-specific onboarding doc you can flip to macOS, filter to the relevant category, and copy keys one at a time without manually translating Ctrl to Cmd. Linux users should use the Windows view; the Ctrl/Alt/Shift bindings are identical between Windows and Linux in nearly all developer applications, with the Super key (Linux's name for the Windows key) being the only real divergence and almost exclusively reserved by the window manager rather than applications.
Copying a Keybinding
Click any green keybinding string in the leftmost column — a brief toast confirms the copy, and the underlined text indicates clickability on hover. The copy uses the modern navigator.clipboard.writeText API where available and falls back to a hidden-textarea + document.execCommand('copy') approach on older browsers. This is genuinely useful for documenting a keymap in a README, sending a coworker the exact key combo over chat, or pasting into a JSON keybinding file where typing the chord by hand would risk typos.
Categories
Below the search row, category chips (Navigation, Editing, Selection, Find/Replace, Terminal, Debug, Git) filter the visible rows. Categories are derived from the data — only categories that actually contain entries for the current application appear, so the Vim view shows fewer categories than VS Code because Vim's Debug and Git shortcuts live in plugin ecosystems (vimspector, fugitive) rather than core Vim itself.
Worked Example: Finding "Delete Previous Word" Across Four Tools
One concrete demonstration of why a unified reference matters: the simple intent delete the word to the left of the cursor binds to four different chords across the tools developers use daily, and the semantic differences between those chords are not always obvious.
- Intent
- Delete the word immediately preceding the cursor — a non-destructive single-action that most editors expose as an explicit shortcut rather than relying on Backspace held down.
- Tools compared
- Vim (Normal mode), GNU Emacs, VS Code on Windows and macOS, and bash/zsh under the default Readline bindings.
- Vim Normal mode: the chord is
db— delete (d) backward word (b). The cursor sits on the first character of the word being deleted, and the text is yanked into the unnamed register, available for paste withp. A related Vim shortcut,<Ctrl+W>, works only in Insert mode and deletes the previous word inline while you're typing — the same chord as bash but with the same semantics. - GNU Emacs:
<Meta+Backspace>(often labeledM-DELin Emacs documentation) is the canonical binding. On most modern keyboards the Meta key is mapped to Alt, so the practical chord is<Alt+Backspace>. Emacs kills the word into the kill-ring, accessible via<Ctrl+Y>(yank). This binding has been stable since the late 1970s — Emacs is famous for never breaking its keybindings, even when the surrounding ecosystem has changed completely. - VS Code on Windows / Linux:
<Ctrl+Backspace>deletes the previous word in any text input or editor buffer. The word boundary respects the active language's word-character regex, so deleting fromfooBarwith a camelCase-aware setting may stop atBrather than consuming the entire identifier. - VS Code on macOS:
<Option+Backspace>is the OS-level word-delete that VS Code inherits from the macOS text system.<Cmd+Backspace>on macOS performs a different action — delete to start of line — so the Mac form intentionally diverges from the Windows form to match the broader OS convention. - bash / zsh (Readline):
<Ctrl+W>deletes the previous word, where Readline's notion of "word" is whitespace-delimited (not language-aware). The killed text goes into the Readline kill-ring and can be yanked back with<Ctrl+Y>. Note thatCtrl+Win many graphical applications means "close window" or "close tab" — a major source of accidental tab closures when terminal muscle memory leaks into a browser.
Semantic comparison. Vim's db moves the cursor along with the deletion; Emacs's M-DEL places the deleted text into a kill-ring shared with all other kill operations; VS Code's Ctrl+Backspace respects camelCase boundaries when configured to; Readline's Ctrl+W uses pure whitespace boundaries. The same conceptual action — "delete a word" — has four meaningfully different definitions of what counts as a word.
| Tool / Context | Key Chord | Word Boundary Definition | Side Effect |
|---|---|---|---|
| Vim Normal mode | db | WORD or word (configurable) | Yanked into unnamed register |
| Vim Insert mode | Ctrl+W | Whitespace + iskeyword | None (no register) |
| GNU Emacs | Meta+Backspace (= Alt+Backspace) | Major-mode syntax table | Pushed to kill-ring |
| VS Code (Win/Linux) | Ctrl+Backspace | Language word regex | None |
| VS Code (macOS) | Option+Backspace | macOS text-system word definition | None |
| bash / zsh (Readline) | Ctrl+W | Whitespace-delimited only | Pushed to Readline kill-ring |
| macOS native text fields | Option+Backspace | NSTextSystem word boundaries | None |
Common Use Cases
Onboarding New Team Members
Engineering onboarding is mostly tool fluency, and tool fluency is mostly keybinding fluency. A new hire who knows that Ctrl+Shift+P opens VS Code's command palette can find any other command without further training; one who doesn't has to navigate menus for every action. Linking new hires to a filtered view of this page — for example, the VS Code Navigation category — gives them a printable, copyable, searchable starter kit. Pair the reference with a 15-minute screen-share where you demonstrate ten high-impact shortcuts (Go to File, Go to Symbol, Multi-cursor, Toggle Comment, Format Document) and most engineers internalize the next twenty on their own through repetition.
Switching from Mac to Windows (or Vice Versa)
The Cmd-vs-Ctrl confusion is the single largest source of broken muscle memory when switching platforms. On macOS, Cmd is the application-shortcut modifier (Cmd+C copies, Cmd+S saves) and Ctrl is mostly reserved for emacs-style text-editing bindings (Ctrl+A to start of line, Ctrl+E to end of line — universal across macOS text fields). On Windows/Linux, Ctrl plays the role macOS Cmd plays, and there is no equivalent of macOS's Ctrl-as-text-editing-prefix outside of terminal applications. Switching platforms requires consciously rewriting six or seven shortcuts (Cmd→Ctrl) and then either accepting that macOS-style text navigation is unavailable in Windows applications or installing a remapper like PowerToys Keyboard Manager to restore it. The OS toggle at the top of this page lets you A/B the two forms side-by-side until the new pattern locks in.
Pair Programming with Different Keybindings
Pair programming sessions break down fast when the navigator and driver have different keymaps. A Vim user driving while an emacs user navigates produces a constant low-grade friction: the navigator can't tell the driver to "save and run the tests" without first asking which key chord the driver expects. Sharing this reference at the start of a pair session — or pre-agreeing on a "neutral" set of shortcuts both will use during the session — eliminates that friction. Some teams adopt a shared keybinding profile checked into the repo (a .vscode/keybindings.json for VS Code teams) so every machine on the team uses the same chords.
Accessibility — Avoiding the Mouse
For users with repetitive strain injuries or motor impairments that make precise mouse work difficult, keyboard-only workflows are not a productivity flex — they are a necessity. WCAG 2.1 Success Criterion 2.1.1 (Keyboard) requires that all functionality be available via keyboard alone, and a comprehensive shortcut reference like this one supports that requirement by surfacing the keyboard equivalents of mouse-driven actions. Particular attention should go to focus management (Tab and Shift+Tab to move between focusable elements), skip links (the "Skip to content" link at the top of every page on this site is one such), and arrow-key navigation within composite widgets like menus and grids.
Keyboard-Driven Browsing
Vim-style browser extensions — Vimium for Chrome, Tridactyl for Firefox, qutebrowser as a standalone browser — let you operate the web mostly without a mouse. f shows hotkeys for every link on the visible page; j and k scroll one line at a time; gi focuses the first text input; / opens an in-page find-as-you-type. The learning curve is steep but the payoff is genuine: navigating a Wikipedia article or a GitHub PR comment thread without ever moving your hands off the home row is meaningfully faster than the mouse-driven alternative, and it eliminates the wrist-twisting reach to the trackpad that's implicated in repetitive strain.
Edge Cases and Modifier-Key Surprises
Several keyboard layouts and conventions don't conform to the simple Ctrl/Cmd/Alt model and routinely surprise people writing cross-platform documentation.
Mac Cmd is not Windows Ctrl is not Linux Super. On macOS, Cmd sits where Alt sits on a PC keyboard — adjacent to the spacebar — and is the primary shortcut modifier. Linux's Super (the key with the Windows logo on PC keyboards, or Cmd on Apple hardware) is almost universally reserved by the window manager or desktop environment for window-management actions: Super+Tab cycles windows on GNOME and KDE, Super+L locks the screen on most distros. Applications running on Linux generally don't bind shortcuts to Super because the window manager intercepts them before the application sees the event.
AltGr on European keyboards. On many non-US keyboard layouts (German, French, Spanish, and others), the right Alt key is labeled AltGr (Alt Graph) and produces a third character group per key — for example, AltGr+E produces € on a German layout. Applications that bind shortcuts to right-Alt-as-Alt may either capture the keystroke or pass it through to character generation, depending on platform conventions. Cross-platform shortcut design generally avoids binding to right-Alt for this reason; left-Alt is safer.
Caps Lock as Ctrl. Many keyboards from the pre-1984 era placed Ctrl on the home row where Caps Lock sits today (the original Sun Type 3 and 4 keyboards, the IBM Selectric, and the Symbolics Lisp Machines). Remapping Caps Lock to Ctrl restores that ergonomic property and is the single highest-impact remap for anyone who uses Ctrl-heavy applications (Emacs, terminal, VS Code). The remap is documented in the FAQ below.
Hyper and Meta on Lisp machines. The 1980s Symbolics Lisp Machine keyboards had physical Super, Hyper, Meta, and Control modifiers — four independent shift-like keys, giving 2^4 = 16 modifier combinations per key. Emacs's documentation still references all four, even though no modern keyboard exposes Hyper or Super distinctly from Meta in default bindings. Karabiner-Elements on macOS and AutoHotkey on Windows can synthesize a Hyper modifier by remapping a single physical key (typically Caps Lock or right-Cmd) to emit Ctrl+Shift+Alt+Cmd simultaneously, creating a 'safe namespace' for personal shortcuts.
Browser-vs-OS-vs-application shortcut conflicts. The classic conflict on macOS is Cmd+H, which the OS binds to "Hide application." Older Mac applications sometimes attempted to bind Cmd+H to "Help" instead, but the OS-level binding wins — the help menu typically gets Cmd+? or Cmd+Shift+/. Another reliable conflict source: Ctrl+W means "close tab" in every browser and "delete previous word" in every terminal, so terminal-trained users routinely close browser tabs by accident when typing in a textarea. Web applications can re-bind some browser shortcuts via preventDefault() but cannot override Ctrl+T, Ctrl+W, Ctrl+N, Cmd+Q, or any chord involving the OS's window-management keys.
Modal vs non-modal editing. Vim's modal design means the same physical keystroke does different things depending on the current mode — i in Normal mode enters Insert mode, while i in Insert mode types the letter i. Non-modal editors (every mainstream editor except Vim and its derivatives) bind editing commands to modifier chords (Ctrl+X to cut, Ctrl+V to paste), which means the unmodified letters always type themselves. Both designs have tradeoffs: modal editing avoids modifier-key contortions but requires you to track mode mentally; non-modal editing has consistent letter-typing behavior but heavier modifier usage. Tools like vim-mode for VS Code and Emacs Evil Mode attempt to give users a modal layer over non-modal foundations.
Behind the Scenes
The UI Events Specification
Web applications detect keyboard input via the W3C UI Events specification, which defines three relevant events: keydown (a key was pressed), keyup (a key was released), and keypress (deprecated as of 2026, replaced by listening for keydown with character-producing keys). Each event exposes a KeyboardEvent object with .key (a logical name like 'a' or 'ArrowDown'), .code (the physical key location like 'KeyA' or 'ArrowDown' — independent of keyboard layout), and modifier flags .ctrlKey, .shiftKey, .altKey, and .metaKey. The .metaKey property is true when the macOS Cmd key or the Windows/Linux Super key is held, which is why cross-platform shortcut handlers typically check both .ctrlKey and .metaKey to capture both Ctrl+S on PC and Cmd+S on Mac.
Why VS Code Uses Chord Shortcuts
A standard keyboard exposes roughly 100 single-modifier combinations (Ctrl + each letter/number/symbol). A large IDE like VS Code has well over 600 named commands. Single-modifier chords cannot cover them all, so VS Code adopts a two-keystroke chord pattern borrowed from Emacs: a prefix key (Ctrl+K) opens a namespace, and a second keystroke selects a command within that namespace. Ctrl+K Ctrl+S opens Keyboard Shortcuts; Ctrl+K Ctrl+T opens the theme picker; Ctrl+K F formats the selection. The chord pattern lets VS Code expose hundreds of low-frequency commands without exhausting the high-frequency single-modifier space (which is reserved for Ctrl+C copy, Ctrl+V paste, Ctrl+S save, and so on). Discoverability is the cost — chords are invisible until you open the Keyboard Shortcuts editor or read documentation — but the command palette (Ctrl+Shift+P) compensates by letting you search any command by name regardless of whether it has a chord at all.
Vim's Modal Philosophy
Vim, derived from vi (which Bill Joy wrote in 1976 over a 300-baud modem connection), inherited modal editing as a bandwidth-optimization decision: every keystroke had to count when each character took 33 milliseconds to traverse the line. Single-letter commands in Normal mode mean editing is dense — one keystroke per intent — and the verb-object grammar (delete word, change inside parens) means compound operations compose without exploding the chord namespace. The modal cost is the friction of switching between Insert and Normal modes, which Vim mitigates with operator-pending and visual modes that let you stage operations without the constant back-and-forth.
Emacs and Its Forty-Year-Old Keybindings
GNU Emacs's keybindings — Ctrl+A to beginning of line, Ctrl+E to end of line, Ctrl+K to kill to end of line, Meta+B backward word, Meta+F forward word — date to the original TECO-based Emacs in the 1970s and have remained stable for over four decades. The same bindings appear in bash and zsh in their default Emacs-mode Readline configuration, in every text input on macOS (Cocoa text fields inherit Emacs bindings system-wide), and in the Python REPL, the MySQL CLI, and countless other tools that link against GNU Readline. The stability is a deliberate Free Software Foundation choice — breaking forty years of muscle memory would be a serious harm to long-time users.
The History of Ctrl+C = Copy
The Ctrl+C/Ctrl+X/Ctrl+V copy-cut-paste triad we now treat as universal originated at Apple in 1983 with the Lisa interface and was carried into the Macintosh in 1984. Larry Tesler's earlier work at Xerox PARC had established the "cut/copy/paste" model conceptually, but the specific keybindings — Cmd+C, Cmd+X, Cmd+V on Mac, mirrored to Ctrl+ on Windows — are Apple's contribution. The choice of C/X/V is mnemonic and physical: C for Copy is obvious; X for Cut suggests a pair of scissors; V for paste is below them on a QWERTY keyboard, making the trio reachable with one hand without crossing fingers. The earlier IBM CUA (Common User Access) standard from 1987 specified Ctrl+Insert and Shift+Insert for copy and paste, which survives in some legacy Windows applications, but Apple's C/X/V triad eventually won the standardization battle and now appears in every mainstream OS and browser.
Comparison: This Tool vs. Alternatives
| Reference | Coverage | OS Toggle | Search | Copy to Clipboard | Offline | Best For |
|---|---|---|---|---|---|---|
| This Tool | VS Code, JetBrains, Vim, Terminal | Yes (Win/Mac) | Real-time, debounced | One-click per key | Service worker (yes) | Quick cross-tool lookup; copying chords into docs |
| VS Code Built-in Keybindings Editor | VS Code only | Implicit (matches active OS) | Yes | No (but you can rebind) | Yes | Customizing your own VS Code keymap |
| vim-cheatsheet.com | Vim only, comprehensive | N/A (Vim is OS-uniform) | Browser Find | No | No | Deep Vim reference with mode-by-mode breakdown |
| KeyCombiner | 120+ apps; paid tier | Yes | Yes | Yes | Web app (no offline) | Power users learning many tools simultaneously with spaced repetition |
| cheatography.com PDFs | Crowdsourced, hundreds of apps | Per-cheatsheet | By cheatsheet only | No (PDF) | Yes (printed) | Printable wall references for one specific tool |
When to use this tool: you need to look up or copy a specific chord across multiple applications, you want OS-correct modifiers without manual translation, or you want to compare how different tools bind the same conceptual action (the worked example above).
When to use VS Code's built-in keybindings editor: you're customizing your own keymap rather than learning the defaults, or you want to see what's bound to a chord you just pressed (the editor includes a "record keystroke" search input).
When to use vim-cheatsheet.com: you need Vim depth — every operator, every motion, every text object — in one place, organized by mode and by frequency of use. Vim's command surface is large enough to deserve its own dedicated reference.
When to use KeyCombiner: you're trying to learn a new application's full keymap rather than look up individual chords. KeyCombiner's spaced-repetition feature drills you on chords over time, which is a meaningfully different workflow from a lookup reference.