Markdown Preview

How to use this Markdown preview

Use this preview when writing README files, documentation, issue templates, release notes, or any text that will be published through a Markdown-based system.

Markdown Preview features

What this preview supports

This Markdown preview is built for common writing and documentation workflows. It supports GitHub-flavored Markdown features such as tables, task-style lists, code blocks, links, headings, and inline formatting.

It is most useful when the formatting matters more than the editing environment. Product teams can check release notes, engineers can test README examples, and support teams can clean up public help text before pasting it into another system.

Markdown is intentionally portable, but platforms still differ. Treat this preview as a close check for structure and readability, then confirm any platform-specific extensions in the destination app.

How Markdown is rendered

The preview converts Markdown to HTML using GitHub-flavored Markdown settings, then sanitizes the generated HTML before displaying it. That keeps the preview useful for real formatting checks without treating pasted HTML as trusted content.

The renderer updates as you type, so the quickest workflow is to draft in small sections and scan the preview whenever you add a heading, nested list, table, or fenced code block. Those are the places where Markdown mistakes are easiest to miss in plain text.

Markdown preview FAQ

Preview Markdown for the renderer that will publish it

Markdown is a family of related syntaxes rather than one identical format everywhere. Basic headings, paragraphs, emphasis, links, code spans, and lists travel well. Tables, task lists, footnotes, automatic links, and raw HTML are extensions whose support varies. The CommonMark specification defines a widely used baseline, but a publishing system may add or remove features.

Preview with the final destination in mind. A README on a code host, a documentation generator, a note app, and a content management system may sanitize HTML differently or use different URL rules. Copy a small test into the real system before publishing a long document. Check nested lists, fenced code, table alignment, images, and links because these are common portability trouble spots.

Use a clear heading hierarchy. Start the document at the level expected by its surrounding page, then move one level at a time. A visually smaller heading is not a reason to skip a level; styling belongs to the final site. Descriptive headings help screen-reader users navigate and make a long document easier for everyone to scan.

Write link text that names the destination or action. “Read the deployment guide” is more useful than “click here,” especially when links are listed out of context. Add useful alternative text to informative images and empty alternative text to purely decorative images when the publishing system supports it. The preview can show markup, but it cannot decide whether the description communicates the image's purpose.

Code fences protect examples from being interpreted as prose. Add a language identifier only when the destination uses it for highlighting, and verify that copied commands do not include prompts or secrets. Very long lines can still create horizontal scrolling in narrow layouts. Wrap explanatory text naturally and keep machine-sensitive code unchanged.

Raw HTML is the least portable option. Some systems allow it, others escape it, and security filters may remove scripts, event handlers, iframes, or styles. Do not try to bypass the destination's sanitizer. If the document needs an interactive component, use the destination's supported component system rather than embedding untrusted markup.

Before publishing, read the rendered version and the source. The rendered view catches broken structure; the source catches malformed URLs, accidental spaces, and closing delimiters that happen to look acceptable. Test every external link and use relative links only when you know the document's final location. A preview produced in the browser cannot confirm that a private or future URL will be available to readers.

Lists need consistent indentation and blank-line treatment. A number in the source does not always control the displayed sequence, and restarting a list can depend on the renderer. Check ordered steps when their numbers carry meaning. Avoid putting an entire paragraph in a list item only to achieve visual indentation; that weakens the document structure.

For collaborative documents, format one concern at a time. Rewrapping every paragraph while changing facts creates a difficult review. Keep factual edits, link updates, and broad formatting changes separate when possible. If copied Markdown includes hidden Unicode spaces or smart punctuation, replace only the characters that break the target system.

• Check heading levels, list nesting, code fences, tables, images, and every link at narrow and wide widths.
• Read the text without styling to make sure meaning does not depend on color, position, or decorative symbols.
• Confirm the destination's sanitizer and extension support before relying on raw HTML or nonstandard syntax.

Final review checklist