Tinker Tools

Markdown Viewer

Visualize your Markdown files instantly. Edit on the left, see the rendered HTML preview in real-time.

Editor| Preview

Welcome to Markdown Viewer

This is a live preview of your markdown text.

Features

  • Real-time rendering
  • Syntax highlighting
  • Easy export
  • GitHub Flavored Markdown support

Code Example

function greet(name) {
    console.log(`Hello, ${name}!`);
}

Table Example

Feature Status
GFM Tables
Task Lists
Strikethrough

Task List

  • Learn Markdown
  • Write some content
  • Share with others

Note: This is a blockquote example.

  1. Type on the left
  2. See changes on the right
  3. Enjoy!

How it works

1

Enter your Markdown

Type or paste your Markdown code into the left editor panel. The editor supports standard Markdown and GitHub Flavored Markdown syntax.

2

View Live Preview

As you type, the right panel automatically updates to show you exactly how your document will render in real-time.

3

Export Result

Click "Download HTML" to save the rendered output as a complete HTML file, or simply copy the result to your clipboard.

What is a Markdown Viewer?

Markdown is a lightweight markup language created by John Gruber and Aaron Swartz in 2004. The original idea was straightforward: write plain text with simple punctuation-based formatting that reads naturally as-is and converts cleanly to HTML. A Markdown viewer takes that plain text, parses it according to a specification, and renders the result as styled HTML in real time. You type a heading with a # prefix, wrap a word in asterisks for emphasis, indent four spaces for a code block, and the viewer shows you exactly how it will look when published. No switching between edit mode and preview mode in separate applications -- you see both at once.

The original Markdown spec left many edge cases undefined. What happens when you nest a blockquote inside a list? How should blank lines interact with indented code blocks? Different parsers handled these situations differently, which led to inconsistent rendering across platforms. The CommonMark specification -- first released in 2014 and actively maintained since -- exists to solve this problem. CommonMark defines precise rules for every ambiguous case, backed by over 600 test examples. When a Markdown viewer claims CommonMark compliance, you know that a document rendering correctly in that viewer will render identically in any other CommonMark-compliant tool. GitHub, GitLab, Reddit, and Stack Overflow all use parsers based on or influenced by CommonMark.

A Markdown viewer is not just a convenience tool for writers. Developers use it daily to preview README files, documentation pages, changelogs, and pull request descriptions before committing them. Technical writers use it to draft content that will eventually live in static site generators like Hugo, Jekyll, or Astro. The viewer bridges the gap between raw text and final presentation, catching formatting mistakes -- broken links, misaligned tables, unclosed code fences -- before anyone else sees them.

Key Features and Benefits

  • CommonMark-Compliant Parsing The viewer parses your Markdown against the CommonMark spec, which handles every ambiguous edge case with deterministic rules. Nested lists, lazy continuation lines, link reference definitions, and setext headings all render predictably. You get the same output whether you paste your document here or push it to a CommonMark-compatible platform like GitHub.
  • GitHub Flavored Markdown Extensions GFM adds features that the base CommonMark spec does not cover: tables with pipe syntax, task lists using [ ] and [x], strikethrough with double tildes, and autolinked URLs. These extensions are specified in the GFM spec maintained by GitHub and parsed by libraries like remark-gfm and markdown-it plugins. If you write README files or GitHub issues, GFM support is not optional -- it is essential.
  • Syntax Highlighting for Code Blocks Fenced code blocks tagged with a language identifier -- like ```javascript or ```python -- get syntax highlighting with accurate token coloring. The viewer uses grammars that recognize keywords, strings, comments, operators, and built-in functions for dozens of languages. This matters because code blocks without highlighting are a wall of monochrome text that forces readers to mentally parse every line.
  • Live Preview with Scroll Sync As you type or paste Markdown into the input pane, the rendered output updates instantly. Scroll position stays synchronized between the source and the preview, so when you scroll to line 200 in your source, the preview scrolls to the corresponding rendered section. This is particularly useful for long documents -- release notes, API documentation, tutorials -- where jumping between sections manually wastes time.
  • Automatic Heading Anchor Generation Every heading in your document gets an auto-generated anchor ID based on its text content. A heading like ## Getting Started becomes an anchor #getting-started. This lets you link directly to specific sections using standard fragment URLs. The anchor generation follows GitHub's algorithm: lowercase the text, replace spaces with hyphens, strip punctuation, and handle duplicates by appending a numeric suffix.
  • HTML Export and Conversion The viewer can export the rendered result as clean HTML. This is useful when you need to paste formatted content into a CMS, an email composer, or any system that accepts HTML but not Markdown. The exported HTML preserves heading hierarchy, list nesting, code block formatting, and table structure without adding unnecessary wrapper divs or inline styles.

