Block Editor: Pasted base64 (binary) images are silently dropped

Problem Statement

Pasting a binary / base64 image into the Block Editor (libs/new-block-editor) silently does nothing. Pasting an image referenced by URL works fine. There is no error, no warning, and no placeholder — the paste simply produces no image, so the author cannot tell whether the editor is broken or the clipboard was empty.

This happens whenever the clipboard holds a data:image/...;base64,... source rather than an http(s) URL — which is the normal result of copying an image out of Google Docs, Figma, Excel, a screenshot tool, or many web pages.

Root cause (verified)

core-web/libs/new-block-editor/src/lib/editor/extensions/nodes/image.extension.ts:132

parseHTML() {
    return [
        { tag: 'figure img[src]' },
        // Fallback: bare <img> tags from other sources / old content
        { tag: this.options.allowBase64 ? 'img[src]' : 'img[src]:not([src^="data:"])' }
    ];
}

allowBase64 is never configured, and @tiptap/extension-image defaults it to false. The :not([src^="data:"]) branch is therefore active, so ProseMirror's paste parser finds no matching rule for a data-URI <img> and discards the node with no feedback.

allowBase64 is a first-class option of the installed @tiptap/extension-image@3.22.2 — no backend work is required:

/**
 * Controls if base64 images are allowed. Enable this if you want to allow
 * base64 image urls in the `src` attribute.
 * @default false
 */
allowBase64: boolean;

Reference: https://tiptap.dev/docs/editor/extensions/nodes/image#allowbase64

Known trade-off of this approach: enabling allowBase64 stores the full data URI inside the Block Editor field JSON rather than uploading the image as a dotCMS asset. Large pasted images will inflate the contentlet payload and the index document. Accepted deliberately to keep this a front-end-only configuration change; a follow-up ticket can add auto-upload of pasted binaries if payload size becomes a problem.

Browser & OS: not browser-specific — reproduced by the parse rule, independent of browser.

Steps to Reproduce

1. Open any image in Google Docs, Figma, or a screenshot tool and copy it to the clipboard (this yields a base64 data URI, not a URL).
2. Log in to the dotCMS admin and edit a contentlet that has a Block Editor field.
3. Place the cursor in the Block Editor body.
4. Paste (⌘V / Ctrl+V).
5. Expected: the image is inserted into the document.
6. Actual: nothing is inserted. No image, no error, no warning message.
7. For contrast, copy an image from a web page via "Copy image address" and paste the resulting URL — that path works, confirming the failure is specific to base64 sources.

Acceptance Criteria

Happy path

• Pasting a data:image/png;base64,… image into the Block Editor inserts a visible image at the cursor
• Pasting a data:image/jpeg;base64,… image inserts a visible image at the cursor
• The inserted node is a dotImage node whose src holds the data URI
• Saving the contentlet and reopening it renders the pasted image unchanged

Rendering parity

• A pasted base64 image renders through the VTL renderer (dotImage.vtl) with the data URI intact in src
• A pasted base64 image renders through the React, Vue, and both Angular SDK block renderers with the data URI intact
• TiptapHtml server-side HTML output preserves the data URI in src

No regressions

• Pasting an http(s) image URL still inserts an image, exactly as it does today
• Images inserted from the dotCMS asset picker still carry their data attribute and language_id query param
• Existing stored content renders unchanged

Editor interaction

• A pasted base64 image can be selected and its toolbar (align, wrap, edit properties) operates on it
• The image properties dialog opens on a pasted base64 image and shows the data URI in the Image URL field without truncating the stored value

Sad path

• Pasting clipboard content whose src is a malformed data URI inserts no node and logs no uncaught error
• Pasting a non-image data URI (e.g. data:text/html;base64,…) does not insert an image node

Tests

• Unit specs in libs/new-block-editor/ cover: base64 paste inserts a node, URL paste still works, and malformed data URIs are rejected

dotCMS Version

Latest from main (verified at commit 66bb905280).

Severity

Medium - Some functionality impacted

Links

• NA — no Freshdesk ticket. Found during Block Editor development.

Start in core-web/libs/new-block-editor/src/lib/editor/extensions/nodes/image.extension.ts at parseHTML and inspect the allowBase64 option from @tiptap/extension-image. Add or update unit specs in libs/new-block-editor/ for base64, URL, and malformed data-URI pastes. Done means valid PNG and JPEG data URIs insert as dotImage nodes, existing URL and asset behavior remains intact, and the listed renderers preserve the URI.