Styling Drag-and-Drop Visual States with Tailwind and dnd-kit

1. Why dnd-kit provides the logic and Tailwind provides the look

dnd-kit is a headless drag-and-drop library for React, meaning it manages sensors for mouse, touch, and keyboard, calculates collisions between draggable elements and drop zones, and exposes the full state of a drag operation, without prescribing a single CSS class system of its own. That separation is deliberate, because visual feedback for drag-and-drop depends heavily on the specific design system, and a library with baked-in styles would always get in the way here.

For a good user experience, drag-and-drop needs at least three clearly distinguishable visual states: the element currently being actively dragged, the drop zone it is currently hovering over, and a placeholder indicating exactly where it would land on release. Without these three states, it stays unclear to the user whether a drag interaction has even started and exactly where the element would be dropped, which quickly leads to mistakes, especially in sortable lists.

2. Styling the dragged element: opacity, scale, and the DragOverlay

dnd-kit exposes a boolean isDragging state through the useDraggable hook, which can flow directly into a conditional class list. A typical pattern reduces the opacity of the original element at its starting position to a value around 0.4 to 0.5, while the actual, fully visible copy of the element is rendered through the DragOverlay component, which follows the cursor independently of the surrounding scroll container.

This separation between the original, semi-transparent element and the fully visible element rendered inside the DragOverlay is critical for performant drag-and-drop, because the overlay is positioned outside the normal document flow and therefore does not trigger expensive reflow calculations for the surrounding list. On top of the opacity change, a slight scale-105 and a stronger shadow in the overlay make the dragged element visually float clearly above the rest of the list.

function SortableItem({ id, children }) {
  const { attributes, listeners, setNodeRef, transform, isDragging } =
    useSortable({ id });

  return (
    <li
      ref={setNodeRef}
      {...attributes}
      {...listeners}
      style={{ transform: CSS.Transform.toString(transform) }}
      className={`rounded-lg border bg-white p-3 transition-opacity ${
        isDragging ? "opacity-40" : "opacity-100"
      }`}
    >
      {children}
    </li>
  );
}

3. Drop zone highlighting: the isOver state while dragging

The useDroppable hook returns a boolean isOver state that is true exactly when a dragged element is currently hovering over this specific drop zone, evaluated through dnd-kit's collision detection. That state is the most reliable signal that a drop would be possible right here, and it should be visually clear but not intrusive, say through a colored border or a lightly tinted background.

A common design mistake is only making the drop zone visible once it is actually being hovered over, leaving it completely invisible outside an active drag operation. It is better to subtly, permanently mark all generally valid drop zones as soon as any drag operation is active, combined with a noticeably stronger highlight for exactly the zone currently under the element, so the user already sees where dropping is even possible before precisely hovering over it.

function DropZone({ id, isDragActive, children }) {
  const { setNodeRef, isOver } = useDroppable({ id });

  return (
    <div
      ref={setNodeRef}
      className={`rounded-xl border-2 border-dashed p-4 transition-colors ${
        isOver
          ? "border-sky-500 bg-sky-50"
          : isDragActive
          ? "border-slate-300 bg-slate-50"
          : "border-transparent"
      }`}
    >
      {children}
    </div>
  );
}

4. The placeholder element: making the future position visible

In sortable lists, a highlighted drop zone alone is not enough, because the user needs to know not just which area, but exactly which position within the list the element would land in. dnd-kit's SortableContext combined with the arrayMove helper function already calculates that target position while dragging, so an empty placeholder roughly the size of the dragged element can be shown exactly at that spot in the list.

The placeholder itself should be visually recognizable as a temporary state, usually through a dashed border and an almost transparent background, so it stays clearly distinguishable from regular list entries and is never mistaken for an actual, already-existing element. It also matters that the placeholder has the same height as the dragged original element, otherwise the rest of the list visibly jumps around whenever the placeholder appears or disappears.

