Safely render rich text revisions diff bounded algorithm DOMPurify inline style allowlist Tiptap table cell attributes

TL;DR: never diff or render stored HTML. Diff the two Tiptap JSON documents instead, at top-level block level, with hard caps on block count, total text, and per-pair diff time, and fall back to a whole-block insert or delete when a pair is too large. Render blocks with generateHTML from the @tiptap/html package using the exact extension list the editor uses, so table, tableRow, tableHeader and tableCell nodes keep their colspan, rowspan and colwidth attributes. Insert the diff markers, then sanitize the finished HTML as the very last step with DOMPurify: an explicit tag and attribute allowlist that includes ins, del and the table tags, plus a hook that rebuilds every style attribute from an allowlist of CSS properties and safe values, because allowing the style attribute on its own filters nothing inside it.

Verbatim problem (the search that created the source thread):

Safely render rich text revisions diff bounded algorithm DOMPurify inline style allowlist Tiptap table cell attributes

Symptoms: a revision history view either hangs or spikes CPU on a large document, renders merged or resized table cells as a plain grid (colspan, rowspan and column widths lost), drops text alignment and text color that Tiptap stored as inline style, or, worst case, renders stored markup an attacker can break out of.

Steps

1. Take Tiptap JSON as the input, never stored HTML

Both revisions must be ProseMirror JSON documents (the shape editor.getJSON returns), validated against the same schema the editor uses. If a revision only exists as HTML, parse it back into JSON with the editor schema once, at write time, and store the JSON.

Expected output: two JSON documents with a content array of top-level blocks. Success check: a document containing a merged table cell has a tableCell node whose attrs object carries colspan, rowspan and colwidth entries; if those attrs are already missing here, no later step can restore them.

2. Bound the work before diffing anything

Set explicit caps and enforce them by truncation plus a truncated flag, not by hoping the input is small. Suggested starting caps: 500 top-level blocks per document, 50000 total text characters per document, and 4000 text characters for one word-level pair diff. Slice block arrays to the cap, and count text with a recursive walk that stops adding once the cap is reached.

var MAX_BLOCKS = 500
var MAX_PAIR_CHARS = 4000

function topBlocks(doc) {
  return (doc.content || []).slice(0, MAX_BLOCKS)
}

function blockText(node, acc) {
  acc = acc || { chars: 0 }
  if (node.type === 'text') acc.chars += (node.text || '').length
  ;(node.content || []).forEach(function (child) { blockText(child, acc) })
  return acc.chars
}

Expected output: an oversized document returns a diff of its first capped blocks plus truncated set to true, in bounded time. Success check: a synthetic 5000-block document finishes and reports truncated, instead of running an all-pairs comparison.

3. Diff at block level first, using a hash map, not an all-pairs scan

Key each top-level block by its serialized JSON. Count keys for the old and new arrays in two Map objects. Blocks whose key appears in both keep one copy rendered normally; blocks only in the old document are deletions; blocks only in the new document are insertions. This pass is linear in the number of blocks, which is what makes the overall algorithm bounded even before the per-pair time limit in step 4.

function keyOf(block) { return JSON.stringify(block) }

function countKeys(blocks) {
  var map = new Map()
  blocks.forEach(function (b) {
    var k = keyOf(b)
    map.set(k, (map.get(k) || 0) + 1)
  })
  return map
}

Expected output: unchanged paragraphs, headings and tables are classified without any character diffing. Success check: changing one word in one paragraph out of 200 leaves 199 blocks classified as unchanged by this pass alone.

4. Word-diff only the changed pairs, with a time limit and a fallback

Pair up a deleted block with the inserted block that replaced it (same position among the changed blocks, or same block type when position is ambiguous) and run a word-level diff on their plain text only when both texts are within MAXPAIRCHARS. With diff-match-patch that bound is the Diff_Timeout property, set to 1 second; a timed-out diff is still a valid diff, just less refined. When a pair exceeds the cap, skip word diffing entirely and render the old block as one whole deletion and the new block as one whole insertion. Never run a character-level diff across a whole large document.

