In this article, we'll learn how copying and pasting works, how cutting and pasting works, or how text, images, files, and other data is transferred from one place to another in the computer via the clipboard. Hopefully, by understanding how this works internally, you'll be able to understand why sometimes copying and pasting doesn't work, and perhaps learn new ways you can use the technology.
Data Transfer
Copying and pasting are two distinct operations to complete a single task: there is a piece of data located in some place, and the user wants to move it to some other place. Thus, there needs to be some way to indicate to the programs where the piece of data currently is (e.g. by copying it), and where should it go afterwards (e.g. by pasting it). This is what copy and pasting does.
There other ways we could achieve this. Fo example, we could simply select these places from a list somehow, or enter some code to represent them, but that's not as fast or as easy as simply copying and pasting, or, alternatively, dragging and dropping. That's why these two methods, copy and paste and drag and drop, became the conventional ways to transfer data within applications, and specially across applications.
This article focuses on the clipboard, but much of its concept also applies to drag and drop.
Intra-Process and Inter-Process Data Transfer
Within a single program, it's very easy to transfer data from one place from another. That's because all the data in memory belongs to that program—it was the program that put it in the RAM in first place—so there are no privacy or security concerns about the program moving around the data that it put in memory in first place, nor data format issues since the program decided its own format.
In the past (Windows XP era, I believe), it was possible for a single program to look at the data of all programs currently running in the computer, including any text inside any textbox, including any passwords currently typed into textboxes despite the fact they showed as asterisks or circles to human users. Nowadays, this is no longer possible, as modern operating systems isolate what memory addresses each program can access.
Consequently, in order for one program to transfer data to another program, some method supported by the operating system must be used. There are different operating systems (Windows, macOS, Linux Mint), so the way it works on each of these tends to be different, specially from one version to another
Additionally, even ignoring these barriers, in order for two programs to communicate with each other a common protocol must exist. The data in the computer is just bytes. There is no "label" for these bytes, no metadata, so there is no way to know what each byte means just from looking at the bytes. You must know what they're supposed to be before you start processing them.
This protocol must also be extensible somehow. Observe that you can copy data in a program made today and paste text in a program made in the 2000's, meanwhile you can also copy and paste layers in an image editor, or clips in a video editor. How can this all be done using the same system?
The Closed, Proprietary Method
In some cases, you can copy and paste things within an application that are very unique to that application, and consequently there is no way to transfer the data to another application.
For example, let's say you're moving around a video clip inside DaVinci Resolve. What should happen if you instead paste or drop it inside a file manager, or inside an image editor, or inside a web browser?
If there is no good answer for this, the application may simply avoid interacting with the operating system at all and handle all the data transfer internally. In this case, there is no need for a common protocol either.
For example, the application may have an unique identifier for each video clip currently in memory, such as an unique number, e.g. 4. When you copy a clip, it simply remembers the identifier of the selected clip, and when you paste, it simply finds the clip by the identifier and moves or duplicates it from one place to another.
If you somehow transferred this identifier to another application, that application wouldn't be able to do anything with it, because the only data it would get is a number like "4" and that doesn't mean anything without access to the rest of the video clip data.
The rest of the video clip data is a bunch of bytes created by DaVinci. DaVinci could allow other applications to access it, but if they did that, they would need to keep those bytes in a stable structure. This is also known as an interface. In other words, DaVinci wouldn't be able to update their program in a way that changed the byte structure of the video clips, because if they did that, every application that has access to it would require an update as well, making the whole thing a huge waste of time.
Other applications would have to waste time updating every time DaVinci changed its format. If they didn't, it would have been a waste of time for DaVinci to bother with this at all.
In this case, we normally say DaVinci uses a closed, proprietary format. Proprietary means that its their own format, as opposed to a commonly agreed standard. And closed means that they don't tell other people how it works, mostly because they don't intend to support other people using their proprietary format.
Copying Text from One Application to Another
When you copy and paste text from one application to another application, what happens exactly depends on the operating system.
The Clipboard on Windows
On Windows, if the application wants to support pasting text in other applications, then the clipboard will be used. The clipboard is a temporary area owned by the operating system where cut or copied data is sent to, and it stays there until it has been pasted.
Observe that this means that to the clipboard there is no difference between data that has been cut and data that has been pasted. It simply holds data, and isn't aware of why the data is there. We'll see why this is important in a bit.
On previous versions of Windows there used to be a system tool called clipbrd.exe that displayed whatever was in the clipboard at the time. It was pretty neat. Nowadays we have clipboard managers that keep a "clipboard history." Essentially, instead of the clipboard holding only a single item of data, every time you copy something it gets added to a pile of items, and the topmost item of this pile is what is sent when you paste.
The Broken Linux Clipboard
On Linux, the way it used to work (because of X11) was simply insane and I have no idea what took they so long to fix it. Instead of placing copied data in a temporary area like Windows does, Linux simply remembered which application initiated a copy. When data is pasted, the target application pulls the data from the application that copied it.
This may sound like the same thing, but it isn't.
For instance, if you copy data from a text editor, and then close the text editor, the text editor is no longer running, so it's no longer in memory, including the text you just copied. This means that for a long time on Linux if you opened a text file, copied a line of text, closed the text editor, and tried to paste it somewhere else, it would just not work. Although you could fix this by installing a clipboard manager, this was the way it worked by default on many Linux distributions.
It's honestly hard to believe someone managed to program something as simple as copy and paste wrong, but as you can see, it's totally possible.
The Media Type (MIME) Protocol
When data is transferred from one application to another, it's necessary to label that data somehow so we know what type of data is being transferred. As data is just bytes, and bytes contain no metadata about themselves, we need some other bytes to tell us what those main bytes mean. For data transfer protocols like the clipboard, this means there are at least two fields one application must set that the other application is able to access:
- The data.
- The media type of the data.
The media type is a text label in an open standard format called MIME. This is similar to how file extensions work, except it's a proper standard with a registry of known MIME types for all data types, and this registry is used not just in copy pasting, but also in several other ways.
For instance, whenever you download something from a website, the web server tells your web browser the MIME type of the data, so it can tell whether a URL is a text file or an image file even if the URL doesn't contain a file extension, or even when the file extension doesn't match the type of the file located by the URL.
For plain text, the MIME type is text/plain.
This means that whenever text is copied to the clipboard, we'll put the text in a field, and in the other field it will be written text/plain.
This system is also used in drag and drop.
Querying the Clipboard
Applications can query the clipboard at any time to see if there is data in there that it supports. This allows them to make the "Paste" action in the Edit menu on the menubar greyed out (disabled) when there is no data in the clipboard or no data of a type that it supports.
If you copy data and the action is greyed out, it's either because the application doesn't support the MIME type the other application specified, or because you actually didn't copy the data at all.
Observation: as a programmer, I don't Ctrl+C and Ctrl+V code. I Ctrl+X, Ctrl+Z, and Ctrl+V code. Because it's faster when I make a mistake anyway.
When is Paste Greyed Out
Naturally, it would be a waste of CPU resources to just check the clipboard every instant to see if there is something in it, so the way it's normally done is that the application waits until the window has gained focus (the user clicked on the window) to check the state of the clipboard. After all, you can't interact with any of the menus without giving the window focus first, so this is a good time to check if something happened outside the application that could have affected the state of items inside the application.
This method is also often used to check if files have changed in the filesystem while you weren't using the application, so switch to one of its windows triggers the checking process.
An alternative method would be if there is some way for the system to notify the application the clipboard has changed. I'm not really sure if such method is available for all systems, specially not Linux running Wayland instead of X11.
Copying Rich Text but Pasting Plain Text
There are two main types of text in the computer: plain text and rich text. Plain text is a simple sequence of bytes where each byte or sequence of bytes represents a character according to a character encoding like ASCII or UTF-8, while rich text may contain formatting, which means bold, italic, font size, etc.
This creates a bit of a problem when we try to copy rich text from one application like a rich text editor (Microsoft Word, LibreOffice Writer), or even an application that can display rich text (web browsers displaying HTML webpages, or PDF's), and try to paste it somewhere that only supports plain text.
The problem is that the application must convert the rich text to plain text, as it doesn't support rich text. Theoretically, it could do that, if there was only one format called "rich text" or "text/rich" that everybody used, but unfortunately that isn't the case. HTML text will be text/html, while text editors may have their own proprietary formats that allow them to do things like pasting only the styling without pasting the actual text, for example. In that case, every year there may be a new rich text editor with its own new proprietary format, and it just becomes impossible to support all of this.
Multiple Formats for the Same Data
The solution to this problem is that the application that copies data into the clipboard can specify multiple formats instead of just one. This means that it's them doing the conversion, not the target application.
For example, if we copy rich text from a web browser, it will create a new clipboard item with the type text/html, convert this text/html to text/plain, and then tell the clipboard that that item has an alternative version of the data that is in text/plain format instead.
When the data is pasted into a text editor that supports rich text, or, more specifically, that supports pasting text/html, it can just take this piece of data, but if the text editor only supports text/plain, it can take the alternative version provided by the source application instead.
Choosing Between Formats when Pasting
Although it's possible for an application to check all types available before picking one, often the application automatically selects the type that makes most sense, and doesn't allow the user to choose the format themselves. This generally works well because in most cases when you copy something, what's placed in the clipboard are data pieces of similar types, and when you paste something, only one type makes sense. However, that's not always the case.
A good example occurs when you copy rich text from a web browser and try to paste it in an application that also supports rich text, but you want to paste it without the formatting. For example, let's say the text in the webpage is red because all text is red on that webpage. If you paste it, it may paste red text, when you really want just the text, plainly.
In this case, there often is a method to paste without formatting, which means either the text/plain type is selected, or the formatting is removed in a middle step by the application where you're pasting.
Toolkits
Most applications do not interact with the system's clipboard directly. Large, mainstream applications may do this, but normally the way it works is that a small application developer will simply use a toolkit that handles most of it, such as Qt or GTK, which means that if those toolkits behave in a certain way, that just becomes the way applications built with them work for no particular reason other than the fact the developer would have to program the behavior themselves otherwise.
This means that in most cases developers do not specifically set that a piece of data is plain/text. They use some toolkit code that says copyTextToClipboard or something like that, and the toolkit handles the minor technical details for them.
The average text box is also entirely implemented by a toolkit, and this may include even its context menu, undo/redo and copy/paste behavior. If you select text from a text box made in Qt and copy it with Ctrl+C, none of what you did was programmed by the developer of the application, it was programmed by the developer of Qt toolkit.
This is great because it saves development time and provides a consistent and convenient behavior.
On the other hand, it also means that inexperienced application developers can have trouble implementing a real Edit -> Paste menu since they just aren't used to how any of this works, because for the most part it was handled by the toolkits.
There are even some extreme cases where, in order to do a certain thing, you need a function provided by one operating system that doesn't exist in other operating systems, but the cross-platform toolkit you used doesn't provide a way to do that, it only provides methods that work in all systems, which means you have to program it yourself, and this may even lead to the application behaving in different ways from one system to another.
Copying and Pasting Images
Images work fundamentally the same way as text, except they're a bit more complicated because there are many different well-supported image formats and many of them are lossy formats.
In the simplest scenario, let's say that you select a rectangle in an image editor and copy it, and then paste it somewhere else. There is no MIME type for "rectangle of pixels," so we must encode this data in a well-supported lossless image format instead, and that format will be PNG, whose MIME type is image/png.
It's worth noting that BMP is a simpler format than PNG, because PNG has a compression/decompression step while BMP does not. However, the BMP bitmap format is a proprietary Windows format, and not an open format like PNG. That's probably why PNG is normally used instead.
After encoding the pixel data in PNG format, it can be pasted in any program that supports PNG, which is probably just any program.
Transparent Images
The PNG format supports transparency, but for a long time it wasn't really possible to copy and paste transparent images in all sorts of applications. This was a long time ago, so I don't remember exactly which applications had this issue, probably a web browser and some open source image editors. To this day I still feel surprised when I paste a transparent image and it actually pastes the transparent pixels.
Copying JPEG's to the Clipboard
It's possible for an application to data in the JPEG format into the clipboard, but there is often no reason to do that.
JPEG is a lossy format, which means that if we take some pixel data and save it as a JPG file by compressing it using the JPEG method, then load the pixel data back by decompressing it, the data we load will be different from the data we saved. We lost data when we saved it.
Consequently, if we have uncompressed pixel data in memory, in order to put this in the clipboard as JPG we would need to compress it, which would make us lose data, which means that when we paste it, we wouldn't even be pasting the pixels we copied. This is just all sorts of wrong. There is no reason to do this.
The only way for this to make sense is if the application had the original, compressed JPEG data in memory, and it transferred that data to the clipboard. In this case, the pixel data uncompressed by the application that you copied from would be identical to the pixel data that will be uncompressed by the application you pasted to.
However, this is unlikely to happen because there is often no reason to keep the uncompressed JPEG data in memory after it's been uncompressed into pixel data you can display on screen.
Animated Images, GIF's and WebP's
The PNG format doesn't support animation, which means if we copy an animated image, such as a GIF or WebP, we can't store the whole animation as image/png, consequently, often when you do this, only one frame is copied, typically the first frame of the animation.
As with JPEG's, it not possible to copy as image/gif or image/webp without being able to reconstruct the compressed data exactly the way you got it. GIF is technically a lossless format, so long as your pixel data has less than 256 unique colors, so it should be possible to convert any 8bpp frames into a valid GIF. However, in order to do this the program would need a GIF encoder.
As mentioned previously, it's typically very easy to copy things to the clipboard using a toolkit, but toolkits don't really provide ways to do unusual things like copying an animated GIF to the clipboard, so any program that wanted to do this is probably going to have to program it themselves, and this involves some low-level programming knowledge that the application developer may have never needed up until this point.
Additionally, even if you COULD copy the GIF into the clipboard, where would you paste that into? Presumably, any application that lets you drag and drop image files into the application could trivially support loading the image data from the clipboard instead of from a file. It's literally the same data, the only that changes is where it comes from. But let's consider how would this occurs in practice.
A rich text editor is typically used to write documents for printing. You can't print an animated GIF unless you live in Hogwarts, so this wouldn't be very useful there. In fact, I've never even tried to drag and drop a GIF into a Word document so I don't really know if even that is supported.
An image editor like Photoshop can certainly open GIF files as frames or layers, but what should happen when you paste it? Does it paste layers or frames? The proper way to handle ambiguities like this would be to display a dialog window and let the user choose, and that's a lot more work than just pasting a PNG. Dialogs have text, and having human-readable text in an application with users worldwide means you need translations for it.
In a video editor, normally the project file doesn't contain the data of clips embedded inside itself, but merely keeps track of the filepaths of the video files associated with the video clips, consequently you may not even be able to paste a static image, much less an animated one.
For WebP, things get a bit more complicated since an animated WebP may be lossless, but it could also be lossy. While you could simply send to the clipboard a lossless WebP regardless of whether you got a lossy WebP or not, depending on the WebP, this could be a lot of uncompressed data, and may even hit hundreds of megabytes if it's particularly large and long animation. I'm not sure if the system will let you copy that much data at once since I never tried to do that.
Copying and Pasting Files
Copying and pasting files works entirely within an file manager. When a file is copied, the file manager internally remembers the filepath of the copied file, and when it's pasted, it creates a new file with the same filename as the copied file in the current location being browsed and copies the data of the copied file into the new file.
In some file managers, copying a file also copies its filepath to the clipboard. The MIME types of this filepath are various and vary from file manager to file manager. For example, text/plain is possible since a filepath is a text code. Additionally, text/uri-list is used for lists of URIs, which can include both URLs on the Internet a files located in the filesystem annotated with a file: protocol, e.g. file://C:\image.jpeg. Additionally, some file managers have their own proprietary formats that may be sent to the system clipboard even if nobody else uses it.
When a folder is copied, the same thing occurs, except that when pasting folders the folder and all its descendants are duplicated.
Cutting and Pasting Files
Cutting and pasting files is a rather unique operation due to the risks involved in this task.
Normally, when you cut something, what happens is that it's copied to the clipboard and then deleted from the application. In other words, cutting is the same as copying and then deleting. This deletion may be undone if the application supports the undo operation, but in any case what it means is that it's deleted from the data that would be saved if you saved the document.
This isn't how it works with files in file managers. When a file is cut, it doesn't get deleted. The reason for this is very simple. The data that exists in the clipboard is stored in the RAM, and if the computer loses power, the data in the RAM is gone. This is also called a volatile memory. Meanwhile the data in a filesystem typically comes from a non-volatile mass storage medium such as HDD or SSD, which means that even if the computer loses power, the data will remain.
If files were deleted when cut, that would induce the risk of accidentally losing files forever if the computer lost power before pasting. This risk could be amended by saving the clipboard to disk, but even in that case we would have another, similar disk.
Without a clipboard manager, we can only have one item in the clipboard, but even with a clipboard manager there is a maximum number of items that are kept in the clipboard, and when you reach that limit, copying something erases the oldest item from the history. This means that if you cut one file and then cut another file without pasting the first one, if cutting deleted files, this operation would have permanently deleted the first file you cut.
For these reasons, the way file managers handle cutting is fundamentally different from other applications.
When a file is cut, it's simply marked inside the file manager as being cut, and when you paste, all the file manager does is move the file from one location to another. The file is never deleted, a new file is never created, and data inside the file is never transferred to anywhere.
A filesystem typically consists of a registry of where the bytes associated to a filepath start and end in a partition of a mass storage medium. This registry is very lightweight compared to the actual data of the files. Consequently, merely changing this register is faster than copying bytes of files.
For this reason, shells provide separate methods for moving files and for copying files. On a simple filesystem, copying files requires creating a new file and filing the new space with bytes, while moving files only requires changing the registry, which is faster, specially with large files gigabytes in size. Moving tens of thousands of small files, however, may take a moment nevertheless since all their records must be updated in the registry.
Observation: if I remember correctly, some filesystems achieve move-speed performance when copy pasting because they're optimized to use the same space in disk if two files are identical, meaning a new space is only created and data copied when you first modify a copy.
Note: this behavior only works within a same filesystem. Moving a file from one partition to another, or from one disk to another, requires crating a new space for the file's bytes in the other partition, so in this case "moving" or "cutting and pasting" means the same thing as "copying and then deleting." For safety, the operating system should first check if the bytes of the pasted file are identical to the files of the cut file before deleting it, in case some unseen error or defective software or hardware caused the data to become corrupt.
The Clipboard Across Windows
Although applications typically run as a single main window, file managers tend to have multiple windows open at the same time, in the sense that there is a single process running and this single process has opened multiple windows.
This means that when you cut and paste a file within a file manager from one window to another, everything is still happening within the same single process. You do not have two different processes running transferring data from one to the other.
We can observe this by trying to do the opposite. If we try to cut a file from inside a file manager and then paste it in a different file manager, for example, it won't work. That's because the data inside the clipboard never indicates what should be done with the original file.
While we can put filepaths inside the clipboard with text/uri-list, there is normally no way to indicate if those filepaths were copied or cut. There is no way to indicate why that data is in the clipboard in the first place.
We could have our own custom format that contained that information, but even then it would be too complicated to work. That's because there is no protocol within the clipboard system to notify one application that a different application has pasted the data you copied or cut from it.
This means if you cut a file from one file manager, and try to paste it in another file manager, even if the second file manager could perform the movement itself, there is no way for the original file manager to be notified that the file has already been moved by the second file manager.
In order to do that we would need a separate method for inter-process communication and put inside the clipboard some information that can be used to use this separate method (e.g. a way to identify which process is the process of the file manager from where the file was cut).
This is just too complicated to implement considering that normally you just wouldn't even have two file managers running at the same time.
One case where you can encounter this issue is if you open an application that resembles a file manager, like an archiver such as WinRAR or 7-Zip. You won't be able to cut a file from File Explorer and paste it into the archiver causing it to be moved, even though in theory this should be very intuitive.
Special Considerations for Web Applications
Web applications can't query the clipboard because they're running inside a web browser's sandbox.
While the web browser itself is able to check the clipboard any time it wants, the web browser doesn't allow random webpages on the Internet to check your clipboard. If they did, and you copied a password, for example, then every single webpage would be able to see it, which is pretty bad.
Every application running in your PC can still the contents of your clipboard at any time. They can also delete all your files if they wanted to, which is a good reason not to install anything you don't believe to be trustworthy.
As a consequence, webpages can't have a button or menu that reads "paste," because they can't fetch data from the clipboard. Well, they can do that, but then you'll see a scary warning telling you the webpage wants clipboard access when you click on it.
Normally, to paste something in a webpage you either press Ctrl+V or you can right click to open the context menu and pick the paste option. Both of these operations are provided and handled by the web browser itself. The web browser takes all the data in all formats available and passes it down to the webpage when you press Ctrl+V.
Pasting Plain Text in WYSIWYG Editors
On webpages featuring rich text WYSIWYG editors (e.g. WordPress, Tumblr), plain text is pasted by pressing Ctrl+Shift+V instead of Ctrl+V. Before writing this article, I assumed that this was something the editor implemented it self, but now that I think about it, they do not have clipboard access, which means that the web browser handles the Ctrl+Shift+V keyboard shortcut and converts the rich text to plain text before the web application has access to it.
Pasting Images in Text Fields
A convention found in image search engines is that you are able to perform a reverse image search by giving keyboard focus to a text box that asks for the image URL but instead pasting an image into that text box.
This is possible because the webpage checks the MIME type of what has been pasted, and if it's an image, it assumes that user wants to search by image.
It's worth noting that this is a rather unintuitive feature. Webpages don't normally request access to the clipboard, which means that the typical way for you to send something to the webpage from the clipboard is going to be pasting it into a text box even if that text box has nothing to do with what you're trying to paste, but you wouldn't know that unless you tried to do it once.
Copying Data Into the Clipboard
Webpages also aren't allowed to copy data into the clipboard whenever they want without permission. Web browsers use heuristic to determine whether the webpage should be allowed access to the clipboard.
For example, if the webpage tries to put something in the clipboard as consequence of the user clicking on something on the webpage, the web browser will allow it. That's how those "copy this" buttons are allowed to function. However, if there is no user interaction, the web browser will prevent the webpage from putting something into the clipboard.