5. Combining dnd-kit states with Tailwind data attribute variants

Instead of managing every state through conditional template strings in JSX, dnd-kit's state can also be written directly as a data-* attribute on the element, say data-dragging="true" or data-over="true". Tailwind can evaluate these attributes directly in utility classes through its built-in data-[attribute]: variant, which makes the JSX considerably more readable, since the styling logic moves entirely into the class list instead of being scattered across several conditional expressions.

This approach pays off especially for components with several states that can be active at once, say an element that is simultaneously isDragging and part of a certain category. Instead of nested ternary expressions in the JSX, every state combination stays readable as declarative utility classes directly on the element, which noticeably improves maintainability as state complexity grows.

<li
  data-dragging={isDragging}
  data-over={isOver}
  className="rounded-lg border p-3 transition-all
             data-[dragging=true]:opacity-40
             data-[dragging=true]:scale-95
             data-[over=true]:border-sky-500
             data-[over=true]:bg-sky-50"
>
  {children}
</li>

6. Practical example: a sortable task list with full visual feedback

A typical task list with several columns, say for different work statuses, combines all three visual states at once: the dragged task item becomes semi-transparent in its original spot, while a fully visible copy in the DragOverlay follows the cursor. The target column currently under the element gets a colored border, and inside that column, the dashed placeholder appears at the computed target position.

For this interplay to actually feel fluid, all transitions, especially opacity and color changes, should be animated through CSS transition properties rather than switching abruptly. A transition duration of around 150 to 200 milliseconds usually feels the most natural in practice, long enough for a perceivable animation but short enough not to feel sluggish compared to the actual, usually much faster mouse movement.

7. Transform instead of layout properties: performance in drag animations

By default, dnd-kit positions elements while dragging through transform: translate3d rather than layout properties like top or left, because transforms can be processed by the browser on the GPU and never trigger a reflow of the rest of the page. Any additional custom styles, say for a scale effect while dragging, should therefore likewise be implemented through transform: scale() rather than width and height changes, to keep the same performance advantage.

If a layout property like width or margin is accidentally animated instead, while a drag operation is running at the same time, that can produce noticeable jank in longer lists, because the browser has to recalculate the layout of the entire list on every frame. Tailwind classes like scale-95 and translate-x-2 already rely on transform internally and are therefore the right choice performance-wise for effects during active drag interactions.

8. Accessibility: the keyboard sensor and status announcements

Besides mouse and touch, dnd-kit also supports a dedicated keyboard sensor that lets users move elements without a mouse, entirely with the keyboard, usually arrow keys to move and the spacebar to pick up and drop. For that mode to stay comprehensible to sighted keyboard users, the entry currently selected or dragged via keyboard should get the same visual focus state as during a mouse interaction, usually a clearly visible focus ring.

For screen reader users, purely visual feedback is not enough, which is why dnd-kit can emit textual status messages to an ARIA live region through its announcements configuration, say when an item was picked up, which position it is currently over, and where it ultimately landed. Those announcements should be short and precise, so they do not unnecessarily slow down the screen reading flow while still containing all the information needed for orientation.

9. Common pitfalls in drag-and-drop styling

A common mistake is accidentally activating the browser's native HTML drag-and-drop API alongside dnd-kit, say through a forgotten draggable="true" attribute on a child element, which results in a duplicated, conflicting ghost image. dnd-kit works entirely independently of the native drag events API, which is why native drag attributes should be consistently avoided in a dnd-kit context.

A second common stumbling block concerns drag-and-drop inside scrollable containers: without auto-scroll enabled, a dragged element moved to the edge of a scrollable area simply stays there instead of automatically scrolling the container further. dnd-kit offers an autoScroll option for this, but it has to be explicitly enabled and tuned to the scroll speed of the specific use case, otherwise the interaction feels unfinished in long lists.

10. Summary

11. FAQ: Drag-and-Drop Visual States: The Essentials at a Glance