Can You Put Binary Files on the Clipboard? (Don't)

A developer who tries to copy a binary file — an .exe, a .zip, a .db, a .bin — by selecting it in a text editor and pressing Ctrl+C is about to corrupt data. The clipboard will accept the bytes, the destination will accept the paste, and the resulting file will be wrong. The checksum will not match. The executable will not run. The archive will not open. The database will not load. This guide explains why binary files do not survive the clipboard, what the clipboard actually carries, and what to do instead.

For neighbouring topics, see the .env file should never touch history, remote SSH in VS Code and the local clipboard, and best clipboard habits for developers in 2026. For clipboard mechanics, see what the Windows clipboard can and cannot store.

What the clipboard actually carries

The Windows clipboard is a multi-format container. When an application places data on the clipboard, it can register multiple formats simultaneously: plain text, HTML, bitmap, file drop list, and a long tail of application-specific formats. The destination asks for the most specific format it understands.

The first-class formats in clipboard history are:

• Plain text (CF_UNICODETEXT) — UTF-16 text. What most applications produce on Ctrl+C.
• HTML (CF_HTML) — an HTML fragment with a header describing the offset of the content.
• Bitmap (CF_DIB) — a device-independent bitmap, used for screenshots and image copies.

Files, when copied from Explorer, are carried as a file drop list (CF_HDROP) — a list of file paths, not the file contents. The clipboard does not hold the bytes of the file; it holds the path to the file. When the user pastes into Explorer, Explorer reads the path and copies the file. When the user pastes into an application that does not understand file drop lists, the application receives nothing useful.

The Windows clipboard history panel does not surface file drop lists as cards. The history shows text, HTML, and bitmap only. This is by design: file references are not history items, they are operations.

Why binary file contents corrupt on the clipboard

When a developer opens a binary file in a text editor (Notepad++, VS Code with a hex extension, or — worst case — plain Notepad) and copies the visible text, the editor has already decoded the binary bytes into a text representation. The decoding is lossy: bytes that do not map to printable characters are replaced with ? or with the Unicode replacement character U+FFFD. Newlines may be normalised. BOMs may be added or stripped.

The clipboard receives the decoded text, not the original bytes. When the user pastes into a new file and saves, the saved file is the decoded text, re-encoded according to the destination's encoding. The result is not the original file. It is a text approximation of the original file.

The corruption is invisible until something tries to use the file:

• Executables — the file will not run. Windows reports "not a valid Win32 application" because the PE header has been mangled.
• Archives (zip, 7z, tar.gz) — the archive tool reports "corrupt archive" or "unexpected end of data" because the checksums do not match.
• Database files (SQLite, db) — the database engine reports "file is not a database" or "database disk image is malformed" because the file header is wrong.
• Images (PNG, JPEG) — the image viewer reports "cannot decode" because the magic bytes are missing or wrong.
• Compiled objects (.o, .obj, .class) — the linker or runtime reports "bad magic number" because the format header is wrong.

The pattern is the same in every case: the clipboard carried text, and the destination saved text, but the source was binary. The trip through the clipboard converted the binary to text and back, and the conversion was lossy.

What "copy the path" means

The right way to move a binary file is to copy the file itself, not its contents. On Windows, this means one of:

• In Explorer, Ctrl+C on a selected file. Explorer places a file drop list on the clipboard. Pasting into another Explorer window copies the file. Pasting into most applications does nothing useful, because the application does not understand file drop lists.
• In Explorer, Shift+right-click → Copy as path. This places the file's path as quoted text on the clipboard. Pasting into a terminal gives the path as a quoted string. This is the right approach when the destination is a command that takes a file path argument.
• In a terminal, clip < file.bin does not work. clip reads stdin and places it on the clipboard as text. For a binary file, this is the corruption pattern described above. clip is for text only.

The "copy the path" approach gives the destination a reference to the file, not the file's contents. The destination (a terminal, a script, an email) decides what to do with the path. If the destination needs the file's contents, it reads the file from the path.

Why this is sometimes tempting

The temptation to copy binary contents comes from a few common situations:

• Sharing a file with a remote teammate. The developer wants to send a binary file through Slack or email. The chat client supports file attachments, but the developer tries to paste the file's contents instead of attaching it. The paste fails or corrupts.
• Moving a file between two machines. The developer wants to move a binary file from a local machine to a remote machine over an RDP session. RDP clipboard redirection supports file copy in some configurations but not all. The developer tries to copy the file's contents as text.
• Inspecting a binary file. The developer wants to look at the bytes of a binary file. They open it in a text editor, copy a section, and paste into a hex viewer. The paste is the decoded text, not the original bytes.

In each case, the right tool is different. For sharing, use the chat client's attachment feature, or upload the file to a file-sharing service and share the URL. For moving between machines, use RDP file redirection, SCP, or a file-sync service. For inspecting, use a hex viewer (HxD, Hex Fiend, xxd) that reads the file directly, not a text editor that decodes it.

The hex dump alternative

For inspecting a binary file, the right approach is a hex dump. A hex dump is a text representation of the binary bytes that preserves the byte values: each byte is rendered as a two-character hex pair, and the ASCII representation is shown alongside. The dump is text, so it survives the clipboard intact. The dump is also human-readable, so it can be shared in a chat or ticket.

The trade-off: a hex dump is not the binary file. A destination that needs the binary file cannot reconstruct it from a hex dump without a reverse utility (xxd -r). The hex dump is for inspection, not for transfer.

For more on hex dumps, see copying hex dumps and keeping alignment.

When file drop lists do not work

File drop lists are the right clipboard format for moving files, but they have limitations:

• They do not cross integrity levels. A file copied from a non-elevated Explorer cannot be pasted into an elevated application. This is the same UIPI restriction that affects drag-and-drop. See elevated VS Code and drag-drop failures for the broader pattern.
• They do not cross RDP sessions reliably. RDP clipboard redirection for files requires specific Group Policy settings on both ends and is often disabled in enterprise environments. See remote desktop copy paste not working for the troubleshooting path.
• They are not in clipboard history. A file copied from Explorer does not appear in Win+V history. The user can paste the file once, immediately, but cannot re-paste from history.

For each of these cases, the workaround is to copy the file's path as text, not the file itself. Shift+right-click → Copy as path puts a quoted path on the clipboard, which survives history, integrity levels (mostly), and RDP sessions (as text).

The 4 MB limit and binary files

The Windows clipboard's 4 MB per-item limit applies to text and bitmap history items. A binary file copied as a file drop list does not hit the 4 MB limit, because the clipboard holds the path, not the contents. A 1 GB video file copied from Explorer pastes correctly into another Explorer window; the limit never applies.

If, however, the developer tries to copy the binary contents as text (the corruption pattern), the 4 MB limit may apply if the resulting text exceeds 4 MB. For a binary file under 4 MB, the text may fit; for a file over 4 MB, the text is truncated and the corruption is even worse.

What to do instead: a decision table

A short checklist

• Do not open a binary file in a text editor and copy its contents. The trip through text corrupts the bytes.
• Use Explorer's Ctrl+C to copy files as file drop lists. Paste into another Explorer window.
• Use Shift+right-click → Copy as path to copy a file's path as text. Paste into terminals and scripts.
• Use a hex viewer for inspection, not a text editor.
• Use file attachments or file-sharing URLs for sharing, not pasted contents.
• Accept that the clipboard is a text-and-image transport. Binary files need a real file-transfer mechanism.

Related reading

• Remote SSH in VS Code and the Local Clipboard
• Copying Commit Messages With the Right Wrap
• Best Clipboard Habits for Developers in 2026
• Clipboard Tools on Multi-Monitor Windows Setups

Sources

• Microsoft Learn — Clipboard formats (Win32) — official reference for CF_TEXT, CF_UNICODETEXT, CF_HTML, CF_DIB, and CF_HDROP, explaining which formats the clipboard actually carries
• Microsoft Learn — File drop lists and the HDROP format — official Shell clipboard documentation, describing how files are copied as paths rather than contents
• Microsoft Support — Copy as path on Windows — official guidance for the Shift+right-click → Copy as path command, which is the safe way to put a file reference on the clipboard
• Microsoft Learn — User Interface Privilege Isolation (UIPI) — official documentation for the integrity-level restriction that affects file copy and drag-drop between elevated and non-elevated processes
• SQLite — Database file format — official SQLite file format reference, used to verify why a clipboard-corrupted SQLite file reports "file is not a database"

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