-webkit-user-drag: Browser Support, Values, Limitations

What is -webkit-user-drag?

-webkit-user-drag is a CSS extension that the WebKit team added to control whether the browser treats an HTML element as a drag source. It accepts three values, auto, element, and none, and gives developers a way to override the default drag behavior of links, images, and selected text.

Which browsers does -webkit-user-drag support?

All Chromium and WebKit browsers support -webkit-user-drag. Firefox and Internet Explorer never shipped support, so use the standard HTML draggable attribute as the cross-browser fallback.

What are the values of -webkit-user-drag?

-webkit-user-drag accepts three values, auto, element, and none. Each one tells WebKit how to decide whether the user can pick the element up.

• auto: The default. WebKit applies its built-in rules. Images, links with an href, and selected text are draggable; every other element is not. Most pages never need to set this value explicitly.
• element: Forces the whole element to become the drag source. Click anywhere inside the element and a drag starts, even on a div, button, or span that the browser would not normally treat as a drag handle. Pair it with cursor: grab so the user can see the affordance.
• none: Blocks dragging entirely. The element cannot start a drag, even if it is an image, a link, or selected text. Use this to stop users from dragging a logo, an avatar, or a thumbnail off the page.

The snippet below shows the three values applied to common page elements. Paste it into a stylesheet on a Chrome, Edge, Opera, or Safari build and the rules take effect on the next paint.

/* Default behavior: images, links, and selected text are draggable. */
.card {
  -webkit-user-drag: auto;
}

/* Force a drag source on a div, even though a div is not draggable by default. */
.card.is-draggable {
  -webkit-user-drag: element;
  cursor: grab;
}

/* Block the default drag on logos, avatars, and product thumbnails. */
img.brand-logo,
img.user-avatar {
  -webkit-user-drag: none;
}

There is no inherited value: -webkit-user-drag is non-inherited, so a child element will not pick up the setting from its parent unless you target the child directly. The property has no animation type, no shorthand, and no JavaScript getter on the CSSStyleDeclaration interface beyond the standard webkitUserDrag camel-case alias.

What are the known issues with -webkit-user-drag?

-webkit-user-drag has the smallest cross-browser footprint of any CSS drag control. The painful edge cases land on Firefox, mobile WebKit, and a few open WebKit bugs.

• Firefox refuses to add it: Firefox never shipped a -webkit-user-drag implementation and has no preference flag to turn it on. Sites that need cross-engine drag control must use the HTML draggable attribute on Firefox.
• Mobile WebKit and Blink ignore element: Chrome for Android, Samsung Internet, iOS Safari, and most blink-based mobile browsers parse -webkit-user-drag without errors but do not fire a drag operation when you set the value to element. Setting it to none still works to block the default image drag.
• WebKit Bug 26931: A long-open WebKit bug means -webkit-user-drag: none on an a element with href is sometimes ignored. The fix is to add draggable="false" on the same element as a backup.
• No standards track: -webkit-user-drag has no W3C, WHATWG, or CSS Working Group draft. There is no unprefixed user-drag property planned, so feature detection cannot rely on a future stable name.
• Conflicts with -webkit-user-select: Setting -webkit-user-select: none alongside -webkit-user-drag: element can suppress the drag in older WebKit builds. WebKit Bug 208682 tracks the interaction. Test the combination on Safari 14 or older if you have to support it.
• No effect inside sandboxed iframes: A page in an iframe with the sandbox attribute and no allow-same-origin token cannot start a drag at all, regardless of the -webkit-user-drag value.

In my experience, the cleanest cross-browser pattern is to set both -webkit-user-drag: none and draggable="false" on every image and avatar. Each one alone misses an engine: -webkit-user-drag does nothing on Firefox, and draggable="false" sometimes fails to block the default Safari drag on a link or an image. Combining them costs nothing and removes the ghost-image drag in every browser.

Citations

All -webkit-user-drag version numbers and platform notes in this guide come from these primary sources:

• MDN Web Docs, WebKit CSS extensions: developer.mozilla.org/en-US/docs/Web/CSS/Reference/Webkit_extensions
• MDN Web Docs, draggable global attribute: developer.mozilla.org/en-US/docs/Web/HTML/Reference/Global_attributes/draggable
• MDN Web Docs, HTML Drag and Drop API: developer.mozilla.org/en-US/docs/Web/API/HTML_Drag_and_Drop_API
• MDN Web Docs, Drag operations: developer.mozilla.org/en-US/docs/Web/API/HTML_Drag_and_Drop_API/Drag_operations
• WHATWG HTML Living Standard, drag and drop: html.spec.whatwg.org/multipage/dnd.html
• Apple Developer, WebKit DOM Programming: Dragging and Dropping: developer.apple.com/library/archive/documentation/AppleApplications/Conceptual/SafariJSProgTopics/DragAndDrop.html
• Apple Developer, WebDragSourceAction.image: developer.apple.com/documentation/webkit/webdragsourceaction/1387721-image
• Apple Developer, WebDragDestinationAction.DHTML: developer.apple.com/documentation/webkit/webdragdestinationaction/dhtml
• WebKit Bugzilla 26931, -webkit-user-drag none ignored on links: bugs.webkit.org/show_bug.cgi?id=26931
• WebKit Bugzilla 208682, drag from -webkit-user-select element should not start selection: bugs.webkit.org/show_bug.cgi?id=208682
• Wikipedia, WebKit: en.wikipedia.org/wiki/WebKit