Markdown Preview - Online Markdown Renderer (GFM)

1. Three views while you draft

View preference persists in local storage for this browser. On a narrow phone screen, prefer single Preview or Source so columns do not crush the table you are debugging.

1. Start in split view: type or paste Markdown and watch the rendered layout update.
2. Switch to Source when you need a distraction-free draft, or Preview when you only care about layout.
3. When the structure looks right, keep the Markdown source; use Copy HTML only if the consumer needs an HTML fragment.

2. Problems the preview catches early

Fix these locally before opening a PR against a docs site. Catching fence and table mistakes here is cheaper than waiting for CI or a reviewer to scroll into a broken section.

• Unclosed fences: the rest of the document renders as one code block — a loud visual signal.
• Table separator rows whose pipe count does not match the header — tables fall back to plain text.
• Nested lists with mixed tabs and spaces — different renderers disagree; standardize on spaces.

3. GFM versus host dialects

remark-gfm covers common GitHub Flavored Markdown: tables, strikethrough, task lists, autolinks. Footnotes, math, and host-specific shortcodes may differ. For important long pieces: pass structure here, then spot-check anchors and image paths on the target host. Relative images can appear blank in local preview without proving they fail in production.

4. When Copy HTML helps

Prefer shipping Markdown to systems that render it natively. HTML copy is a bridge for stubborn editors, not the long-term source of truth.

• Email or CMS fields that accept HTML fragments.
• Treat HTML as a snapshot — not guaranteed parity for every Markdown extension.
• Relative image URLs still need real deployment paths.
• Strip wrapper tags if the host theme already supplies them.

5. Pair with TOC and table helpers

Generate a table of contents on the TOC tool, then return here to feel jump targets. Build wide tables in the Markdown table generator so pipes stay aligned. This page focuses on what-you-see rendering, not heading renumbering or bulk outline edits.

6. Habits that keep diffs readable

Consistent structure makes both preview and git blame easier. Security note: local preview still means you should not paste secrets into shared sessions — the risk is human, not a network upload from this page.

• Do not skip heading levels (H2 straight to H4) — outlines and TOC tools get confused.
• Tag fenced blocks with a language for humans and highlighters.
• Pick one list marker style (- or *) per document.
• If a host lacks callout syntax, use blockquotes or bold mini-headings instead.

7. Last-mile reminder

Use this as a pre-commit layout check: fences close, tables stand, lists nest. It does not replace the official preview on GitHub, GitLab, or your docs theme, but it blocks the most common accidents before you push.

8. Long docs, CI, and link hygiene

For handbooks that span thousands of lines, preview sections by pasting chapter-sized slices rather than forcing the entire book through the editor if your device feels sluggish. Keep heading hierarchy stable so TOC generators and docs CI link checkers stay green. When a docs pipeline renders with a different Markdown engine (Goldmark, CommonMark, MDX), treat this preview as GFM-oriented and schedule one host render before release. Copy HTML output into email only after you inline or strip styles your mail client will ignore. Broken relative links look fine as text but fail in preview navigation — click internal anchors after generating a TOC. For images, paste one absolute URL sample to verify rendering, then restore relative paths for the repo. Avoid raw HTML with scripts in Markdown drafts; preview is not an XSS lab for untrusted paste.

• Preview chapter-sized slices for very long handbooks.
• Re-render on the real host before cutting a docs release.