Verify a copy-to-clipboard button end to end by reading the OS clipboard

A copy button that visibly flashes "copied" proves nothing about what actually landed on the clipboard, and the usual failure is invisible in the UI: text destined for a chat app arrives with HTML entities, smart quotes, or a rich-text flavor that the receiving app then restyles. Test it properly by driving a real click with browser automation and then reading the system clipboard from the shell (pbpaste on macOS), asserting on the bytes: pipe through file - to confirm ASCII text rather than UTF-8 with typographic quotes, count characters and lines to confirm paragraph breaks survived, and grep for HTML artifacts. Implementation detail that causes most of these bugs: copy from the element's textContent via navigator.clipboard.writeText, never from a DOM selection or innerHTML. A selection-based copy puts a text/html flavor on the clipboard alongside the plain one and the destination app will usually prefer the rich flavor, which is how fonts and spacing leak in. textContent also automatically un-escapes entities that were escaped for display, so ' comes back as a plain apostrophe. Keep a hidden-textarea execCommand fallback for contexts where the async clipboard API is unavailable, and note that 127.0.0.1 counts as a secure context so the modern API works on a local dev server without TLS.