Description
MarkItDown preserves some strikethrough representations but silently flattens semantically equivalent variants to plain text. This makes superseded or corrected text indistinguishable from current text in the Markdown output.
The behavior reproduces with the latest PyPI release, markitdown==0.1.7.
Minimal HTML reproduction
from pathlib import Path
from tempfile import TemporaryDirectory
from markitdown import MarkItDown
html = """<!doctype html>
<html><body>
<p>Plain <s>s element</s> after.</p>
<p>Plain <del>del element</del> after.</p>
<p>Plain <strike>strike element</strike> after.</p>
<p>Plain <span style="text-decoration: line-through;">inline CSS line-through</span> after.</p>
<p>Plain <span style="text-decoration-line: line-through;">CSS text-decoration-line</span> after.</p>
</body></html>
"""
with TemporaryDirectory() as tmp:
path = Path(tmp) / "fixture.html"
path.write_text(html, encoding="utf-8")
print(MarkItDown().convert(str(path)).markdown)Actual output
Plain ~~s element~~ after.
Plain ~~del element~~ after.
Plain strike element after.
Plain inline CSS line-through after.
Plain CSS text-decoration-line after.
Expected output
All five inputs express strikethrough and should retain that meaning, for example:
Plain ~~s element~~ after.
Plain ~~del element~~ after.
Plain ~~strike element~~ after.
Plain ~~inline CSS line-through~~ after.
Plain ~~CSS text-decoration-line~~ after.
At minimum, the obsolete but still encountered <strike> element could be normalized consistently with <s> and <del>. If parsing inline CSS is intentionally out of scope, documenting that limitation would make the loss less surprising.
DOCX observation
A minimal DOCX shows the same inconsistency between OOXML variants:
| OOXML run property |
Actual Markdown |
<w:strike/> |
~~single strike~~ |
<w:dstrike/> |
double strike |
Mapping double-strike to ordinary Markdown strikethrough would preserve the important semantic distinction from current text even if Markdown cannot represent the double line exactly.
Impact
The text itself remains present, so conversion appears successful, but consumers can interpret superseded text as current. This is particularly misleading in notes, procedures, and other documents where strikethrough carries meaning.
Environment
- MarkItDown: 0.1.7
- Python: 3.12.13
- OS: macOS 26.6.2, arm64
The same HTML and DOCX outputs were also observed through a MarkItDown MCP installation using markitdown==0.1.5.
Duplicate check
I searched open and closed issues for strikethrough, strike, line-through, double strike, and dstrike and did not find a report matching this behavior.
Description
MarkItDown preserves some strikethrough representations but silently flattens semantically equivalent variants to plain text. This makes superseded or corrected text indistinguishable from current text in the Markdown output.
The behavior reproduces with the latest PyPI release,
markitdown==0.1.7.Minimal HTML reproduction
Actual output
Expected output
All five inputs express strikethrough and should retain that meaning, for example:
At minimum, the obsolete but still encountered
<strike>element could be normalized consistently with<s>and<del>. If parsing inline CSS is intentionally out of scope, documenting that limitation would make the loss less surprising.DOCX observation
A minimal DOCX shows the same inconsistency between OOXML variants:
<w:strike/>~~single strike~~<w:dstrike/>double strikeMapping double-strike to ordinary Markdown strikethrough would preserve the important semantic distinction from current text even if Markdown cannot represent the double line exactly.
Impact
The text itself remains present, so conversion appears successful, but consumers can interpret superseded text as current. This is particularly misleading in notes, procedures, and other documents where strikethrough carries meaning.
Environment
The same HTML and DOCX outputs were also observed through a MarkItDown MCP installation using
markitdown==0.1.5.Duplicate check
I searched open and closed issues for
strikethrough,strike,line-through,double strike, anddstrikeand did not find a report matching this behavior.