Suppose a service-note editor receives short instructions copied from a legacy portal. The portal uses <b> for a compact category label, but the new note format wants those labels italicized. The words must survive. This is a conversion rule for one source convention, not a request to strip all formatting from every paste.
Override one element's formatting
In an application with Quill 2 loaded and an initialized quill instance, register the matcher before the user pastes:
const Delta = Quill.import('delta');
quill.clipboard.addMatcher('B', (node, delta) => {
return delta.compose(
new Delta().retain(delta.length(), {
bold: null,
italic: true
})
);
});
The callback retains the interpreted content and changes its attributes. Setting bold to null removes that attribute from the affected Delta range; italic: true applies the replacement. Simply returning a newly inserted label would discard the element's actual words and any supported content inside it.
For this fictional source fragment:
<p><b>Before dispatch:</b> inspect the foam insert.</p>
the intended result is "Before dispatch:" in italic text, followed by the unchanged inspection instruction. That is an acceptance expectation for the application, not a claim that a live editor ran here. Inspect the resulting Delta as well as the visible paragraph before accepting the conversion rule.
This policy targets B elements. It does not automatically apply to STRONG, and it does not recognize every way another application might visually make text bold. Add broader rules only after inspecting the markup your actual source produces.
Understand when each matcher runs
Quill builds the imported Delta from the children toward their containing elements. Node-type matchers run before selector matchers; within those groups, registration order matters. A later matcher can change the interpretation produced earlier.
That explains a common debugging trap: a matcher can run successfully while a later rule changes the same formatting again. Temporarily inspect the Delta entering and leaving the specific callback in a development fixture. Check the final document too, rather than treating a console message as proof of the final formatting.
You can also supply a matchers array in Clipboard configuration. Those entries follow Quill's default matchers. Avoid registering the same rule both there and in component code that runs repeatedly when the editor rerenders.
Keep conversion separate from insertion
Quill 2's conversion API accepts an object containing HTML and text. Older snippets that pass only an HTML string do not express the current signature. The Quill 2 migration notes describe this change.
For a developer-controlled test fragment:
const converted = quill.clipboard.convert({
html: '<p><b>Before dispatch:</b> inspect the foam insert.</p>',
text: 'Before dispatch: inspect the foam insert.'
});
console.log(converted.ops);
Conversion produces data; this call does not insert it. Choose the application's insertion or replacement route separately. The Quill HTML loading guide covers that distinction for whole documents.
A formatting matcher is not an HTML sanitizer. Keep the application's approved handling of untrusted HTML and supported formats. The literal fixture above establishes a narrow conversion expectation and says nothing about arbitrary portal content being safe.
Finish by pasting the real portal fragment into a development note, checking the preserved instruction, and undoing the paste. Then reopen the saved note and inspect the label again. If formatting changes only after reopening, trace the stored Delta and reader renderer rather than adding another paste matcher.