Vista Previa Markdown

The preview implements the CommonMark 0.31 specification extended with GitHub Flavored Markdown additions. CommonMark is the strictly defined, unambiguous specification that resolved years of inconsistency between Markdown parsers. It covers headings, emphasis, strong, blockquotes, fenced code blocks, inline code, links, images, and hard line breaks with precise rules for every edge case. GitHub Flavored Markdown adds four widely used extensions to CommonMark: tables using the pipe syntax, task lists using hyphen-bracket syntax such as - [ ] and - [x], strikethrough using double tildes, and autolinks for bare URLs and email addresses. Fenced code blocks support syntax highlighting for over 150 programming languages including Python, JavaScript, TypeScript, Rust, Go, Java, SQL, Bash, YAML, and TOML. Inline HTML passes through and renders as written, which is CommonMark-compliant behavior. The preview does not include MathJax, KaTeX, Mermaid diagram rendering, or custom admonition syntax. Those are platform-specific extensions. Adding them would make the preview misleading for users whose target platform does not support them. If your deployment target uses a different Markdown flavor — for example, Hugo's Goldmark, Jekyll's Kramdown, or Notion's custom parser — test a sample of your most complex formatting directly in that platform before relying on this preview for final verification. Practical tip: for GitHub README files specifically, this preview is highly reliable because it implements the same spec GitHub uses. Verify table alignment in the GitHub interface before merging, as column-width rendering can differ between the preview and GitHub's rendering engine.

Yes. The preview re-renders on every input event with a 150-millisecond debounce delay applied to smooth performance on longer documents. The debounce means the render fires 150 milliseconds after you stop typing, rather than on each individual keystroke. For typical typing speed, this makes updates feel nearly instantaneous. For documents shorter than approximately 50 kilobytes — roughly 8,000 to 10,000 words — the full parse and render cycle completes in under 10 milliseconds on modern hardware. The 150-millisecond debounce is the only latency you notice. On documents in the 50 to 200 kilobyte range — long technical articles, chapter drafts, or large README files — the render takes 20 to 80 milliseconds. Combined with the debounce, you see the update about 200 to 250 milliseconds after you stop typing. On very large files above 500 kilobytes, the render may take 200 to 500 milliseconds. If you experience stuttering or visible lag on a large document, switch to manual-refresh mode using the toggle at the top of the editor. In manual mode, the preview updates only when you click the Render button. This lets you type freely without any re-render overhead. The toggle state is preserved in your browser's local storage, so if you work regularly with large documents, the preference persists across sessions. Practical tip: keep the preview panel visible during writing rather than toggling it open only to check — catching formatting mistakes in real time costs far less effort than reviewing a finished draft for syntax errors.

Yes, with important caveats about fidelity. When you paste formatted rich text from Google Docs or Microsoft Word into the editor, the tool reads the clipboard's HTML representation of the content and converts it to Markdown syntax on paste. Standard formatting maps cleanly. Heading styles H1 through H6 convert to the appropriate number of hash symbols. Bold text converts to double asterisks. Italic text converts to single underscores. Ordered and unordered lists convert correctly. Hyperlinks convert to the [text](url) syntax. Simple tables convert to pipe-delimited Markdown table syntax. More advanced formatting does not survive the conversion. Merged table cells have no Markdown equivalent and are dropped to the nearest plain representation. Table cell alignment via the colon syntax is partially preserved but may need manual adjustment. Text color, text size, custom fonts, and background highlights have no Markdown representation and are stripped. Comments, revision history, tracked changes, footnotes, and endnotes are all discarded. Images paste as broken references unless you replace the src with an accessible URL. If you need a precise Markdown conversion from a Word document, the most reliable method is to use pandoc on the command line: pandoc -f docx -t gfm input.docx -o output.md. This handles complex tables, footnotes, and image extraction more accurately than clipboard paste. Practical tip: use paste-to-Markdown for quick drafts and paragraph restructuring. For final handoff documents, use pandoc or a dedicated conversion tool to avoid silent data loss.

Yes, with one specific caveat about raw HTML blocks. The Markdown-to-HTML renderer sanitizes its output against a strict allowlist that covers standard document elements: paragraph tags, heading tags H1 through H6, emphasis, strong, blockquotes, ordered and unordered lists, list items, code and pre blocks, tables, links with href attributes, and images with src and alt attributes. Script tags are stripped entirely. Inline event handler attributes like onclick, onload, and onerror are stripped. javascript: and data: URL schemes in href and src attributes are blocked. This sanitization means copied HTML is safe to paste into CMS platforms that accept HTML input, including WordPress's Code view, Webflow's HTML embed, and custom CMS rich-text fields. The exception is raw HTML blocks you include in your Markdown source. CommonMark allows arbitrary HTML blocks embedded directly in Markdown, and the renderer passes them through as written per the specification. If your Markdown source contains a raw HTML block with JavaScript or unsafe attributes, those will appear in the rendered output exactly as you wrote them. That is intentional and standards-compliant, but it means you are responsible for verifying any raw HTML you include. For CMS platforms that accept Markdown source natively — Ghost, Dev.to, Hashnode, Obsidian Publish, and most static site generators — paste the Markdown directly rather than the rendered HTML. The platform's own renderer will produce the correct output for its environment. Practical tip: always review the rendered HTML in Developer Tools before pasting into a CMS if your Markdown source contains any raw HTML blocks.