ClickPaste: pasting clipboard contents as real keystrokes on Windows

The problem: applications that ignore the paste command

ClickPaste is described in one line as a Windows 10/11 notification area app in C# that can paste clipboard contents as keystrokes to whatever location you click. That single sentence contains the whole design. The application does not send a paste keystroke combination, it does not set the target window's text, and it does not talk to the clipboard through any special API. It types the characters, one at a time, as if a person were at the keyboard. That is the point of the tool, because the class of applications that refuse a programmatic paste is exactly the class of applications where you need this. A console window, a command prompt inside a remote desktop session, a login field, an elevated dialog: all of these are awkward or impossible to fill from the clipboard directly, and all of them respond to synthesised keystrokes. The primary language is C#, the licence is BSD-3-Clause, the default branch is master, and the recent release tags are v1.4.4 from 2026-05-05, v1.4.3 from 2026-05-04 and v1.4.2 from 2026-01-30, with the last push on 2026-05-05.

The three step interaction, and why the target comes first

The usage section is short because the interaction is short. You need some text in the clipboard first. Then you click the target notification icon to begin, at which point the app enters a pick a location mode, and you click the window or field where you want the text to land. Your clipboard contents should then be typed as keystrokes onto the window you selected. The ordering is the interesting design decision. Clicking the notification icon first, rather than clicking the destination first, is what makes the tool work with elevated applications. The README explains the constraint: Microsoft requires the ClickPaste binary to be run from the system drive's Program Files folder in order to paste to UAC-elevated processes, and the easiest way to achieve that is to use the MSI installer. So the elevation story is not a footnote. It is a rule imposed by Windows on where the binary may live, and it is why the installer is more than a convenience.

The settings that control how the typing happens

Settings are reached by right-clicking the notification icon and selecting Settings, and the README lists what you can change. You can switch between key typing modes, which matters because a fast typist and a slow typist behave very differently against an application with input validation or a rate limit. You can set how much delay there is before and between keystrokes, which is the same knob viewed from the other side. You can trigger a confirmation when the clipboard contains more than a chosen number of characters, which is a guard against dumping a large block of text into a field that was not expecting it. You can configure which hot key combination will be used, and the README notes you can clear the key textbox with delete or backspace if you want no hotkey at all. Finally, you can configure whether the hot key activates the target selector to pick a paste location or just starts typing immediately.

Installing on Windows, and the Program Files constraint

There are two distribution routes, and the README is explicit about which one to use for elevated targets. You can install ClickPaste using the MSI installer, or you can get the portable ZIP from the Releases page. The note about Program Files is the deciding factor for many people, because it says that in order to paste to UAC-elevated processes, Microsoft requires the ClickPaste binary to be run from the system drive's Program Files folder, and that the easiest way to achieve this is to use the MSI installer. The portable ZIP therefore works for ordinary applications but will not satisfy the elevation requirement, and the app will be running from wherever you unpacked it. The repository layout supports the Windows packaging story, with a ClickPaste.csproj and ClickPaste.sln for the project, a Setup/ directory, an app.manifest, and a sign.bat for code signing.

Where ClickPaste is the wrong tool

The limits follow from the mechanism. First, this is not a clipboard manager. There is no history buffer, no search, no sync between machines and no pinning of items, and the README describes the tool purely as a paste mechanism for whatever location you click. If your problem is that you lose things you copied, this is the wrong program. Second, typing every character means the speed is bounded by human plausible typing, which the delay settings confirm, so pasting a large document into a remote session over a slow link is slower than a real clipboard paste would be, and a large paste is exactly when the character count confirmation will fire. Third, the tool is Windows only, by construction, since it depends on the Windows notification area and the Windows input APIs. And fourth, the elevation rule is a genuine constraint rather than a bug: a portable copy of the tool simply cannot type into an elevated process, which is the case where you are most likely to be working with a password prompt.

The alternative approach, and the trade you are making

The obvious alternative is to solve the problem at the other end, by making the target application accept a paste. In a terminal that means enabling a bracketed paste mode or using a clipboard-aware SSH client, and in a browser field there is usually no problem at all. That approach is better when you control the target, because it is exact and fast, and it carries no elevation restrictions. The approach ClickPaste takes is better when you do not control the target, which is the common case for someone pasting into a console in a remote session or into a system dialog they do not own. The cost of that generality is real though. Synthesised keystrokes are visible to the receiving application as typing, which means anything that reacts to keyboard input, such as a shortcut chord inside your pasted text, will fire, and any application that binds individual keys may behave differently than it would with a real paste. The trade is between one reliable mechanism that works everywhere the OS allows and a per-target fix that is exact where you can make it exact.

Editorial conclusion

Adopt ClickPaste if you regularly need to enter text into a Windows application that ignores clipboard paste, such as a console, a remote session or an elevated prompt, because the tool works by generating real keystrokes rather than sending a paste command. Do not adopt it as a general clipboard manager, since it has no buffer history and no sync, and the README describes it purely as a paste mechanism. Before you install, read the Program Files requirement, because Microsoft only permits pasting into elevated processes when the binary runs from the system drive, and the MSI installer is the easiest way to satisfy that.

Frequently asked questions

Official sources

1. Collective-Software/ClickPaste on GitHub
2. Issues
3. License: BSD-3-Clause
4. README
5. Releases