What Actually Comes With Pasted Text? We Inspected Six Common Sources

Copying text can carry far more than the words you can see. In our Chrome 153 captures on Windows, the same plain text could arrive with rich HTML, app-specific clipboard formats, an image file or nothing but plain text.

Contents

• What we captured — and what this test can’t tell us
• Results: six sources, very different paste data
• The same plain text can hide very different rich data
• Google Docs and ONLYOFFICE kept structure — with very different baggage
• Spreadsheet copy flattened structure and also exposed an image
• Invisible characters survived every source in plain text
• What this means when copy and paste behaves strangely

What we captured — and what this test can’t tell us

For this article, we built a small local research page we called Paste Probe and used it to inspect what Chrome exposed during a paste event on 21 September 2026. The probe intercepted the event, recorded the available clipboard formats, captured the plain-text (text/plain) and HTML (text/html) representations when present, listed files exposed through the event and flagged selected invisible or control characters. It never rendered the pasted HTML.

The current W3C Clipboard API Working Draft describes ClipboardEvent.clipboardData as a DataTransfer object that exposes a filtered set of clipboard data to a page during user-initiated copy, cut and paste operations. This article therefore covers what the browser made available to the paste event, not a forensic dump of everything the operating system may have stored on the clipboard.

MDN likewise documents clipboardData as the DataTransfer object a paste handler can use to obtain data for the paste operation. In practical terms, text/plain is the plain-text representation without HTML markup, while text/html can preserve links, formatting and document structure. A paste can expose files and other formats as well.

Our dataset contains eight unique captures across six sources:

• a direct webpage copy in Chrome;
• Google Docs;
• Gmail;
• ONLYOFFICE Document;
• ONLYOFFICE Spreadsheet;
• Windows Notepad.

All captures came from Chrome 153 on Windows within a few minutes of one another. The test content included formatted text, links with tracking parameters, a list, a table, inline code, a quote, smart punctuation, a non-breaking space, a zero-width space, a right-to-left override paired with its closing control, and a zero-width joiner inside the 👩‍💻 emoji sequence.

The dataset has limitations. We did not record exact version or build details for each source, and most sources have one meaningful capture rather than repeated standardized trials. The two ONLYOFFICE Document captures look different as raw HTML because an app-specific class value changed, but the meaningful markup is otherwise the same, so we treat them as one result. The two Spreadsheet captures differ in line-break and whitespace handling, but we did not record enough procedural detail to say what caused the difference.

This is an observational comparison, not a standardized cross-app benchmark.

Results: six sources, very different paste data

Source	Plain-text characters	HTML characters	Other data exposed	Notable observation
Direct webpage	447	5,102	—	HTML preserved headings, links, table structure and the test’s invisible Unicode.
Google Docs	450	12,127	2 Google-specific formats	Heading/list/table/links preserved; much formatting expressed through inline styles.
Gmail	447	5,583	—	Same plain text as the webpage; HTML rewrote the emoji as a Google-hosted image.
ONLYOFFICE Document	445	26,722	—	Rich structure preserved inside a much larger HTML representation with app-specific classes and styling.
ONLYOFFICE Spreadsheet	443–449	4,346–4,361	image/png file	Rich structure largely flattened; two captures differed in whitespace/line-break handling.
Notepad	447	0	—	Only plain text exposed; the invisible Unicode still survived.

The character counts above describe the captured strings, not bytes, memory use or performance cost. A large HTML representation is not automatically bad or unsafe; it simply means the source supplied more markup to the browser during that paste.

The same plain text can hide very different rich data

The clearest comparison in our dataset is the direct webpage, Gmail and Notepad.

Their plain-text values were character-for-character identical. If you looked only at the plain-text representation, you would not know which of the three sources the content came from.

Their richer representations were very different.

The direct webpage copy exposed both text/plain and text/html. Its HTML preserved the original heading, paragraphs, list, table, inline code, blockquote, emphasis and both links, including their tracking parameters.

Gmail exposed the same two broad formats, but it rewrote part of the HTML. Most of the original structure remained recognizable, while the 👩‍💻 sequence became an img element pointing to a Google-hosted emoji image. The actual emoji was still present in the element’s alt and data-emoji attributes, and the plain-text representation still contained 👩‍💻 normally.

Notepad exposed only text/plain. The words survived, including the deliberately planted invisible characters, but there was no HTML representation for the browser to inspect.

The comparison explains a common copy-and-paste frustration: “the text” can look unchanged while a rich editor receives additional structure that a plain-text editor never sees. If a destination uses the HTML representation, it can preserve links, lists and formatting that are absent from plain text.

Google Docs and ONLYOFFICE kept structure — with very different baggage

