20 CSS Copy Buttons

One line does the work: await navigator.clipboard.writeText(value). It returns a promise, so wrap it in try/catch and drive your UI from the result rather than assuming success — that single habit is what separates a copy button that works from one that silently lies. The important constraint is that the Clipboard API is only available in a secure context: HTTPS, or localhost during development. On a plain http:// page or a file opened directly from disk, navigator.clipboard is undefined and your handler throws immediately. Check for it before calling — if (navigator.clipboard && window.isSecureContext) — and fall back to the textarea technique below. Write to the clipboard only in direct response to a user gesture like a click; browsers reject clipboard writes from timers or on page load, which is a deliberate anti-abuse measure rather than a bug.

Almost always the secure-context rule. The Clipboard API is gated on HTTPS, and localhost counts as secure, so a button that works perfectly in local development can fail the moment it ships to a staging box served over plain HTTP. Opening the page as a file:// URL fails the same way, which catches people testing a downloaded snippet by double-clicking it. Inside an iframe there is a second gate: the frame needs clipboard-write permission, so an embedded playground or preview can reject the call even on an HTTPS parent. The fix in every case is the same — feature-detect, then fall back to a hidden textarea plus document.execCommand('copy'), which is deprecated but still works everywhere and needs no permission. Never let the failure be silent: show the user a message telling them to select and copy manually, which is what a screen-reader user needs anyway.

No, and any tutorial claiming otherwise is describing something else. Writing to the clipboard requires a JavaScript API call — CSS has no access to it and never will, because the clipboard is a security-sensitive system resource. What CSS can do is the entire feedback experience: a hidden checkbox plus :checked flips the label from "Copy" to "Copied", swaps the icon, and animates the transition with no script at all. That is genuinely useful for prototyping the interaction or for a design-system reference, and it is what the pure-CSS demo in this collection shows — with the limitation stated on the page rather than implied away. There is one honest half-measure: an <input> or <textarea> with onfocus="this.select()" pre-selects the value so the user only has to press Ctrl+C, which reduces the interaction to one keystroke without any clipboard write.

A copy button that only changes colour is invisible to assistive technology. Three things fix that. Use a real <button type="button"> with an aria-label if the button is icon-only, so it is announced as something activatable rather than skipped. Put the confirmation in a live region — an empty element with aria-live="polite" that you write "Copied to clipboard" into on success — because a visual state change fires no accessibility event on its own. Use role="alert" instead for the failure path, since a copy that did not happen is urgent and the user needs to know to select the text manually. Beyond that, keep a visible :focus-visible ring and a 44×44px minimum target per WCAG 2.5.8; icon-only copy buttons are frequently 24px, which is a real problem on touch. Do not disable the button during the success window without saying why.

Absolute positioning inside a relatively-positioned wrapper, offset from the top-right corner: position: absolute; top: .6rem; right: .6rem on the button, position: relative on the <pre>. Two details make it feel right. Give the <pre> enough padding-right that a long first line cannot slide underneath the button — otherwise the button sits on top of the code it is meant to copy. And if you reveal the button only on hover to keep the block clean, add :focus-within to the same rule, or keyboard users can never reach it: .block:hover .copy, .block:focus-within .copy { opacity: 1 }. For a very tall snippet, position: sticky; top: .6rem keeps the button reachable while the reader scrolls through the code, though sticky silently fails if any ancestor has overflow: hidden or a transform.

Keep the display string and the clipboard string separate. This matters most for wallet addresses shown as 0x71C7…8f3A and API keys masked as sk_live_••••4a2f: the visible text is a presentation choice, and copying it gives the user something useless. Store the real value where the handler can reach it — a data-copy-value attribute, a hidden input, or the element's own value if it is a read-only field — and truncate only visually with text-overflow: ellipsis or a CSS-generated middle ellipsis. Never truncate the source string in JavaScript and then copy that. The same rule applies to the masked-key pattern: the mask belongs to the view layer, so the reveal toggle and the copy button both read the underlying value, not the asterisks the user can see.

Because one handler is bound to one value instead of reading its own target. The usual shape of the bug is a query for a single element — document.querySelector('.copy-btn') — wired once, or a shared variable captured outside a loop, so whichever value was current at setup time is the one every button copies. Fix it by letting each button carry its own target: <button data-copy-target="#snippet-3">, then one delegated listener on the container reads event.target.closest('[data-copy-target]') and resolves the value per click. That scales to any number of buttons with a single listener, survives content added after page load, and avoids the ID collisions you get from generating id="copy1", id="copy2" and so on. It also keeps the success state local — set it on the clicked button, not on every button sharing the class.

The CSS ports unchanged — every .cpy-NN selector and custom property is framework-agnostic. The copy logic is where framework idiom matters, and the shape is the same everywhere: a small async handler plus one piece of state for the success window. In React that is const [copied, setCopied] = useState(false) with a setTimeout to clear it, and the timer must be cleared in the effect's cleanup or a rapid re-click leaves a stale timeout that resets the label early. Vue uses a ref and onBeforeUnmount; Svelte a plain let and onMount's returned cleanup. One React-specific trap: do not put the handler inline in JSX if the component re-renders often, or you create a new function on every render and lose the ability to clear the previous timer. For Tailwind the states map to group plus data-[state=copied]: variants, which keeps the whole feedback transition in markup without a stylesheet.