CSS Only Hamburger Menu — Checkbox Hack, No JavaScript Required

The "checkbox hack" is the foundational technique for building interactive CSS-only components: a hidden native <input type="checkbox"> holds a boolean UI state (open/closed), a <label for="..."> toggles that state on click without any script, and CSS sibling combinators (~ and +) read the checkbox's :checked pseudo-class to style everything downstream of it in the DOM.

Why a checkbox and not a button

A checkbox is the only common form control whose boolean state is exposed to CSS through a pseudo-class the browser maintains for free — :checked. A <button> has no equivalent persistent state selector in CSS; toggling its appearance or a sibling's requires JavaScript to add/remove a class. By binding the visible hamburger icon to a <label for="menuToggle">, clicking or tapping the label fires the browser's native "activate the associated control" behavior, which toggles the checkbox exactly like clicking the checkbox itself — this is standard HTML form behavior, not a hack in itself; the "hack" is only in *repurposing* that toggle as a UI state machine.

Sibling combinators do the routing

The markup order matters: the checkbox comes first, and every element whose appearance depends on the menu state — .hamburger, .nav-panel, .overlay — is a general sibling (~) that follows it in the same parent. .menu-toggle:checked ~ .nav-panel reads as "when the checkbox with class menu-toggle is checked, style any later sibling with class nav-panel." CSS has no parent selector and no way to reach backward or sideways outside this sibling chain, which is why the checkbox must be a direct sibling ancestor of everything it drives — it cannot be nested inside the element it's supposed to control if that element also needs to be a sibling target for others.

Hiding the checkbox without breaking it

The checkbox is hidden with opacity: 0 and pointer-events: none rather than display: none. A display: none input is still functionally checkable via its label, but some assistive technology and older focus-management logic treat display-none form controls inconsistently; opacity: 0 keeps the element in the accessibility tree and focusable via the label's native association, while making it visually invisible. position: absolute removes it from document flow so it doesn't take up space.

The bars-to-X morph

Each of the three bars is an independent <span> with its own transform. On :checked, the top bar translates down 7px and rotates 45deg, the bottom bar translates up 7px and rotates -45deg, and the middle bar scales to zero width while fading out. Because all three transforms are driven by the same single :checked state through three separate sibling selectors (.bar1, .bar2, .bar3), the animation is perfectly synchronized without a single line of JavaScript coordinating them — the browser's CSS transition engine runs all three in parallel.

The full-screen overlay

.overlay is a second <label for="menuToggle"> covering the viewport with position: fixed; inset: 0. Tapping anywhere outside the open nav panel — a click on the overlay — also toggles the same checkbox back to unchecked, because it's the same for association. This gives "click outside to close" behavior, a UX expectation for slide-in menus, entirely through native label semantics rather than a document-level click listener.

Where this actually matters: no-JS environments

This pattern isn't a novelty — it's the only viable way to ship an interactive hamburger menu in contexts that strip <script> tags outright: sanitized user-generated HTML (forum signatures, wiki pages), many CMS "raw HTML" content blocks, iframe sandboxes without allow-scripts, HTML email (where scripts are stripped or blocked by every major mail client), and AMP pages, which explicitly forbid custom JavaScript. In every one of these, a JS-based hamburger menu simply does not run; this one does, because the browser's own form-control state machine is doing the work.

Keyboard accessibility

The label receives :focus-visible styling via the adjacent selector .menu-toggle:focus-visible + .hamburger, and because the checkbox itself remains keyboard-focusable and toggled with Space/Enter through standard form semantics, Tab and Space alone are enough to open the menu without touching a mouse — no tabindex trickery or manual key handling required.