Word crashes copying large web tables: fix 0x8004260A

Cause 1: The clipboard can't handle the HTML bloat

What's actually happening here is that Word's internal HTML parser gets overwhelmed when you copy a table from a web browser that's more than about 100 rows or 10 columns. Browsers like Chrome, Edge, and Firefox generate a ton of inline styles for every cell — font sizes, margins, borders, background colors. Word receives this monster HTML object through the clipboard and tries to convert it to a native Word table. The COM subsystem (Component Object Model) that handles that conversion hits a timeout or memory limit, and you get 0x8004260A — which is a CLIPBRD_E_CANT_OPEN error wrapped in a Word crash.

I've seen this most commonly when someone copies a table from a Confluence page or a complex HTML report generated by a BI tool like Tableau. The fix doesn't require installing anything.

Fix: Paste as plain text first, then convert to table

1. Copy the table in your browser normally (Ctrl+C).
2. In Word, press Ctrl+Alt+V (Paste Special).
3. Choose Unformatted Text from the list.
4. Word will paste the data as tab-delimited text. Now select that text.
5. Go to Insert > Table > Convert Text to Table.
6. Check that the column count matches your original table. Word usually auto-detects it from the tabs.
7. Click OK. You'll get a clean table without any of the junk CSS that caused the crash.

The reason step 5 works is that Word's text-to-table parser is far more efficient than its HTML table importer. It doesn't try to render formatting per cell — it just splits on tabs and newlines. This bypasses the COM timeout entirely.

Cause 2: Clipboard history or third-party clipboard managers

Windows 10 and 11 have a built-in clipboard history feature (Win+V). It works by keeping a cache of copied items. When you copy a huge table, the clipboard history manager tries to store it, and then Word also tries to read it. These two competing accesses to the clipboard can cause a lock conflict, raising error 0x8004260A.

Third-party tools like Ditto Clipboard Manager or CopyQ can also interfere. They hook into the same system API as Word.

Fix: Disable clipboard history and restart

1. Press Win+I to open Settings.
2. Go to System > Clipboard.
3. Toggle Clipboard history off.
4. If you use a third-party clipboard tool, exit it completely (right-click its tray icon and choose Exit).
5. Restart Word and try pasting again — but this time use Paste Special as described above.

If you need clipboard history for other tasks, turn it back on after the paste. The crash only happens during the paste operation, not during copy.

Cause 3: A corrupt Word add-in (usually a PDF converter or reference manager)

Add-ins like Adobe Acrobat PDFMaker, EndNote, or Mendeley hook into Word's paste event to process clipboard data. A bug in one of these add-ins can cause the COM handler to fail when it receives a large HTML payload. This is less common than the first two causes, but I've seen it twice in the last year — both times with an outdated PDFMaker add-in from Adobe Acrobat DC v2023.

Fix: Start Word in safe mode to confirm, then disable the culprit

1. Hold the Ctrl key and double-click the Word shortcut. Keep holding Ctrl until a dialog asks if you want to start in Safe Mode. Click Yes.
2. In Safe Mode, test the paste. If it works without crashing, an add-in is the cause.
3. Exit Safe Mode and restart Word normally.
4. Go to File > Options > Add-ins.
5. At the bottom, next to Manage, select COM Add-ins and click Go.
6. Uncheck all add-ins. Then close Word and reopen.
7. Enable add-ins one at a time, testing the paste after each. The one that triggers the crash is your culprit.
8. Either update that add-in to the latest version or keep it disabled when you need to paste big tables.

Don't bother with the Office Quick Repair tool here — it won't fix a third-party add-in conflict. That's a waste of 20 minutes.

Quick-reference summary table