How Do Windows File Drop Lists (HDROP) Work?

When File Explorer copies or drags files, Windows does not put a zip of their bytes on the clipboard. It puts a list of paths. Microsoft’s name for the standard list is CF_HDROP. Older single-file code still looks for CFSTR_FILENAME / FileNameW. Getting those structures wrong is how an app pastes one file out of ten.

This teardown restates Microsoft Learn. It is not an SDK. Clipboard history still does not store these lists: Win+V is text, HTML, bitmap, 25 items, 4 MB, off until enabled, unpinned clear on restart.

CF_HDROP in one paragraph

Microsoft Learn, Shell clipboard formats: CF_HDROP transfers the locations of a group of existing files. It is a predefined format (no RegisterClipboardFormat). The STGMEDIUM is an HGLOBAL pointing at a DROPFILES structure. DROPFILES.pFiles is an offset to a double-null-terminated array of fully qualified paths.

Example for two files:

c:\temp1.txt\0c:\temp2.txt\0\0

DragQueryFile reads the list. Call it with iFile = 0xFFFFFFFF to get the count, then call once per index. If the object was created during a drag, DROPFILES.pt can hold the drop point; DragQueryPoint retrieves it.

The bytes of temp1.txt are still on disk. Delete the file before paste and the paste fails.

Related Shell formats

Learn groups several formats with HDROP. The ones that show up in real bugs:

A complete Explorer copy usually offers HDROP plus a preferred effect (copy versus move for Cut). A minimal app that sets only FileNameW will look fine in testers who copy one file and break on a multi-select.

Why “Electron saw one file”

Several separate mistakes produce the same screenshot.

Read FileNameW only. The wide filename format is a single string. The other nine paths in the HDROP blob are ignored. Fix: enumerate HDROP with DragQueryFile.

Read HDROP count as 1 because of ANSI/Unicode. DROPFILES.fWide says whether the path array is Unicode. Parsing it as ANSI (or the reverse) can stop at the first wide NUL and report one file. Use the Shell helper instead of hand-rolled walkers when possible.

HTML5 DataTransfer.items vs files. In Chromium, a drop can expose items as a list and files as a FileList. Some wrappers historically mapped only files[0]. Native HDROP had all paths; the JavaScript layer dropped them. Current Electron has improved; apps on old bridges still show the bug.

webUtils.getPathForFile on one File. A web drop of ten files is ten File objects. Code that only looks at event.dataTransfer.files[0] is an app bug, not a Windows limit.

Clipboard paste versus drop. navigator.clipboard.read() in the browser does not return HDROP. A web app that handles drop but implements paste as text will “lose” files on Ctrl+V. Why Some Apps Accept Paste but Reject Drag is the opposite symptom; this is its sibling.

Windows itself will put every selected path in one HDROP. Explorer does not silently keep one file.

Building a list (sources)

To put files on the clipboard or into a drag:

1. Allocate a DROPFILES + path array with the double NUL.
2. Set fWide = TRUE on modern Windows.
3. Offer CF_HDROP on the IDataObject.
4. Set CFSTR_PREFERREDDROPEFFECT to DROPEFFECT_COPY unless this is a Cut.
5. For a drag into old targets, also offering FileNameW of the first file is compatibility, not a substitute.

For a screenshot that should land in Explorer, write a temp PNG, then build HDROP pointing at that PNG. A DIB alone will not do. How to Drag an Image Out of Clipboard History.

Virtual files (content not yet on disk) should use FILEDESCRIPTOR + FILECONTENTS, not a fake HDROP to a path that does not exist.

Optimized moves and Cut

Explorer often performs an optimized move on the same volume: the directory entry is updated, bytes are not rewritten. CFSTR_PERFORMEDDROPEFFECT may be DROPEFFECT_NONE even though the user saw a move. Sources that must update a database should read CFSTR_LOGICALPERFORMEDDROPEFFECT. This is why a clipboard app that thinks “Cut means I should delete the source” can destroy data if it also deleted after an optimized move. Prefer letting Explorer finish the contract.

What this means for Win+V users

None of these structures appear as history cards. Why You Cannot Drag Old Clipboard Files Into Explorer. Cloud text sync will not transport HDROP. Does Windows Clipboard Sync Upload What You Copy?.

To move many files today, use Explorer. How to Copy Multiple Files and Paste Them Somewhere Else.

What this means for a shelf

A local shelf that wants to re-drop yesterday’s files must persist either:

• the paths, and fail clearly if they are gone, or
• private copies, and HDROP those copies.

Edge-Drop’s OLE startDrag path is this structure plus a temp file for images. It is optional. It does not change how Explorer itself copies files.

Folders in the list

A selected folder is one path in the HDROP array. It is not an expansion of every child. Paste in Explorer duplicates the folder node (and, in a normal copy, its contents as a tree). An app that “opens each dropped path” should GetFileAttributes and decide whether it received a directory. Treating a directory as a file handle is a common crash.

Nested selections (a folder plus a file already inside it) can duplicate data on paste. Explorer will still list both paths. Clean the selection before copy when that matters.

MAX_PATH and long names

Legacy MAX_PATH (260 characters) still bites some DragQueryFileA callers. Prefer the wide API. Paths that exceed legacy limits can exist on modern NTFS. If a paste fails only for deep trees, long-path awareness in the target is the suspect, not a “clipboard size” myth. History’s 4 MB cap is irrelevant; HDROP is not stored there.

CFSTR_SHELLIDLIST versus HDROP

PIDL lists can describe items that have no file path (a Control Panel apple, a library root). An app that only implements HDROP will ignore those drags. That is correct if the app only opens files. It is a bug if the app advertised “drop anything from Explorer.” For files on NTFS, HDROP is enough. For This PC / namespace folders, expect SHELLIDLIST or a failed drop.

Clipboard history still stores neither.

Checklist for app developers

• Enumerate all HDROP names; never assume one.
• Honor fWide.
• Do not treat FileNameW as the full selection.
• On drop, iterate dataTransfer.files (or the native HDROP) completely.
• Distinguish clipboard paste from drag; implement both if the UI implies both.
• Never HDROP a path that was not checked for existence if the UX promises a paste.
• Leave optimized-move deletion to the Shell unless the app is the file manager.

Related reading

• Copying a Folder to the Clipboard: What Gets Stored
• Dragging Several Files as One Stack
• Why You Cannot Drag Old Clipboard Files Into Explorer
• How to Get a Screenshot Into Photoshop Without Recopying

Sources

• Shell clipboard formats (Microsoft Learn) — CF_HDROP layout, FileName, FILECONTENTS, drop-effect formats.
• Handling Shell data transfer scenarios (Microsoft Learn) — DragQueryFile count via 0xFFFFFFFF; CF_HDROP as the simple retrieval path.
• DROPFILES structure (Microsoft Learn) — pFiles offset and fWide.
• DragQueryFile (Microsoft Learn) — extracting each path.
• Using the clipboard (Microsoft Support) — history still does not treat HDROP as a stored type.

Copy. Stack. Drop.

Transform your clipboard into an interactive edge shelf. Stack, pin, and drag assets into any app with zero friction.

Download for Windows Get from Microsoft Store

How to Install Guide · First 10 Minutes Guide · Drag & Drop Guide · Edge-Drop vs Win+V · Support