Markdown flavors and compatibility

Markdown has multiple flavors: CommonMark (standardized core), GitHub Flavored Markdown (GFM adds tables, task lists, strikethrough), and extended variants supporting footnotes, definition lists, and math (LaTeX). Our editor uses GFM by default with CommonMark compatibility for the base syntax. The live preview renders the output so you can see exactly how the content will appear on GitHub, GitLab, or in static site generators like Next.js MDX.

When writing documentation for open-source projects, stick to GFM — it is the most widely supported. Avoid HTML in Markdown (except for elements Markdown cannot produce, like <details> or <video>), because some renderers strip inline HTML for security. Our editor highlights unsupported syntax so you catch issues before publishing.

Markdown for developers: beyond basic formatting

Markdown is widely used for API documentation, README files, and blog content. Advanced techniques include: fenced code blocks with syntax highlighting (specifying the language after the opening ```), collapsible sections (<details>/<summary>), and table alignment using colon placement. Our editor supports all GFM extensions and provides character and word counts for tracking documentation progress.

When using Markdown in CMS platforms like Contentlayer or MDX, be aware that frontmatter (YAML/TOML between --- delimiters) is parsed separately from the body. Our editor can validate frontmatter formatting and highlight YAML syntax errors.

How to use the Markdown Editor

Step 1: Type or paste your Markdown content into the editor panel on the left. The live preview on the right updates instantly as you type.

Step 2: Use Markdown syntax to format your text — # for headings, ** for bold, * for italic, - or * for bullet lists, and ``` for code blocks with syntax highlighting.

Step 3: Create tables using pipe characters (|) to separate columns and dashes (---) to create the header separator row. The preview renders the table with proper alignment.

Step 4: Add links using [text](url) syntax and images using  syntax. The preview shows clickable links and rendered images.

Step 5: Use the word and character counts at the bottom to track document length while writing documentation or blog posts.

Step 6: Export your content by copying the rendered HTML from the preview, or copy the raw Markdown for use in GitHub READMEs, documentation sites, or CMS platforms.

Common mistakes and how to fix them

Error: Missing blank lines before headings and lists. Many Markdown renderers require a blank line before headings (# Heading) and lists (- item) to properly detect block-level elements. Without the blank line, the heading may render as inline text.

Error: Incorrect table formatting. Tables need a header row, a separator row with at least three dashes per column (---), and data rows. Missing the separator row causes the table to render as plain text.

Error: Forgetting the space after heading markers. The syntax #Heading (no space) may not render as a heading in some parsers. Always use # Heading with a space after the hash marks.

Error: Code blocks not rendering. Fenced code blocks require three backticks (```) on their own line to open and close. If the closing backticks are indented or missing, the code block extends to the end of the document.

Error: Inline HTML being stripped. Some Markdown renderers strip inline HTML for security. If you need HTML elements like <details> or <video>, check that your target platform supports them.

Tips and best practices

Use reference-style links ([text][ref] and [ref]: url) for documents with many links. This keeps the Markdown source cleaner and makes link URLs easier to update in one place.

Add a blank line before headings and lists to ensure correct rendering across all Markdown parsers. This is the most common cause of formatting issues.

Use fenced code blocks with language identifiers (```javascript, ```python) for syntax highlighting. This makes code examples much more readable in documentation.

For long documents, use a table of contents generated from your headings. Many static site generators auto-generate TOCs, or you can create one manually with anchor links.

When writing for GitHub, use GFM (GitHub Flavored Markdown) extensions like task lists ([x] completed, [ ] incomplete), tables, and strikethrough (~~deleted~~) for enhanced formatting.