Wrap inserted text in an ins element and deleted text in a del element, and escape every text segment before wrapping it: replace ampersands first, then any markup-significant characters, using a small escape function in your codebase. The diff markers are the only markup this step creates; all document markup comes from step 5.

Expected output: a small edit shows as a short ins and del run inside the paragraph; a replaced table or a huge replaced section shows as one del block followed by one ins block. Success check: the fallback path, not an exception or a hang, is what a 20000-character changed block produces.

5. Treat tables as one block outside, and diff cell by cell inside

A table is a single top-level block, so step 3 decides whether it changed at all. If it changed, do not word-diff across cell boundaries (that produces markers spanning cells and invalid table markup). Instead align rows by index and cells by index inside each row:

1. If a cell JSON is identical in both revisions, render it unchanged.
2. If only the cell content changed and its attrs are identical, word-diff the cell text per step 4, inside that cell only.
3. If colspan, rowspan, colwidth or background in the cell attrs changed, mark the whole cell as changed (for example by adding a diff class in your own rendering pass before sanitizing) and render the new cell content plainly; a span or width change has no meaningful word diff.
4. Added or removed rows render as whole-row insertions or deletions.

Expected output: merged and resized cells keep their shape in the diff view, and only genuinely edited cells are highlighted. Success check: a revision that only widens one column shows that one cell marked changed, with the new colwidth value present in the rendered cell attributes.

6. Render with generateHTML and the exact editor extension list

Render each block (or the reassembled document) with generateHTML from @tiptap/html, passing the same extensions array the editor was created with, including StarterKit or your explicit node set plus Table, TableRow, TableHeader, TableCell, TextStyle and any mark extensions that emit inline style (text color and highlight are the usual ones). generateHTML with a missing table extension silently drops the table or its cell attributes; a missing TextStyle extension drops the span elements that carry alignment and color.

var { generateHTML } = require('@tiptap/html')
var html = generateHTML({ type: 'doc', content: blocks }, extensions)

Here extensions is the shared array imported from the same module the editor setup imports it from; define it once and import it in both places.

Expected output: rendered table cells carry colspan and rowspan attributes when they differ from 1, a data-colwidth attribute when colwidth is set, and alignment or color appears as a style attribute on the paragraph or span that Tiptap produced it for. Success check: render the same JSON in the editor and through generateHTML and compare the table markup; any attribute present in one and missing in the other means the extension lists differ.

7. Sanitize last, with an explicit allowlist

Sanitizing must be the final step, after diff markers are inserted, so nothing reaches the page unsanitized and the sanitizer sees the real final markup. Configure DOMPurify with only the tags and attributes this view needs. On the server use the isomorphic-dompurify package or a jsdom-backed DOMPurify instance; plain DOMPurify needs a browser window.

var clean = DOMPurify.sanitize(dirtyHtml, {
  ALLOWED_TAGS: ['p', 'h1', 'h2', 'h3', 'h4', 'h5', 'h6', 'blockquote', 'ul', 'ol', 'li',
    'strong', 'em', 'u', 's', 'code', 'pre', 'a', 'span', 'br', 'hr',
    'table', 'thead', 'tbody', 'tr', 'th', 'td', 'colgroup', 'col', 'ins', 'del', 'img'],
  ALLOWED_ATTR: ['href', 'rel', 'target', 'alt', 'src', 'width', 'height',
    'colspan', 'rowspan', 'data-colwidth', 'style'],
  ALLOW_DATA_ATTR: false
})

Note what is absent: no script, iframe, form or event handler attributes, and data attributes are off except the named data-colwidth, which the attribute list admits explicitly. Links keep only safe protocols because DOMPurify validates URI attributes by default; do not widen that with ALLOWUNKNOWNPROTOCOLS.

Expected output: script elements, event handler attributes and javascript protocol links are gone, while tables, ins and del markers and allowed cell attributes survive. Success check: the test payloads in step 9 pass.

