20 Tailwind CSS keyboard-key styles for documentation shortcuts, command palettes, cheat sheets, and keybinding settings — from the reference <kbd> keycap and 3D press-down buttons to shortcut combos, arrow-key clusters, auto-detected Mac/Windows keys, icon keycaps, live press visualizers, and neumorphic, glassmorphism, retro typewriter, and terminal treatments. Scoped under .kbd-NN for no-collision pasting, prefers-reduced-motion guarded, framework-agnostic.
Building a whole Tailwind app, not just this component?
You just browsed 20 Tailwind kbd keys. Untitled UI Pro unlocks 5,000+ components and sections and 250+ page examples for React, styled with Tailwind CSS v4. One licence is a one-time $349 with lifetime updates; teams start at $999.
The reference keycap the whole collection builds on: a real <kbd> styled entirely in utilities so it sits inside documentation prose without disturbing the line it lives on. A hairline border-kbd01-rim plus a one-pixel shadow-[0_1px_0_…] edge reads as depth, every dimension is in em so the cap tracks the text, and leading-none keeps the line box intact.
A chunky 3D keycap whose wall is a solid 0_6px_0 shadow that collapses to 0_2px_0 as the face travels down translate-y-1 — 4px of travel, perfectly synchronised, so the key looks pressed rather than sunk. Each cap is a real <button> wrapping a <kbd>, so it responds to pointer and a held Space bar.
The two shapes a shortcut takes, styled so they can never be confused: chords (held together) sit in one shared tray joined by +, while sequences (pressed in order) float free with a then pill between them. The outer <kbd> wraps inner <kbd>s per the HTML spec, and the separators are siblings with aria-hidden.
For prose that mentions a dozen keys, the raised cap gets noisy. This flat treatment is a tinted chip — no border, no edge — with a faint inset ring-kbd04-rim/50 so it stays perceivable on any surface. Side-by-side cards compare it to the raised cap so the reader can see which to reach for.
One class list, three contexts: a 68px display headline, body copy and a caption — and the cap is correct in all of them because padding, radius, border width and even the edge shadow are authored in em. Tailwind's spacing scale is rem-based, so this is where arbitrary values earn their keep.
A shortcut reference with a macOS / Windows segmented control — zero JavaScript. The radios live inside their labels, so has-checked: styles the active tab, and a one-line @custom-variant kbd06-win lets every key inside the demo choose between ⌘ and Ctrl. Mac glyphs carry sr-only names, so a screen reader says “Command”, not “place of interest sign”.
Newsletter
Enjoying these demos? Get new ones by email.
A short email when a new collection ships. Unsubscribe any time.
The inverted-T arrow cluster and the six-key navigation block, laid out on explicit grid tracks so the shape survives every viewport. One [--u:clamp(…)] unit sizes every cap through size-(--u), and each arrow glyph is aria-hidden with a spoken name beside it.
Show ⌘ to Mac visitors and Ctrl to everyone else, automatically. Eight lines of script read navigator.userAgentData.platform and write one data-os attribute on the root; a @custom-variant kbd08-mac does the rest in markup. A manual macOS / Windows override uses aria-pressed:, because detection is a guess and the visitor knows better.
A real keyboard's geometry in utilities: one unit [--u:clamp(26px,7vw,46px)] and per-key multipliers — w-[calc(var(--u)*2.25)] for Shift, *6.25 for Space — so proportions match a physical board at every size. The function row is grouped Esc · F1–F4 · F5–F8 · F9–F12 like the hardware, and wraps by group on phones.
Keys whose visible label is a mark — search, escape, backspace, eject, power — drawn as inline SVG with stroke-current so they re-theme with the text colour. Every graphic is aria-hidden and paired with sr-only text, so the announced name is always a word; a visible caption under each cap teaches sighted readers the same word.
The docs-site search field with a ⌘ K badge tucked inside — and the badge behaves: it is pointer-events-none so clicks land in the input, it fades out on focus via peer-focus:opacity-0, and an Esc hint fades in to tell the user how to leave. The input advertises the shortcut to assistive tech with aria-keyshortcuts.
A four-group reference sheet for the Atlas editor that reflows from four columns to one with grid-cols-[repeat(auto-fit,minmax(min(100%,15rem),1fr))]. Keys hug the right edge of every row so the key column stays aligned across groups, rows highlight on hover for scanning, and print: utilities strip shadows and backgrounds so the sheet prints clean.
An editor toolbar whose tooltips name the action and its shortcut. Pure Tailwind: group-hover: opens a tip after a 300ms intent delay, group-has-focus-visible: opens it instantly for keyboard users, and the arrow is an after: border triangle. Each tip is a real role="tooltip" wired with aria-describedby.
An app's keybinding settings as a real data table — <caption>, scoped headers, status pills and per-row Reset buttons with sr-only context. On narrow screens the table scrolls inside its own container while the Action column stays pinned with sticky left-0, and the conflicting binding is flagged with colour, an icon, a text explanation and an inset accent bar.
Newsletter
Enjoying these demos? Get new ones by email.
A short email when a new collection ships. Unsubscribe any time.
A keystroke visualizer for screencasts and docs: focus the pad, press anything, and each press appears as a cap group — modifiers included, so Ctrl + Shift + K shows as one chord. Caps animate in with zero JS via starting: (@starting-style), leave via a data-out: variant, and a readout shows event.key beside event.code so the difference is visible.
Soft UI keycaps extruded from the pad with paired light and dark shadows, pressing into an inset pair on group-active:. The classic neumorphism failure — shadow-only edges with no measurable contrast — is fixed with a hairline border-kbd16-rim, a label above 4.5:1 and an accent label on press, so the control stays perceivable.
A frosted media-player shortcut panel over a colour field: the panel and every key blur what sits behind them. A solid, readable fill is declared first; supports-[backdrop-filter:blur(1px)]: swaps in the translucent fill and backdrop-blur-2xl only where blur actually works — so text never lands on an unblurred, busy background.
Round glass-top typewriter keys on an enamel plate, after the Wickfield No. 5: a domed radial-gradient face, a nickel ring-[3px] rim, a hard offset stem shadow and a Courier Prime legend. Each key is a button that drops 4px on group-active: while the stem shadow shortens, and the second row is offset half a key like the real machine.
CLI help output rendered as a terminal window: monospace caps for Ctrl + C, Ctrl + R and friends, a <dl> of key → effect, comment-style descriptions and a blinking block caret driven by an @theme animation token (--animate-kbd19-blink). Light mode becomes a warm paper terminal; dark mode is classic green-on-black.
The theming technique the whole collection runs on, shown on its own: every token is light-dark(day, night) in @theme, the root flips scheme-light → scheme-dark through a :has(:checked) custom variant, and a CSS-only role="switch" drives it. Live swatches in the token list repaint with the theme, so the variable → colour mapping is visible.
FAQ
Frequently asked questions
How do I style a semantic kbd element with Tailwind utilities instead of a styled div?
Keep the real element — write <kbd> and apply the look with utilities, exactly as Demo 01 does. A keycap is four things: a tactile border (border border-b-2 so the bottom edge reads as depth), a soft background (bg-gradient-to-b from-white to-slate-100), a rounded shell (rounded-md), and monospace, slightly smaller text (font-mono text-xs) with horizontal padding but almost no vertical (px-1.5 py-0.5). The one trap: <kbd> is inline by default, so py and fixed heights are ignored and tall caps clip on wrapping lines. Add inline-flex items-center to make padding and vertical centring behave. Because it stays a <kbd>, screen readers still announce it as keyboard input and nothing about the markup's meaning is lost to styling.
How do I make a 3D keycap press down on click using only Tailwind?
The wall of the key is a hard, offset box-shadow, not a gradient. Demo 02 writes the resting state as shadow-[0_6px_0_theme(colors.slate.400)] — a 6px solid drop with zero blur, which the eye reads as the side of a physical cap. On :active you shrink that wall and nudge the cap into it: active:shadow-[0_2px_0_theme(colors.slate.400)] active:translate-y-1. The travel distance (translate-y-1, 4px) must equal the shadow difference (6px minus 2px) or the key appears to float or sink through the board. Add transition-all duration-75 so the press is felt, not animated. The common mistake is using shadow-md with blur for the wall — it looks like elevation above the page, not a side you can push, and the :active collapse then has nothing crisp to shorten. Keep blur at 0 for every keycap layer.
How do I auto-detect the OS so Mac visitors see Cmd and everyone else sees Ctrl?
Demo 08 does it in about eight lines of script with no framework. Render both labels in the markup — a <span> for ⌘ and one for Ctrl — then on load read navigator.platform (or navigator.userAgentData.platform where present), test it against /mac|iphone|ipad/i, and toggle a hidden class on the branch that does not apply. Rendering both first matters: if you build the badge in script, a visitor with JavaScript disabled, or a crawler, sees an empty shortcut. The Tailwind side is just hidden on whichever branch loses. A subtle bug is matching navigator.userAgent for 'mac' — Chrome on Windows can contain 'Macintosh'-like tokens through compatibility strings, so prefer platform. And never key the whole shortcut off the OS; only swap the modifier glyph, since the letter is the same on both.
Can I build a Mac vs Windows shortcut toggle without any JavaScript at all?
Yes — Demo 06 is a pure-CSS segmented control. Two <input type="radio"> share one name so only one is ever checked, and they sit inside the component, hidden with sr-only (never hidden — that would drop them from the tab order and break keyboard selection). Each <label> paired by for is the visible pill. You then reveal the matching shortcut row with the sibling combinator: peer-checked/mac:block on the Mac row, hidden by default. The reason this works is the radios are earlier siblings of the rows, so peer can reach forward to them. The usual failure is nesting the rows in a different parent than the radios — peer only sees following siblings, so a wrapper <div> around the rows severs the link and nothing toggles. Keep radios and rows flat in the same container.
How do I size keyboard keys responsively so they look right in a headline and in body text?
Size the cap in em, not px, and it inherits from whatever text it sits in. Demo 05 uses a single class list — padding, border radius and font all expressed relative to the current font size (text-[0.85em] px-[0.5em] py-[0.15em] rounded-[0.35em]) — then drops the same <kbd> into a 68px headline, a body paragraph and a caption. The cap scales to each because 1em resolves against its parent. If you hardcode text-xs and px-1.5, the key is correct in body copy and tiny next to a display heading. The one thing to keep fixed is border width — a 0.1em border on a 68px line is a visibly fat frame, so pin the border to border (1px) and let only the interior scale. This is also why you avoid setting line-height on the cap; inheriting it keeps the key vertically centred on its text baseline at every size.
Should I use the kbd element for every key, and is the raised 3D style accessible?
Use <kbd> for genuine keyboard input — a shortcut, a key to press — because that is the element's defined meaning and assistive tech announces it accordingly. Do not reach for it as generic 'badge' styling for tags or statuses; that is markup lying about intent. On the visual side the raised cap is decorative, so accessibility rides on contrast and state, not depth: the gradient fill and text must clear 4.5:1, and any interactive cap (Demos 02, 15) needs a visible focus-visible:ring-2 since the shadow trick gives no focus cue on its own. For a paragraph that mentions a dozen keys, the raised style is the wrong call entirely — Demo 04's flat tinted chip exists precisely because twelve embossed caps in running prose are visual noise. Reserve the 3D cap for standalone shortcut callouts; use the flat chip inline.
How do I put a Cmd+K shortcut hint inside a search input without it blocking typing?
Demo 11 places the badge with the input as a positioned context: the wrapper is relative, the <input> gets right padding so text never slides under the badge (pr-16), and the hint is absolute right-2 top-1/2 -translate-y-1/2. The badge itself is a tiny <kbd> reading ⌘ K. The bug everyone hits is the badge eating clicks and caret placement near the right edge — fix it with pointer-events-none on the badge so every click and drag falls through to the field. If the shortcut actually focuses the input, wire that in script with a keydown listener and preventDefault on the combo, but keep the visual badge pointer-events-none regardless. Also pad enough: a two-key hint needs more than pr-10, or long queries scroll beneath it and the last characters vanish under the badge.
How do dark-mode keycaps stay readable, and why does the light-dark approach break in an iframe?
Demo 20 themes every token through light-dark(day, night) on CSS custom properties, so one declaration carries both schemes and the keycap's fill, border and text switch together without a duplicated dark variant. For it to resolve you must declare color-scheme: light dark on the root (Tailwind: scheme-light-dark) — omit it and light-dark() silently returns the first argument forever, which reads as 'dark mode does nothing'. The subtler trap is scope: an iframe does not inherit the parent document's theme state, so a cap previewed in an isolated frame can show the wrong scheme until color-scheme is set on the frame's own root. When you need per-key overrides (an accent cap), set the custom property on that key and let light-dark() inside it pick the branch — don't fork into dark: utilities, or the two theming systems drift apart.