How to Preview and Convert Markdown

  1. 1

    Paste or Write Your Markdown

    Enter your Markdown text in the input area. You can paste an entire README file, a draft blog post, or just a few lines you want to test. The viewer accepts any valid Markdown -- headings, paragraphs, lists, code blocks, links, images, blockquotes, and horizontal rules. If you are working with an existing file, copy its contents directly. There is no need to strip frontmatter (YAML between --- delimiters) manually; the viewer handles it gracefully by either ignoring it or displaying it as a code block.

  2. 2

    Check the Rendered Preview

    The right pane -- or the area below the input, depending on layout -- shows the rendered HTML output in real time. Scan it for formatting issues. Common problems include: a heading that shows as plain text because you forgot the space after the # character, a list that collapsed into a single paragraph because of missing blank lines, or a link that displays raw brackets because of a misplaced parenthesis. These are easy to spot in the preview and painful to find in raw text alone.

  3. 3

    Verify Table and Code Block Rendering

    Tables require pipe characters and a header separator row with at least three hyphens per column. A table like | Name | Age | followed by | --- | --- | followed by data rows will render as a formatted HTML table. Code blocks need triple backticks on their own line, with an optional language tag. Check that your tables align properly and your code blocks have the correct syntax highlighting. Missing a closing backtick fence is one of the most common Markdown mistakes -- it causes everything after the opening fence to render as code.

  4. 4

    Test Internal Links and Anchors

    If your document uses internal links to jump between sections -- written as [Setup Guide](#setup-guide) -- verify that they resolve correctly in the preview. The anchor must match the generated heading ID exactly. Capitalization, special characters, and duplicate headings all affect the generated anchor. Click the link in the preview to confirm it scrolls to the right section. This step saves you from publishing a document full of broken internal navigation.

  5. 5

    Export or Copy the Result

    Once the preview looks correct, grab the output in your preferred format. Copy the rendered HTML for pasting into web-based editors. Copy the raw Markdown if you made edits in the viewer and want to update your source file. If you need a standalone HTML page, the export function wraps the content in a minimal HTML document with a stylesheet. For documentation workflows, you can take the validated Markdown and feed it directly into your static site generator or documentation platform.

Expert Tips for Working with Markdown

Understand the difference between CommonMark and GFM before you start writing. CommonMark is the base specification -- it covers headings, paragraphs, emphasis, links, images, code blocks, blockquotes, lists, and thematic breaks. GFM extends CommonMark with tables, task lists, strikethrough, and autolinks. If your target platform only supports CommonMark, using GFM-specific syntax will result in raw pipe characters and tildes showing up in your published content. Always check which spec your rendering platform supports. Most documentation tools like Docusaurus and MkDocs support GFM or a superset of it, but email renderers and some CMS platforms may only handle basic CommonMark.

Learn the precise rules for list continuation. This trips up experienced Markdown users constantly. In CommonMark, a list item's continuation text must be indented to align with the first non-space content after the list marker. For a bullet list using - as the marker, that means two spaces of indentation. For an ordered list using 1. as the marker, that means three spaces. If your continuation paragraph is indented by the wrong amount, it breaks out of the list and becomes a standalone paragraph. This is why your carefully structured multi-paragraph list items sometimes render as a mess of disconnected text blocks. The viewer shows you immediately whether your indentation is correct.

Use reference-style links for documents with many URLs. Instead of cluttering your paragraphs with inline links like [text](https://very-long-url.example.com/path/to/resource?query=value), define your URLs at the bottom of the document: [text][1] in the paragraph and [1]: https://very-long-url.example.com/path/to/resource?query=value at the end. This keeps your source text readable and makes it easy to update URLs in one place. Reference links also make it simpler to reuse the same URL multiple times without duplication. The rendered output looks identical either way -- the difference is entirely in the authoring experience.

Pay attention to how Markdown handles HTML. The CommonMark spec allows raw HTML in Markdown documents, which means you can drop a <details> tag or a <table> with colspan attributes directly into your Markdown and it will pass through to the rendered output. But there is a catch: Markdown processing is disabled inside HTML block-level elements. If you open a <div> and write Markdown inside it, that Markdown will not be parsed -- it will appear as raw text. Some parsers offer extensions to re-enable Markdown inside HTML blocks, but the default behavior follows the spec. Use this feature sparingly and test the output in the viewer before committing. Mixing HTML and Markdown is a source of subtle rendering bugs that are hard to diagnose without a live preview.

Related Tools

Markdown rarely exists in isolation. You will encode HTML entities when embedding special characters in Markdown content that must not be interpreted as HTML tags. You will diff two versions of a document to see what changed between drafts. And you will count words when you have a target length for a blog post or documentation page. These tools fit naturally into a Markdown authoring workflow -- use them alongside the viewer to catch every issue before you publish.

Frequently Asked Questions

Recommended Tools