ByteScope

Clipboard Inspector

Clipboard viewer — every MIME type, raw HTML, hex dump. Local, on a click, then gone.

Nothing is uploaded or logged. The snapshot lives in this tab and is gone when you leave.

Async Clipboard API

Nothing has been read yet. Click Read clipboard — this page never reads on its own.

navigator.clipboard.read
checking
navigator.clipboard.readText
checking
clipboard-read permission
checking

Typical browser support

Typical picture only. Trust the live rows above. Cells marked ? were not verified on a real device here.

APIChromeEdgeFirefoxSafari
navigator.clipboard.readChrome and Edge: yes, after a gesture. Safari: text and images. Firefox: untested here.?
navigator.clipboard.readTextThe fallback when read() is missing. Text only — not "clipboard is text only".
paste event clipboardDataAvailable in current desktop browsers. Not the same pipe as read().
permissions.query clipboard-readOften throws. A throw is unknown on this page, never denied. Firefox and Safari untested here.??

This browser, right now: checking

About this tool

This page answers a question developers actually type: what is in my clipboard? Not a guess. After you click, it asks navigator.clipboard.read() for every MIME flavour the browser will hand over — text/plain, text/html, text/uri-list, image/png, image/svg+xml, and the vendor ones like web application/x-vnd…. Each row is a type, a size in bytes, and a viewer that fits. Nothing is uploaded, nothing is logged, and leaving the page drops it.

All the MIME types, not a textarea

A paste into a form only keeps what that form asked for. The clipboard itself often holds several representations of the same copy at once. This page lists every one. Hex uses the same language as the hex editor: offset, 16 bytes per row, ASCII on the side. Images show type, bytes, and pixel size when createImageBitmap can read them. A flavour whose getType() rejects is marked unavailable; the rest of the table still renders.

The HTML cell is the point

Paste from Word or Notion and the hidden passenger is text/html — inline styles, mso- junk, converted lists. This page shows that source as text, escaped so it cannot become DOM. There is no dangerouslySetInnerHTML, no eval, no injection. If you only wanted the words, text/plain is the other row; the HTML row is why the paste looked wrong.

Denied is not empty, and unknown is not denied

clipboard.read() must run from a click or a paste. This page never reads on load. NotAllowedError means the browser refused or still wants a gesture — not that the clipboard is empty. An empty result is a different state. navigator.permissions.query({ name: "clipboard-read" }) often throws; a throw is shown as unknown, never as denied. Some browsers only implement readText(). That is reported as "this browser only returns plain text" — not "the clipboard only had plain text".

Two paths, because they disagree

The Async Clipboard API and a paste event's clipboardData.items are not the same pipe. Chrome may sanitise HTML on read() and leave a web text/html unsanitized twin; a paste event can still see types read() hid, or the other way around. The paste well on this page is a comparison, not a second toy. Both results stay in this tab and vanish when you leave.

Frequently asked questions

Do you upload or store what is on my clipboard?

No. The bytes never leave this tab. There is no server round-trip, no analytics payload with the contents, no log. Closing or navigating away drops the snapshot. The privacy line on the page is the whole policy.

Why do I have to click? Why not read automatically?

The Async Clipboard API requires a user gesture, and this page would not auto-read even if it did not. Clipboard contents are secrets: passwords, tokens, unsent mail. A click is the consent. The paste well is the other consent — you pasted.

I clicked and it said permission denied. Is my clipboard empty?

No. NotAllowedError is a refusal (or a missing gesture), not an empty clipboard. Empty is a separate result: read() came back with no items, or the browser threw NotFoundError. This page will not fold those together.

The paste well and the Read button show different types. Which is real?

Both, for their own API. navigator.clipboard.read() and event.clipboardData are different paths, and browsers sanitise them differently — especially text/html. The mismatch is the information. Neither path is rewritten into the other.

This browser only shows text/plain. Is that all that was copied?

Not necessarily. Some browsers only expose clipboard.readText(), which returns Unicode text and no other MIME types. This page says so in those words. It will not claim the clipboard "only contained plain text" when the other flavours were never offered.

Is it safe to look at HTML from the clipboard here?

The HTML is escaped and shown as text. It is not parsed into elements, not run as script, and not assigned with innerHTML. Treat it as untrusted input anyway — that is why it is a viewer, not a preview of the rendered page.