8. Filter inline style by property allowlist, inside a hook

Allowing the style attribute in step 7 does not filter what is inside it: DOMPurify treats the attribute value as opaque, so a style carrying a url value, an expression, or positioning that overlays the page survives sanitizing unless you filter it yourself. Register an uponSanitizeAttribute hook that parses the declaration list, keeps only allowlisted properties with pattern-checked values, rebuilds the attribute, and drops it when nothing survives. In the same hook, clamp colspan and rowspan to plain integers and data-colwidth to digits and commas only.

var ALLOWED_PROPS = {
  'text-align': /^(left|center|right|justify)$/,
  'color': /^(#[0-9a-fA-F]{3,8}|rgb\([0-9, ]+\)|[a-zA-Z]+)$/,
  'background-color': /^(#[0-9a-fA-F]{3,8}|rgb\([0-9, ]+\)|[a-zA-Z]+)$/,
  'width': /^[0-9]+(px|%)$/,
  'vertical-align': /^(top|middle|bottom|baseline)$/
}

DOMPurify.addHook('uponSanitizeAttribute', function (node, data) {
  if (data.attrName === 'colspan' || data.attrName === 'rowspan') {
    data.attrValue = /^\d+$/.test(data.attrValue) ? data.attrValue : '1'
    return
  }
  if (data.attrName === 'data-colwidth') {
    data.keepAttr = /^\d+(,\d+)*$/.test(data.attrValue)
    return
  }
  if (data.attrName !== 'style') return
  var kept = []
  data.attrValue.split(';').forEach(function (decl) {
    var parts = decl.split(':')
    if (parts.length !== 2) return
    var prop = parts[0].trim().toLowerCase()
    var value = parts[1].trim()
    var pattern = ALLOWED_PROPS[prop]
    if (pattern && pattern.test(value)) kept.push(prop + ': ' + value)
  })
  data.attrValue = kept.join('; ')
  data.keepAttr = kept.length !== 0
})

Because values must match a full-string pattern, values containing url references, var references, imports or multiple declarations smuggled into one value can never match and are dropped. Positioning, sizing offsets and z-index are absent from the allowlist on purpose: revision text needs alignment, color and column width, not layout control over the host page. Remember hooks are global on a shared DOMPurify instance; remove the hook after use in long-lived server processes, or use a dedicated instance for this view.

Expected output: a paragraph aligned center keeps its alignment, a colored span keeps its color, a sized table cell keeps its width, and a style carrying position fixed or a background url loses the whole attribute. Success check: after sanitizing, no style attribute in the output contains a property outside the allowlist table above.

9. Insert only the sanitized string, and prove it with tests

Set the sanitized string as the container element HTML (in React, the dangerouslySetInnerHTML prop with an object whose html key is the sanitized string; the prop name itself is the warning). Never insert the pre-sanitize string, and never mark stored content as trusted to skip this step.

Pin the behavior with tests:

1. XSS payloads: a paragraph carrying a script element, an image with an error handler attribute, a link with a javascript protocol href, and a cell with a positioning style. Expect all four neutralized and the style attribute removed.
2. Table snapshot: a document with a colspan 2 header cell and a colwidth array on a body cell. Expect the rendered, sanitized diff HTML to carry the same colspan and data-colwidth values.
3. Style cases: alignment and color survive; a url background and a fixed position do not.
4. Bound case: two 5000-block documents differing in one block. Expect completion well inside your request timeout, truncated reported if caps were hit, and exactly the one changed block marked.
5. Round trip: an unchanged revision pair renders with no ins or del elements at all.

Expected output: all five tests pass. Success check: deleting the step 8 hook makes tests 1 and 3 fail, which proves the hook, not the attribute allowlist, is what filters inline style.

When this applies

• A revision history, audit or review view renders two versions of a Tiptap or ProseMirror document and highlights what changed.
• Documents contain tables with merged cells (colspan or rowspan above 1) or resized columns (colwidth set), and the diff view must preserve that layout.
• Stored content carries inline style from text alignment, text color, highlight or cell width, and the team wants to keep those while still sanitizing.
• A naive whole-document character diff is too slow on large documents, or sanitized output keeps losing table attributes or alignment.

When this does not apply

• Live collaborative editing. That is the Tiptap Collaboration extension and Yjs; a rendered revision diff is a read-only view, not a merge mechanism.
• Plain text or Markdown documents with no rich structure. A simple line diff is enough and tables and inline style never arise.
• Content from a fully trusted single author rendered in an internal tool with no stored attacker input. Sanitizing is still cheap insurance, but the style hook and attribute clamping matter less.
• Editing the document inside the diff view. Render the diff read-only; send edits back through the editor so the JSON stays schema valid.

Variant: DOMPurify strips colspan, rowspan or table cell attributes

The attributes were not in ALLOWED_ATTR, or the HTML was generated without the table extensions so the attributes never existed. Fix both layers: generate with the full extension list (step 6) and allow colspan, rowspan and data-colwidth (step 7). Sanitizer config alone cannot restore attributes generation already dropped.

Variant: inline styles disappear after sanitizing

Either style is missing from ALLOWED_ATTR, or the hook rebuilt the attribute and every declaration failed its pattern (a common cause is values with units or functions the patterns do not admit, such as a width in rem). Check which layer removed it before widening any pattern, and widen by adding one tested property pattern at a time.

Variant: the diff view hangs or runs out of memory on big revisions

The diff is running at character level over the whole document, or block keys are being compared all-pairs instead of through a map. Move to the block pass in step 3, keep Diff_Timeout at 1 second for pairs, and enforce the step 2 caps with the whole-block fallback.

Variant: sanitized output still shows an overlay or a remote background

A style attribute was allowed without the step 8 property filter. DOMPurify alone does not parse CSS declarations. Add the hook, and treat a content security policy on the page as a second layer, not as a substitute for filtering the attribute.

Why it happens

Three separate systems each discard or endanger a different part of the rendering. ProseMirror diffing is expensive because a character-level Myers diff grows with the product of the two text lengths, so unbounded input means unbounded time; bounding has to happen structurally (blocks first, capped pairs, a timeout) rather than by optimizing the inner loop. Tiptap attributes live in the schema, not in the text: colspan, rowspan and colwidth only serialize when the table extensions that own them participate in generation, so rendering is exactly as faithful as the extension list you pass. And sanitizers work on tags and attributes, not inside attribute values: the style attribute is one opaque string to DOMPurify, so property-level safety only exists if your own hook parses and rebuilds it.

Edge cases and pitfalls

• Nested structures: lists and blockquotes contain blocks inside blocks, and tables contain rows inside a block. The cap and the hash pass operate on top-level blocks; recurse into a changed container for display, but never let recursion restart an unbounded diff at every level.
• Duplicate blocks: identical paragraphs repeated in a document are why step 3 counts keys in a Map instead of testing membership in a Set; a Set-based pass misclassifies the second copy of a repeated paragraph as inserted or deleted.
• colwidth is an array, not a number: a cell spanning two columns carries one width per spanned column, serialized as a comma joined data-colwidth value. Clamping it as a single integer corrupts resized merged cells.
• Marks versus attributes: bold and italic are marks and survive as elements; text alignment lives on the paragraph node and color lives on a TextStyle mark rendered as a span with style. Losing alignment or color is usually the style filter or a missing TextStyle extension, not the diff.
• Sanitize after marking, always: escaping and wrapping text in ins and del before sanitizing is safe because ins and del are on the allowlist; sanitizing first and inserting diff markup built from raw text afterwards reopens the injection hole the sanitizer closed.
• Server rendering needs a DOM: DOMPurify in Node requires a window from jsdom or the isomorphic wrapper. A sanitize call that silently returns its input because no window exists looks like success and is the most dangerous failure mode here; assert in a test that a script payload is actually removed in the server environment.