useLayoutEffect

The plain-language idea

useEffect's callback runs after the browser has painted the screen — the user might see a frame before your effect runs. useLayoutEffect's callback runs synchronously after DOM mutations, but before the browser paints — it blocks the paint until it's done.

function Tooltip({ targetRef }) {
  const [position, setPosition] = useState(null);

  useLayoutEffect(() => {
    const rect = targetRef.current.getBoundingClientRect();
    setPosition({ top: rect.bottom, left: rect.left });  // measure, then adjust, before paint
  }, [targetRef]);

  return position && <div style={{ position: "absolute", ...position }}>Tip!</div>;
}

If this used useEffect instead, the browser could paint the tooltip at its default (wrong) position for one frame, then snap to the measured position — a visible flicker. useLayoutEffect measures and adjusts before the user ever sees the wrong frame.

useEffect fires AFTER the browser paints — the user can see a one-frame flicker before it runs.

BackNext

What people usually miss

Watch out

• useLayoutEffect blocks the browser's paint. Slow work inside it delays every visual update, which is exactly the tradeoff for its timing guarantee — use it narrowly, not as a default replacement for useEffect.
• Both hooks run after render and after the DOM is updated — the difference is purely about when relative to paint, not whether the DOM is ready. Both can safely read ref.current's measurements.
• Server-side rendering has no browser paint to synchronize with, and useLayoutEffect logs a warning on the server — components using it need a client-only guard, or React will (correctly) flag the mismatch.

Why this matters in interviews

"You built a tooltip that flickers to the wrong position for a split second — how do you fix it?" is a concrete, real bug, and correctly diagnosing it as a paint-timing issue (not a re-render issue) is what separates knowing the two hooks exist from actually understanding why they differ.