If you build web apps, you've been bitten by this at least once. You bind Ctrl+Alt+something as a shortcut, ship it, and a Polish user files a bug because that combo types ą on their keyboard. Or you tell users to press Delete and half of them backspace while the other half forward-delete, depending on which platform they're reading from. Marcin Wichary's reference exists because these problems are real, recurring, and poorly documented in one place. The core value here is the modifier key asymmetry. Windows gives you three modifiers for app shortcuts (Ctrl, Alt, Shift); Mac gives you four (Command, Option, Control, Shift). That extra modifier key on Mac is genuinely consequential for shortcut design space — it's not trivia, it's architecture. And the fact that Mac's Control key descended from terminal use while Windows' Ctrl became the primary app modifier creates a naming collision that still confuses developers who work cross-platform. The AltGr section is where experienced developers will learn something even if they think they know this territory. On many non-US Windows keyboards, Right Alt doubles as AltGr and outputs language-specific characters — Polish ą via AltGr+A, for example. Because AltGr is equivalent to Ctrl+Alt for legacy reasons, any Ctrl+Alt shortcut in a web app can collide with basic text input for non-English users. The mirror problem exists on Mac: Option-based shortcuts collide with the typographical character layer (Option+Q = œ on US English). Both platforms have the same bug class, but through different mechanisms. The piece is strongest on the small details that would take you hours to discover through debugging. Mac text fields support Unix-lineage shortcuts (Ctrl+A for beginning of line, Ctrl+E for end, Ctrl+K to kill to end of line) that most Mac users don't know exist but a vocal minority depends on. Windows still supports Shift+Delete for cut and Shift+Insert for paste — CUA-era holdovers that persist quietly. Arrow key behavior diverges: on Mac, up/down in a single-line input jumps to beginning/end, while Windows uses Home/End for the same purpose. The symbol documentation is genuinely useful as a lookup table. Apple uses ⌃ ⌥ ⌘ ⇧ in menus but not always on keycaps; the 2026 keyboard unification gets a mention. The observation that ⎋ (Escape) appears in Mac menus but never on the physical key is the kind of detail that reveals how even Apple's design coherence has seams. What's missing is any discussion of the web platform's own abstraction layer — the KeyboardEvent API, the difference between key and code properties, how IME composition events interact with all of this, or how frameworks like React handle cross-platform keyboard normalization. The piece stays at the physical and OS layer, which is the right scope for a reference but means web developers still need to bridge the gap themselves. There's also no mention of accessibility implications — screen reader keyboard conventions add yet another layer of conflict. This is a reference, not an argument. It doesn't try to be more than that, and it succeeds at exactly what it promises. The writing is clean, the examples are specific, and the illustrations (key cap photos, menu screenshots) do real work. If you ship software that handles keyboard input on both platforms, bookmark it.
