Tiptap color: change selected text and keep the reader output legible

An original visitor notice distinguishes a revised opening time from the surrounding directions. The phrase still says “Revised opening time: 10 a.m.” in plain words. Color can help someone scanning the notice, but it must not be the only indication that the time changed.

Add foreground color support

In an existing Tiptap 3 application with compatible packages:

import { TextStyle, Color }
  from '@tiptap/extension-text-style';

const noticeColorExtensions = [TextStyle, Color];

Include those entries in the editor's existing extension list alongside its document schema. If the application already uses TextStyleKit, inspect its configuration before registering the same support again; the official Color documentation says that kit includes Color.

Foreground color is different from a Tiptap highlight, which marks a passage with a mark element and can supply a background. Decide which visible effect the authoring control promises. A control labeled “Text color” should not unexpectedly apply a yellow background.

Apply and remove color on the intended selection

This example limits a custom text-color control to two illustrative notice colors:

const noticeColors = new Set(['#173f69', '#842d36']);

function applyNoticeColor(color) {
  if (!noticeColors.has(color)) return false;
  return editor.chain().focus().setColor(color).run();
}

function resetNoticeColor() {
  return editor.chain().focus().unsetColor().run();
}

Here editor is the initialized Tiptap editor. Select “Revised opening time: 10 a.m.” before invoking the handler. Restoring editor focus lets a toolbar button operate on the editor selection. With only a caret, the command can affect subsequent typing instead of recoloring a phrase, so check both interactions in your actual toolbar.

Reset removes the selected text's explicit color. It does not insert a black color value. The resulting appearance depends on the inherited foreground and background styles in the editor and reader. That makes reset especially useful when the reader has its own theme.

The two-color set controls this handler only. It does not reject other colors arriving through pasted content, imported JSON, or another API. If the application needs an enforced palette, apply that policy at the relevant content boundaries as well.

Inspect the exported phrase before saving

Read editor.getHTML() after applying the color. The revised-time phrase should have a color style, while the other directions should retain their intended formatting. Inspect structured JSON too if that is the representation the application stores. Do not require one exact hexadecimal spelling in serialized HTML: browsers may represent the same color using an equivalent CSS form.

Reset the phrase and inspect the export again. Its foreground color should be removed without clearing unrelated formatting such as bold or a link. Save and reopen through the application's normal document service; an in-memory export alone does not confirm storage or the final reader renderer.

If the exported color survives but the reader looks different, inspect the reader's stylesheet and HTML-cleanup path. Changing the editor container's global color would not repair a missing inline style in the saved document. The font-family guide covers another TextStyle attribute with its separate font-delivery requirements.

Check the actual foreground and background together

Read the revised time against the background where the notice will appear. WCAG's minimum contrast criterion calls for at least 4.5:1 for ordinary text, or 3:1 for qualifying large text. Evaluate the final rendered colors rather than assuming a named palette is accessible. W3C contrast explanation

Also read the notice without relying on color: its wording must identify the revision. At a narrow width, confirm that the time and its “Revised” label remain readable together. Finish by resetting a test phrase and verifying that the default reader text remains legible too.