Copy, cut, paste and drop — all detected.
A web page can tell when you paste into it, roughly how you did it, and what you pasted. This is a live demonstration of all three, and an explanation of how each one works.
About this page
One listener, every field
Detection is a single listener on the document, in the capture phase — not a handler wired onto each input. That is why it still sees pastes into third-party widgets, design-system components and anything that calls stopPropagation. The Referral code field below has no paste handler of its own, and is detected anyway.
Where the paste came from is inferred, not reported
No browser API tells a page whether a paste was Ctrl+V, the right-click menu or a drag. It has to be worked out from the order and timing of events: a paste shortly after the paste shortcut is attributed to the keyboard, one arriving with no preceding shortcut to the context menu, and a drop to the drag. That inference is a pure state machine, so it can be tested without a browser at all.
Some pastes never fire a paste event
Mobile paste bars and certain menu paths mutate the field without a ClipboardEvent ever arriving. The detector also watches beforeinput for insertFromPaste and insertFromDrop, which is what catches those.
- Clipboard text stays in your browser. The server is told the shape of an event — what kind, how it was triggered, which field, how many characters and when — and never the contents.
- Sending excerpts is opt-in, off by default, and capped at 80 characters even when you turn it on. People paste passwords into demos.
- The redaction is enforced on both ends: the client omits the field, and the server rebuilds every payload from scratch rather than trusting that the client did.
- The server log lives in memory and is gone on restart. No database quietly accumulates other people’s clipboards.
Can a website detect when you paste into a form?
Yes. Pasting fires a paste event that any page can listen for, and a listener on the document catches it for every field at once — including fields the page never wired up itself.
Can a site tell whether you used Ctrl+V, right-click or a drag?
Not directly — no browser API reports it. It can be inferred from timing: this demo watches for a paste shortcut or a drag immediately before the paste and attributes the event to whichever it saw, falling back to the context menu when it saw neither.
Can a website see what you pasted?
Yes. The pasted text is handed to the page along with the event. That is why this demo keeps clipboard contents in the browser by default and sends the server only the shape of the event: type, field, character count and time.
Can a website stop you pasting into a field?
Yes, by cancelling the paste event — which is what the Confirm email field here does. It is worth knowing it is usually hostile: blocking paste breaks password managers and makes long values far more error-prone, without stopping anyone determined.
Does detection work in fields the app did not write itself?
Yes. Because the listener sits on the document in the capture phase, it also sees pastes into third-party widgets and into components that stop the event from bubbling any further.
Why is a copy measured from the selection instead of the clipboard?
During copy and cut the event’s clipboard data is write-only: reading it back returns an empty string, so every copy would be logged as zero characters. The count has to come from the selection instead.
Try it
Not yet activeCopy, cut, paste or drag text into any field below. Every clipboard action on the page is detected, attributed, and logged.
Fields
A contenteditable region — pastes here are detected too.
Protected: pasting is refused while the switch below is on.
Detected and counted like any other field — but its contents are never kept, previewed or sent, whatever the switches below say.
Rendered by a component with no paste handler of its own — proof the detection is global, not wired per field.
Settings
Frequently asked questions
Can a website detect when you paste into a form?
Yes. Pasting fires a paste event that any page can listen for, and a listener on the document catches it for every field at once — including fields the page never wired up itself.
Can a site tell whether you used Ctrl+V, right-click or a drag?
Not directly — no browser API reports it. It can be inferred from timing: this demo watches for a paste shortcut or a drag immediately before the paste and attributes the event to whichever it saw, falling back to the context menu when it saw neither.
Can a website see what you pasted?
Yes. The pasted text is handed to the page along with the event. That is why this demo keeps clipboard contents in the browser by default and sends the server only the shape of the event: type, field, character count and time.
Can a website stop you pasting into a field?
Yes, by cancelling the paste event — which is what the Confirm email field here does. It is worth knowing it is usually hostile: blocking paste breaks password managers and makes long values far more error-prone, without stopping anyone determined.
Does detection work in fields the app did not write itself?
Yes. Because the listener sits on the document in the capture phase, it also sees pastes into third-party widgets and into components that stop the event from bubbling any further.
Why is a copy measured from the selection instead of the clipboard?
During copy and cut the event’s clipboard data is write-only: reading it back returns an empty string, so every copy would be logged as zero characters. The count has to come from the selection instead.