Google Docs exposed 450 characters of plain text and 12,127 characters of HTML in our capture. It also exposed two additional Google-specific clipboard format labels:

application/x-vnd.google-docs-document-slice-clip+wrapped
application/x-vnd.google-docs-internal-clip-id

Paste Probe saw those labels but did not read the associated data, so we cannot use them to make claims about what Google stores inside them.

The HTML itself retained the heading, list, table and both links. Some formatting that the original webpage represented with HTML elements was expressed through inline CSS styling instead. That matters for cleaning tools: removing every style attribute before interpreting it can also erase formatting that the source app encoded only in CSS.

ONLYOFFICE Document went much further in size. Its representative capture contained 445 characters of text/plain and 26,722 characters of text/html.

The markup still carried useful structure: the heading, list, table, links and formatting were present. Much of the extra size came from app-specific classes and styling. Our two Document captures differed in an opaque app-specific class value, but the meaningful HTML was otherwise the same.

That is a useful caution when comparing clipboard markup. Two captures can differ as raw strings without representing a meaningful difference in the content a user would care about.

Spreadsheet copy flattened structure and also exposed an image

The ONLYOFFICE Spreadsheet result was different from the document editors.

Both Spreadsheet captures exposed text/plain, text/html and a file item with MIME type image/png. The PNG image file was around 9 KB in each capture. MDN documents that files can be available from ClipboardEvent.clipboardData during a paste event, so a file appearing alongside text and HTML fits how browser paste data can be structured.

The HTML representation, however, had flattened most of the original rich structure into essentially one spreadsheet cell. The original hyperlinks no longer survived as anchor elements. The source content was still recognizable as text, but it was no longer represented like the original webpage or document.

The two Spreadsheet captures were not identical. One produced 443 characters of plain text and 4,346 characters of HTML; the other produced 449 and 4,361. Their line-break and whitespace handling differed, and one retained the test content’s non-breaking space where the other did not.

We do not know why. Because we did not log the exact selection or editing state for those two captures, we cannot attribute the difference to a specific Spreadsheet behavior. The result shows variability in our captures, not a general rule about ONLYOFFICE Spreadsheet.

Invisible characters survived every source in plain text

The test content deliberately contained several characters that are easy to miss visually:

• U+200B ZERO WIDTH SPACE between A and B;
• U+202E RIGHT-TO-LEFT OVERRIDE followed later by U+202C POP DIRECTIONAL FORMATTING;
• U+200D ZERO WIDTH JOINER inside 👩‍💻;
• a non-breaking space.

Every unique source capture retained the zero-width space, the directional-control pair and the emoji’s zero-width joiner in text/plain. The non-breaking space was less consistent: it appeared in some ONLYOFFICE captures but not in all sources.

Invisible Unicode is not inherently suspicious. The zero-width joiner in 👩‍💻 is doing legitimate work: Unicode uses U+200D in emoji ZWJ sequences to request a combined glyph. Directional overrides also have legitimate text-direction uses, although Unicode advises avoiding them where possible because of security concerns. The practical point is simpler: plain text is not always visually simple. Characters you cannot easily see can survive copy and paste even after all rich HTML has disappeared.

So “paste as plain text” and “remove all hidden characters” are different operations. Plain text discards rich structure. It does not guarantee that every Unicode control or zero-width character has vanished.

What this means when copy and paste behaves strangely

When a paste behaves strangely, these observations suggest a few useful checks:

If formatting unexpectedly survives a paste, the destination may be using a rich representation such as text/html rather than only text/plain.

If formatting disappears, the source may have supplied only plain text, the destination may have chosen the plain representation, or an intermediate app may already have flattened the content.

If a document cleaner removes every style attribute without understanding what the source app encoded there, it can erase meaningful formatting along with the junk.

If text still behaves oddly after “paste without formatting,” invisible Unicode can be worth checking because some controls survive perfectly well in text/plain.

If copied content changes after passing through an email composer, document editor or spreadsheet, the transformation may have happened before the destination app ever received it.

Paste X-Ray is designed for exactly that situation. The tool inspects the browser-exposed representations, shows links and invisible characters, and can produce cleaned rich text without treating plain text as the only definition of clean.

Across these six sources, copy and paste behaved less like moving one string and more like moving a small bundle of representations. What you see on screen is only one layer.

Sources and verification

• W3C — Clipboard API and events
• MDN — ClipboardEvent: clipboardData property
• MDN — DataTransfer: types property
• MDN — DataTransfer: files property
• Unicode — Emoji ZWJ sequences
• Unicode — Bidirectional Algorithm
• Elegant Matter — first-party Paste Probe captures collected 21 Sep 2026 in Chrome 153 on Windows; eight unique captures across six sources, summarized in the results above.