Ctrl+V in Word Loses Colors and Font Sizes? The Data Is Fine — a Default Setting Changed
2026-10-27
Tags: Windows · Clipboard · Guide
A few months ago we released RDP Clipboard Anchor. It is a clipboard history tool specialized for remote desktop scenarios: anything copied inside an RDP session is cached and anchored locally, so it survives disconnects and can be dragged out at any time. Its history list is designed around that bridging scenario.
In May this year, a user filed a feature request on our feedback repo: they wanted the clipboard history to support categories, with frequently used items saved as favorites. Categories and favorites are general-purpose clipboard management needs, beyond the scope of an RDP bridge tool. The request really pointed at another product: a clipboard manager for everyday local use. That is the direction we started ClipLab in.
Then, during testing, we ran into the problem this post is about.
The Symptom That Made No Sense
Copy a piece of text with colors, font sizes, bold and italic from Word, let the clipboard get overwritten by something else in between, then find that entry in ClipLab's history and paste it back into Word. The colors and font sizes are gone; the bold and italic are still there.
The first suspect was ourselves: part of the data got lost when storing, or when writing back. A clipboard manager's whole job is to store content as-is and hand it back as-is — failing that is a bug.
So we audited the data along the entire chain first.
First, Confirm the Data Is Still There
The Windows clipboard allows the same content to exist in multiple formats at once. When Word copies a piece of text, it puts a dozen or so formats on the clipboard: Rich Text Format, HTML Format, plain text, plus a pile of OLE-native formats (Embed Source, Native, and friends).
We wrote a probe script that uses the raw Win32 API (OpenClipboard / GetClipboardData) to grab the raw bytes of every format one by one, hash them, and archive them. Then we ran a three-step comparison.
Step one: after the copy, pull the stored bytes out of the tool's database and compare them with the original bytes on the clipboard. HTML Format matched byte for byte.
Step two: clear the clipboard, have the tool write the entry back, and probe again. The hashes matched — still byte-for-byte identical.
Step three: bypass the tool entirely, have the probe put Word's original bytes back onto the clipboard, and paste into Word.
Step three still lost the colors. Not a single byte was missing, and Word still pasted the same way.
Word's Four Paste Options
The data was fine, so next we looked at Word's behavior. Right-click pasting shows Word's four paste options, and trying them one by one makes the pattern clear:
| Paste option | Color / size | Bold / italic |
|---|---|---|
| Keep Source Formatting | ✅ | ✅ |
| Use Destination Theme | ✅ | ✅ |
| Merge Formatting | ❌ | ✅ |
| Keep Text Only | ❌ | ❌ |
The data is complete, and Word is fully capable of pasting it as-is — all you have to do is explicitly pick "Keep Source Formatting". But on a plain Ctrl+V, Word decides on its own and goes with "Merge Formatting": bold and italic survive; font, color, size, and family are dropped. That matches our symptom exactly.
So what does Word use to decide which one is the default? We ran several rounds of elimination. First, the data angle: we captured all 16 formats Word puts on the clipboard (including the OLE-native ones like Embed Source and Native), byte for byte, and replayed them unchanged — colors still lost. RTF only, HTML only — same result. Then, the source angle: the clipboard records an "owner", and Windows does not verify that the window handle passed to OpenClipboard belongs to whoever calls it, so we passed Word's own main window handle, replayed all the formats, and used GetClipboardOwner to confirm the owner was now Word's own window. Plain Ctrl+V — still Merge Formatting.
There was a detour along the way: we first suspected the RTF was missing its conventional NUL terminator, added it, pasted, still lost. We wanted WordPad as a control, only to find Win11 has removed WordPad; instead we saved the RTF to a file and opened it directly in Word — the formatting was all there.
By this point the direction was clear: we had exhausted everything testable about data and source, and Word still went Merge Formatting every time. This is not a data problem; it is Word's standing policy for "content from other programs". As for exactly how it distinguishes its own content from foreign content, we did not dig further — it did not affect the conclusion.
The Real Switch Is a Setting
That policy lives in a user-visible setting: File → Options → Advanced → Cut, copy and paste → "Pasting from other programs".
In May 2024, the Word team announced on the Microsoft 365 blog that Word 2405 changed this default: "Pasting from other programs" went from "Keep Source Formatting" to "Merge Formatting". In other words, nothing was misconfigured — this is Word as installed: anything classified as "from other programs", which includes everything a third-party tool writes back, gets downgraded by Ctrl+V across the board.
What to Do
- Change the Word setting (recommended): File → Options → Advanced → Cut, copy and paste, set "Pasting from other programs" back to "Keep Source Formatting". One change, permanent. This is the user's own preference; a tool should not decide it on their behalf.
- Right-click paste: if you leave the setting alone, explicitly pick "Keep Source Formatting" from the right-click menu — one extra click each time.
- No tool-side fix, and there should not be one: every clipboard manager in its default configuration triggers the same downgrade. The data is already byte-for-byte faithful; the only step beyond that is impersonating Word itself. That is not paste enhancement — it is an impersonation attack.