Markdown Dialect Laboratory

Understanding Markdown dialect fragmentation

Markdown was created in 2004 as an intuitive syntax for converting plain text into HTML. However, because John Gruber's original specification left dozens of edge cases undefined, different platforms developed their own parsing implementations. This led to dialect fragmentation between strict specifications like CommonMark, developer extensions like GitHub Flavored Markdown (GFM), and knowledge-base extensions popularised by Obsidian.

When you take notes in personal knowledge management tools, you often use advanced syntax extensions without realising they may not render correctly in other applications. Understanding the three primary tiers of modern Markdown ensures your files remain future-proof and readable for decades:

1. CommonMark: the interoperable foundation

CommonMark is a strongly defined, unambiguous specification created by John MacFarlane and Jeff Atwood. It specifies exact whitespace handling, nesting rules, and precedence for basic inline and block formatting: headings, bold, italic, unordered and ordered lists, blockquotes, code spans, code blocks, and horizontal rules. CommonMark prioritises strict determinism over convenience features. It deliberately excludes tables, task checkboxes, and footnotes from its core standard.

2. GitHub Flavored Markdown: developer extensions

GitHub Flavored Markdown (GFM) builds directly on top of the CommonMark specification, adding five essential extensions: pipe tables, task lists with clickable checkboxes, strikethrough with double tildes, automatic URL linking, and footnotes. Because GFM is the default dialect of GitHub issues, pull requests, and README files, it has become the standard for technical documentation across the software industry.

3. Obsidian and local-first knowledge systems

Obsidian extends GFM with features tailored for non-linear thinking and networked thought. These include wikilinks ([[Target Note]]) for bidirectionally linking ideas, transclusions (![[Note]]) for embedding content, callouts (> [!note]) for highlighted sidebars, KaTeX math syntax for scientific equations, text highlights with double equals, and comments enclosed in double percent signs. While these features make writing in a desktop vault productive, exporting them to standard CommonMark renderers can leave raw syntax tokens visible.

How this dialect laboratory analyzes your notes

This browser laboratory scans your text using deterministic lexical extractors. It identifies every syntax construct, measures its frequency, and cross-references it against parser capabilities:

• Portability risk assessment: If your note relies heavily on Obsidian-specific wikilinks or callouts, the tool warns you that migrating to standard web CMS platforms or CommonMark tools will require link transformation or rendering plugins.
• Privacy gap detection: Obsidian comments (%%comment%%) are intended to remain private in reading mode. If your text includes comments, this tool highlights that migrating the raw Markdown file to a standard viewer will expose those private notes.
• Table formatting compliance: Verifies that pipe tables adhere to GFM delimiter row standards with proper colons for alignment.

Keeping your notes safe and portable

At Oyma, we believe that your notes should belong to you in plain files on your disk. That is why our desktop app reads standard Markdown directly from your local folders while natively supporting Obsidian wikilinks, callouts, and spreadsheet-like tables. Explore our comprehensive Markdown syntax reference to see implementation guides for every syntax construct, or use the Vault Health Inspector to check link integrity across your entire vault.