VS Code Shortcuts

Features

• Over seventy common commands in seven categories: commands and files, find and go to, editing, multi-cursor, IntelliSense and refactoring, view and panels, debugging and terminal
• Windows / Linux and macOS keybindings shown side by side
• Search by command name, in plain English
• Search by key combination — `Ctrl+Shift+P`, `ctrl shift p` and `Ctrl + Shift + P` all work
• Search by category to list everything of that kind
• Chord bindings (pressed twice, such as Ctrl+K Ctrl+S) come with a note on how to press them
• When one key combination matches several commands, they are listed together (F12 and Shift+F12, for instance)
• Every command sits in a searchable dropdown, for when the name escapes you
• Empty input lists the full reference, browsable as a cheat sheet
• Paste tolerance: quotation marks and full-width characters do not break the lookup
• Keys are written as they appear on the keycaps (Ctrl / Cmd / Alt / Shift), never translated

How to use

1. Type a command name, such as "Command Palette"
2. Or type a key combination, such as Ctrl+Shift+P, to see which command it runs
3. If the name escapes you, type a category to list everything of that kind
4. The result shows Windows / Linux and macOS side by side, with a note for chord bindings

FAQ

Why is it mostly Cmd rather than Ctrl on macOS?

It is a platform convention: macOS reserves Cmd (⌘) for application shortcuts and leaves Ctrl to the system and terminal layers, and VS Code follows it. So a `Ctrl+X` on Windows is usually `Cmd+X` on macOS. But not always — a few are exceptions: go to line, trigger suggestions and toggle terminal stay on Ctrl on macOS, and "go back" is `Ctrl+-` rather than `Alt+Left`. That is why both columns are written out command by command instead of being generated by swapping Ctrl for Cmd, which would get exactly those exceptions wrong.

Why do some shortcuts need two presses?

Those are chords: press the first part (say `Ctrl+K`), release, then press the second (say `Ctrl+S`) for the whole thing to count. They exist because the good combinations ran out — VS Code ships over a thousand default bindings, and chording is how it keeps growing. The tool flags chords explicitly, because otherwise people assume the keybinding is misprinted.

I have customised my keybindings. Is this still accurate?

No — and that is a boundary of the tool by design. Everything here is the default. The reliable way to see what is actually bound on your machine is the Command Palette: press `Ctrl+Shift+P` (`Cmd+Shift+P` on macOS), type the command name, and the keybinding shown on the right is the one currently in effect. Or open the Keyboard Shortcuts editor with `Ctrl+K Ctrl+S`, which lists every binding and any conflicts.

Why no browser devtools shortcuts?

Because that is an entirely different keymap, and it varies between Chrome, Edge, Firefox and Safari as well as across platforms — every entry would need checking on its own. Mixing it into the same table means someone presses a key, nothing happens, and the whole table stops being trusted; and a shortcut table that is not trusted is worth nothing. So this covers VS Code first, where the defaults are documented and the platform differences are clear. Better few and correct than many and unreliable.

How should I actually learn these?

Not by memorising a table. The path that works is to do your work through the Command Palette (`Ctrl+Shift+P`) at first — it can reach nearly everything in VS Code, and the keybinding for whatever you pick is displayed on the right the whole time, so it sinks in through use. Alongside that, fix a handful of high-frequency ones into habit: the command palette, quick open, add next occurrence, toggle line comment, format document. Those cover the large majority of daily work. Look the rest up when clicking starts to annoy you.