How to strict commonmark compliance conversion
- Step 1Paste or drop the source Markdown — Paste text or drop a single
.md/.mdx/.markdownfile. The tool processes one file per run (acceptsMultipleis false). - Step 2Understand this is the GFM-extension step, not full normalisation — The converter has no options (
needsOptions: false) and handles exactly three GFM constructs. It is not a complete spec-normaliser — tables, footnotes, alerts and emoji shortcodes are left as-is. Plan a verification step in your strict renderer afterward. - Step 3Run the conversion — Click Run. Task-list checkboxes are stripped,
~~strikethrough~~becomes<del>, and bare URLs are angle-wrapped. The three regex passes run together in a single pass. - Step 4Validate in a reference implementation — Run the output through
cmark(the CommonMark reference implementation) or your target renderer. The three rewritten constructs should now parse cleanly; check that surviving constructs render acceptably. - Step 5Resolve the constructs that still drift — Decide what to do with pipe tables (enable a table extension downstream, or render to HTML with the Markdown to HTML tool), footnotes (enable an extension or remove), emoji shortcodes (use the Emoji Remover), and alerts (they become plain blockquotes).
- Step 6Download and commit — Save as
.md. Output type ismarkdown. Commit once your strict renderer produces the output you expect end to end.
Compliance coverage: what this tool does and does not normalise
Use the 'Still drifts' rows as your post-conversion checklist before claiming strict CommonMark compliance.
| GFM construct | This tool's action | Strict-compliance status after |
|---|---|---|
| Bullet task lists | Checkbox removed → plain bullet | Compliant |
| Strikethrough | Rewritten to <del> raw HTML | Compliant (HTML allowed by spec) |
| Bare autolinks | Wrapped in <...> | Compliant |
| Pipe tables | Untouched | Still drifts — not in CommonMark |
| Footnotes | Untouched | Still drifts — not in CommonMark |
| Emoji shortcodes | Untouched | Still drifts — not in CommonMark |
| Alert blockquotes | Untouched | Renders as plain blockquote |
Tier limits
Markdown-family per-file limits. Character count is enforced separately from file size.
| Tier | Max file size | Max characters | Files per run |
|---|---|---|---|
| Free | 1 MB | 500,000 | 1 |
| Pro | 10 MB | 5,000,000 | 10 |
| Pro-media | 50 MB | 20,000,000 | 50 |
| Developer | 500 MB | Unlimited | Unlimited |
Cookbook
Compliance-oriented before/after, including the constructs that still need attention after the pass.
The three convertible constructs, normalised
A document with a checkbox, struck text and a bare URL comes out spec-compatible on all three.
Input: - [ ] ~~draft~~ final Spec: https://commonmark.org Output: - <del>draft</del> final Spec: <https://commonmark.org>
A table is left for you to handle
Pipe tables are not in CommonMark and the tool does not convert them. To make the table truly compliant, render it to HTML separately or enable a table extension in your strict renderer.
Input: | A | B | |---|---| | 1 | 2 | Output (table unchanged — still not strict CommonMark): | A | B | |---|---| | 1 | 2 |
Footnotes survive and still need a decision
CommonMark has no footnote syntax. The tool leaves them, so you must enable a footnote extension downstream or remove them for true compliance.
Input: Claim.[^a] [^a]: Source. Output (unchanged — footnotes are not CommonMark): Claim.[^a] [^a]: Source.
Verify with cmark
After conversion, run the file through the reference implementation to confirm the three rewritten constructs parse and to see how the survivors render.
Command: cmark converted.md > out.html Expect: - plain <ul> bullets (task checkboxes gone) - <del> renders struck - <a href> from angle-bracket autolinks - pipe table appears as a literal paragraph (no <table>)
Alert blockquote downgrades cleanly
The > [!NOTE] marker is left as text; a strict renderer shows a plain blockquote. That's the expected compliant rendering, just without the GitHub admonition styling.
Input: > [!NOTE] > Read this. Output (unchanged; renders as a normal blockquote in cmark): > [!NOTE] > Read this.
Edge cases and what actually happens
This is not a full spec-normaliser
By designThe tool handles exactly three GFM constructs (task lists, strikethrough, autolinks). It does not normalise heading styles, list indentation, blank-line spacing, or any other CommonMark detail, and it does not convert tables, footnotes, emoji or alerts. Calling the output 'strict CommonMark' is only accurate for those three constructs — verify the rest in your renderer.
Tables remain non-compliant
Still driftsPipe tables are a GFM extension that CommonMark does not define, and this tool does not convert them. A reference renderer like cmark will treat the table as a paragraph of pipe characters. For true compliance, render the table to HTML separately (the Markdown to HTML tool) or enable a table extension in your toolchain.
Footnotes remain non-compliant
Still driftsCommonMark has no footnote syntax and the tool leaves [^1] / [^1]: untouched. Under a strict parser they render as literal text. Enable a footnote extension downstream or remove them to reach full compliance.
Strikethrough relies on raw HTML being allowed
CautionThe strikethrough rewrite uses <del> raw HTML. CommonMark permits raw HTML, so cmark passes it through — but a strict pipeline that additionally sanitises HTML will strip the tag, dropping the strike. Confirm your toolchain allows inline HTML.
Autolink edge cases break some URLs
CautionThe autolink pass captures trailing punctuation (https://x.com. → <https://x.com.>) and truncates URLs containing ) (Wikipedia-style links). Both produce technically-wrapped but functionally-broken links. Pre-wrap such URLs in <> before running the tool for clean compliance.
Uppercase `[X]` checkboxes survive
Not matchedOnly [ ] and lowercase [x] are stripped. An uppercase - [X] keeps its checkbox, so a strict renderer will show the literal brackets. Lowercase your checkboxes before conversion for uniform results.
Output passing 'looks compliant' is not guaranteed by the tool
VerifyThe tool does not run a CommonMark validator or test suite. It applies three rewrites and trusts you to verify. Run the output through cmark or your renderer to confirm actual compliance — especially for documents heavy in tables or footnotes.
Other passes run even if you only wanted one
ExpectedAll three passes always run together; there are no options. If you only intended to strip checkboxes, strikethrough and autolinks will still be rewritten. Plan around the combined behaviour.
Free-tier size and character cap
413 size capFree tier rejects files over 1 MB or 500,000 characters, checked independently. Long academic manuscripts can hit the character cap first. Upgrade to Pro (10 MB / 5,000,000) or split before converting.
Frequently asked questions
Will the output pass the cmark test suite?
The three constructs this tool rewrites (task lists, strikethrough, autolinks) become CommonMark-compatible, so they parse cleanly under cmark. But the tool doesn't run a validator, and constructs it leaves alone — tables, footnotes, alerts — are not CommonMark and will render differently. Test your specific document in cmark to confirm full compliance.
Does it convert GFM tables to make them spec-compliant?
No. Pipe tables are not part of this transform and CommonMark has no table syntax, so a strict renderer treats them as plain text. For compliance, render the table to HTML separately (Markdown to HTML tool) or enable a table extension in your toolchain.
What about footnotes?
Left untouched. CommonMark has no footnote syntax, so [^1] references render as literal text in a strict parser. Enable a footnote extension downstream or remove footnotes manually to reach true compliance.
Is strikethrough-via-`<del>` really CommonMark compliant?
Yes — CommonMark explicitly allows raw HTML, so <del>text</del> is valid CommonMark and renders struck wherever HTML is permitted. The caveat is a pipeline that sanitises HTML for security, which would strip the tag and drop the strike.
Is this a complete CommonMark normaliser?
No. It handles exactly three GFM constructs. It does not normalise heading styles, list indentation, or blank-line spacing, and it doesn't touch tables/footnotes/alerts/emoji. Treat it as the GFM-extension step of a compliance workflow, then verify the rest.
How do I check compliance after running it?
Run the output through cmark (the CommonMark reference implementation) or your target renderer's preview. Confirm the rewritten constructs parse and review how surviving constructs (tables, footnotes) render. The tool itself does no validation.
Why are my Wikipedia URLs broken after conversion?
The autolink regex stops at ), so a URL containing a parenthesis like Markdown_(disambiguation) gets the closing ) placed outside the angle brackets, breaking it. Pre-wrap such URLs in <> before running the tool.
Does it normalise uppercase `[X]` checkboxes?
No. Only [ ] and lowercase [x] are stripped. - [X] keeps its checkbox and will show literal brackets in a strict renderer. Lowercase your [X] first.
Are there any options to control the conversion?
No — needsOptions is false. The three passes always run together. You can't disable any of them or select strict-only behaviours; the conversion is fixed.
Is the conversion done locally?
Yes. It runs in your browser using the shared converter engine. Manuscripts and internal documents are not uploaded during conversion; only an anonymous processed-file counter is recorded for signed-in stats.
What file sizes are supported?
Free: 1 MB / 500,000 characters / 1 file. Pro: 10 MB / 5,000,000 / 10. Pro-media: 50 MB / 20,000,000 / 50. Developer: 500 MB, unlimited. The character limit is enforced separately from byte size.
Which academic pipelines is this useful for?
Any pipeline built on a strict CommonMark reader — Pandoc's CommonMark reader, cmark-based static builders, or journal submission systems that follow the spec. This tool removes the GFM extensions those readers choke on; you still configure extensions (tables, footnotes) for what remains.
Privacy first
All Markdown processing runs locally in your browser using JavaScript. No file is ever uploaded to JAD Apps servers — only metadata counters are saved for signed-in dashboard stats.