How We Verify Shortcuts

Why a shortcuts site needs a method at all

Keyboard shortcuts look like the simplest data on the web, which is exactly why so much of it is wrong. Shortcut lists get copied between sites for years after a vendor renames a command, a Mac binding gets pasted into a Windows table, and "tips" that were never true in any version get repeated until they look authoritative. A reference is only worth using if you can trust a row without opening the application to check it. Everything below exists to earn that trust.

Where a shortcut is allowed to come from

Every row must trace back to a primary source: the vendor's own documentation, the application's built-in shortcut panel or help menu, the command's --help output or man page, or the official release notes that introduced the binding. Blog posts, forum answers, other shortcut sites and AI-generated lists are not accepted as sources — if we cannot find a binding in vendor material or reproduce it in the tool, it does not go in. Each platform page carries a source note naming the document we checked and the date we checked it.

This rule is why some pages are short. Some tools simply have very few documented shortcuts, and we would rather publish eight correct rows than forty plausible ones. Pages that could not reach a useful minimum have been folded into their group pages instead of being left up as thin entries.

How platform differences are handled

Most desktop applications ship one keymap for Windows and Linux and another for macOS, and they are not always mirror images — Cmd does not always replace Ctrl, and some bindings exist on only one platform. Where a table shows a single binding, it is the Windows/Linux form unless the platform is Mac-only; Mac variants are noted in the row description when they differ by more than the modifier key. Where a tool's keymap changed across major versions, the table follows the current stable release and the source note says which version was checked.

Terminal and CLI pages follow the same idea: commands are shown as they run today, with deprecated forms mentioned in prose rather than listed as if they still worked. Version-sensitive tools such as Docker Compose, kubectl and cloud CLIs carry an explicit "checked" date because their syntax drifts.

What happens before a page is published

Hand-checking is only the first step. Every build of the site runs an automated verification battery that refuses to ship if any of the following fails: every shortcut key shown in a page must exist in the underlying dataset (no rows invented in HTML); every dataset row must appear on its page (nothing silently dropped); FAQ answers that mention a shortcut must match the table; and platform totals quoted anywhere on the site must equal the real count. The same battery parses every page with a strict HTML validator and rejects generated filler phrasing, so the explanatory text on a page has to be written specifically for that tool.

The dataset itself is public. The full shortcut and command data is published in a GitHub repository and through a JSON API, so anyone can diff what changed between versions or check a row against the source themselves.

What the explanatory text on each page is for

A table tells you which keys to press; it does not tell you which five shortcuts are worth learning first, which ones collide with the operating system or with another tool you run alongside it, or why a binding behaves differently than its name suggests. The prose sections on a platform page are written from using the tool, not summarised from its manual, and they only reference shortcuts that appear in the table above them. If a paragraph mentions a key combination you cannot find in the table, that is a bug — please report it.

Corrections

Reports come in through the contact page and the "Suggest an edit" link on every platform page. A confirmed error is fixed in the dataset, which updates the page, the API and the printable cheat sheets together, and is normally live within a few days. We do not silently rewrite pages; material corrections are reflected in the page's modified date.

If you want to know who is behind this, the about page says so.