How to Screenshot a Hover State, Dropdown, or Animation

Hover states, dropdowns, tooltips and mid-animation frames share a property that makes them uniquely annoying to capture: the act of taking the screenshot is what destroys them. You move the mouse to reach the shortcut, and the thing you wanted is gone. There are three good answers, and the third one is to stop taking a picture altogether.

Why this is hard

Transient UI depends on continuous input. A :hover rule applies only while the pointer is over the element. A dropdown listens for a click outside itself, or for focus to move, and closes. A tooltip has a dismiss timer. All three are correct behaviours, and all three are hostile to a screenshot, because moving your hand to the keyboard is exactly the event they are watching for.

The workarounds fall into two categories: make the state permanent, or make time stop. Which you need depends on whether the state lives in CSS or in JavaScript.

1. Force the state in DevTools

This is the right answer for anything driven by a CSS pseudo-class, which covers most buttons, links, inputs and cards.

1. Open DevTools and select the element in the Elements panel. Right-click it on the page and choose Inspect to get there fastest.
2. In the Styles pane, click the :hov button in the toolbar.
3. Tick :hover. The element renders as if the pointer were on it, permanently.
4. Screenshot however you like. The state survives moving the mouse, using the keyboard, and switching windows.

The same panel offers :active, :focus, :focus-visible, :visited and :target. :focus-visible is worth knowing: it is the state that draws the keyboard focus ring, and it is the one you want when documenting accessibility.

Where it does not work

Force-state only affects CSS pseudo-classes. If the dropdown opens because a script added a class or mounted an element, ticking :hover changes nothing — the browser is not the thing deciding. That is the next section.

2. Freeze the page with the debugger

For anything JavaScript controls — dropdowns, autocomplete suggestions, tooltips with timers, modals that close on outside click — the trick is to stop script execution while the overlay is open. A paused page keeps rendering exactly what was on screen and stops responding to the events that would close it.

1. Open DevTools and go to the Console.
2. Run setTimeout(() => { debugger; }, 3000).
3. Switch back to the page and open the menu, hover the element, or trigger the tooltip.
4. After three seconds the debugger pauses. The page is frozen with the overlay open and will not respond to anything.
5. Screenshot. Then press F8 or the resume button in DevTools to let the page continue.

Chrome also offers an event-listener breakpoint under Sources → Event Listener Breakpoints → Mouse → mouseover, which pauses the first time the pointer enters any element. That is more precise, and considerably more irritating on a busy page.

3. Catching a specific animation frame

Sometimes the problem is not a state but a moment: a transition that flickers at 30%, a loading spinner that looks wrong at one angle.

Three tools, in increasing order of precision:

• Slow it down. Chrome DevTools has an Animations panel (in the drawer, via the ⋮ menu → More tools) with playback speed controls. Drop to 10% and the frame you want lasts ten times longer.
• Scrub it. The same panel records animation groups and lets you drag a playhead through them, stopping wherever you like.
• Pin it from the console. For an exact percentage, pause the animation and set its time directly:

const el = document.querySelector('.spinner');
const anim = el.getAnimations()[0];
anim.pause();
anim.currentTime = anim.effect.getTiming().duration * 0.4;

And if you want the animation itself rather than a frame of it, a screenshot is the wrong artefact entirely. Record the screen, or capture the @keyframes rule — which brings us to the last option.

4. Stop screenshotting and capture the CSS

Every technique above produces one frame of one state. If what you actually want is to study how a component behaves, or to rebuild it, a picture is a poor container — you get the resting state and none of the transitions, or one hover frame and no idea what it looked like before.

The states live in the stylesheet, not in the element. A :hover rule, a @keyframes block and a transition declaration are all sitting in CSS whether or not anything is hovering — which means a capture that reads the stylesheet gets them all, without you having to trigger anything.

This is what Grabby’s element capture does. Point at a component and it collects the computed styles plus the pseudo-class rules that apply to it, the @keyframes blocks those rules reference, the @font-face declarations the type depends on, and pseudo-elements. The capture opens in an editor where the component is live — you can hover it, resize it between desktop, tablet and mobile widths, and watch the animation run — and export it as standalone HTML or a single-file JSX component.

Copying that by hand from DevTools is harder than it looks, mostly because the styles are rarely on the element you copied. The five things that break when you copy HTML and CSS covers why.

Which one do you need?

The short answer

Nine times out of ten: inspect the element, click :hov, tick :hover, screenshot. It takes about five seconds once you have done it twice, and it works no matter where your mouse ends up.

For anything a script controls, freeze the page with a three-second debugger timeout. And if you are going to need that component again — to rebuild it, or to check what it does at another width — capture its code rather than its pixels. The states are in the stylesheet already.

That choice between pixels and code is the same one behind most capture decisions; the four ways to capture a web page lays out what each format keeps, and interactive state is the row where they differ most.