DeskTest.net
GitHub

Clipboard Test Guide

A reference for the DeskTest.net Clipboard Test. This tool answers a narrow, practical question: do copy, paste, and image-paste actually work in this browser? The clipboard is one of the first things to break in RDP and Citrix sessions and in locked-down managed browsers - the bridge between the remote session and the local machine gets disabled, or a policy blocks the Clipboard API, and users quietly lose the ability to copy and paste between the session and their desktop.

Open the Clipboard Test →

What does the Clipboard Test check?

Two interactive steps, plus an optional scripted-read probe. No hardware, no plugin, no uploads.

  1. Copy to clipboard works. The moment you press Start, the tool writes a short sample string to the clipboard with navigator.clipboard.writeText. This has to happen inside the button click, because browsers only allow a script to write to the clipboard during a real user gesture. If the async Clipboard API is blocked or unavailable, the tool falls back to the legacy document.execCommand('copy') and reports which path worked.
  2. Paste captures text and images. You focus a paste box and press Ctrl+V (Cmd+V on a Mac). A paste event listener reads event.clipboardData: any plain text, and any image item (for example a pasted screenshot). Paste the sample the tool just copied to prove a clean round-trip, or copy any image and paste it to test image-paste.
  3. Scripted read (optional). On Chromium browsers a "Read clipboard with API" button calls navigator.clipboard.readText. This is permission-gated - the browser may prompt, or a policy may block it outright. It is separate from manual paste: manual Ctrl+V can work perfectly while scripted read is denied.

There is also a "Paste did nothing" button. If Ctrl+V delivers nothing at all - the tell-tale sign of a broken inbound clipboard bridge - press it so the tool can still record the failure and produce a verdict and report.

When should I run this?

How to run it

  1. Press Start Clipboard Test. Step 1 (copy) runs immediately and reports pass, warn (legacy fallback used), or fail.
  2. Click into the paste box and press Ctrl+V. The sample string you just copied should appear, and the captured text is echoed back below the box.
  3. To test image-paste, copy any image - a screenshot, or right-click an image and Copy - then paste into the same box. The tool reports the image type and size only; it never displays or uploads the pixels.
  4. Optionally press Read clipboard with API (Chromium) to test scripted read. Allow the permission prompt if it appears.
  5. Read the verdict, then use Copy Diagnostic Report or Send to your IT to attach the result to a ticket.
Nothing pasted leaves your browser. Captured text is shown back as inert text, an image is summarized as type and size only, and there are no network requests. See Privacy below.

Reading the verdict

Each step gets a status badge - Pending, Running, Pass, Warn, or Fail. The verdict panel at the top gives a one-line title, a likely cause, and a recommended next step. There are five outcomes:

VerdictMeaning
Clipboard works (pass)Copy succeeded and paste delivered text (and an image, if you tested one). The clipboard bridge is intact in both directions.
Scripted read is blocked (warn)Copy and manual paste both work; only navigator.clipboard.readText is blocked by browser policy. Usually intentional and harmless for normal copy/paste.
Clipboard bridge is broken (fail)Copy failed and nothing could be pasted back. The classic RDP/Citrix clipboard-redirection failure, or a policy that blocks the Clipboard API outright.
One-way: copy works, paste does not (fail)The sample copied, but pasting delivered nothing. The inbound half of the bridge (local machine into the session) is off.
One-way: paste works, copy does not (fail)Paste delivered content, but writing to the clipboard failed - an insecure context, a denied clipboard-write permission, or outbound redirection turned off.

Fixing a broken clipboard bridge

RDP (Remote Desktop)

In the Remote Desktop Connection client, open Show Options - Local Resources and make sure Clipboard is checked before connecting. On the host side, the Group Policy Do not allow clipboard redirection (under Remote Desktop Services - Remote Desktop Session Host - Device and Resource Redirection) must be Disabled or Not Configured. If image-paste specifically fails, confirm the session is not restricting redirection to text only.

Citrix

Clipboard behavior is governed by the Client clipboard redirection policy and the more granular Clipboard selection update and Client clipboard write/read allowed formats policies. If plain text pastes but images do not, the allowed-formats policy is usually limiting the clipboard to text. Have the Citrix admin allow the image formats you need.

Managed / locked-down browsers

Chrome and Edge expose clipboard as a site permission and via policy: DefaultClipboardSetting, plus the site-scoped clipboard permission. The page must also be a secure context (https) for the async Clipboard API to exist at all - over plain http, navigator.clipboard is undefined and only the legacy fallback remains. For iframes, the embedding page must grant clipboard-read / clipboard-write via the allow attribute and Permissions-Policy.

Kiosk shells and in-app webviews

Some kiosk shells and embedded webviews strip clipboard access entirely. If the test fails there but passes in the system browser, open the app in the system browser instead, or ask whoever maintains the kiosk image to allow clipboard access for the app origin.

Privacy: what happens to what I paste

Everything runs in JavaScript on the page; there are no network requests. When you paste text, the tool reads it from the paste event and echoes it back using textContent - never innerHTML - so it is displayed as literal characters and can never execute as markup. When you paste an image, the tool reads only its MIME type and byte size from the clipboard item; it does not render the image, encode it, or send it anywhere. Nothing you paste is stored, logged, or transmitted. The diagnostic report contains the pass/fail results and, for any pasted image, its type and size - never the content. View source to verify all of this.

Behind the scenes

Copy timing. Writing to the clipboard requires a live user activation. The tool therefore fires writeText first, synchronously, inside the Start click handler - before any await - and only then runs the rest of the flow. Starting the write after an await would break the gesture chain and the browser would reject it, producing a false failure.

Async API versus legacy fallback. The modern path is navigator.clipboard.writeText, which exists only in a secure context. If it is missing or rejects, the tool tries document.execCommand('copy') against a hidden textarea and reports a warn if only the legacy path worked. A warn means copy still functions but through an older mechanism that a few apps do not use.

Paste capture. The paste box is a plain textarea with a paste event listener. On paste, the tool reads event.clipboardData.getData('text/plain') for text and scans clipboardData.items (and files) for the first item whose type begins with image/, taking that item's type and size via getAsFile(). Text is compared against the sample copied in Step 1 to confirm a clean round-trip. The listener is attached to the injected textarea, so resetting the test discards it along with the node.

Scripted read. The optional read button calls navigator.clipboard.readText(), which is permission-gated behind clipboard-read and is Chromium-oriented. A rejection with NotAllowedError is reported honestly as "blocked by browser policy or a denied permission," and never counted as a hard failure of copy and paste.

Elsewhere on the web: