Markdown Previewer: Live Preview, Render and Export MD and MDX Online

If you write documentation, README files, blog posts, or technical content of any kind, you already know the markdown workflow. You write in a text editor, save the file, open it in a browser or GitHub, and then notice the heading is wrong or the code block didn't render the way you expected. So you go back, fix it, save again, refresh. Repeat ten times per document.

It's a small friction point, but it adds up. Especially when you're writing something complex: a README with multiple sections, a blog post with code examples, or MDX content with component references.

That's exactly why we built the Markdown Previewer on Tooltri. Paste your content, see the rendered output instantly, make changes, and see them reflected in real time. No save cycle. No tab switching. No waiting.

What Is Markdown and Why Does Everyone Use It?

Markdown is a lightweight markup language created by John Gruber in 2004. The idea was simple: let people write plain text that looks readable as-is, but can also be converted to clean HTML automatically.

It caught on fast. GitHub made it the default for README files and pull request descriptions in 2009. Stack Overflow adopted it for answers. Jekyll made it the standard for static site blogging. Notion, Linear, Obsidian, Bear, Ghost, Hashnode: virtually every modern writing tool either uses Markdown natively or supports it as an import format.

The reason it stuck is the same reason it was designed that way in the first place. Plain text is portable. It doesn't lock you into an app. It works in every editor, every operating system, every version control system. A .md file you write today will still be perfectly readable in twenty years.

But plain text has one limitation: you can't see the formatting until something renders it. That's the gap a Markdown previewer fills.

What Is MDX and How Is It Different?

MDX is Markdown extended with JSX. It lets you use React components directly inside your Markdown content.

import { Chart } from './Chart'

## Quarterly Results

Here's the breakdown for Q3:

<Chart data={q3Data} />

The numbers above show a clear trend toward...

This is MDX. It reads like Markdown, but the <Chart /> component is a real React component that gets rendered in the final output.

MDX was created specifically for documentation sites and content-heavy React applications. Docusaurus uses it. Contentlayer supports it. The Next.js docs are written in MDX. If you're building a modern web application with a blog or documentation section, there's a good chance you're working with MDX files.

The challenge with MDX is that standard Markdown previewers can't render the JSX component parts. Those require the full React runtime and access to the actual component code. Our previewer handles MDX files gracefully: it renders everything it can (all the standard Markdown content), displays component tags as text so nothing breaks, and automatically detects when your content is MDX so you always know what you're working with.

The Live Preview That Actually Works

Most online Markdown previewers have the same problem: they feel like an afterthought. A basic textarea on the left, a div on the right, minimal styling that looks nothing like how the content will actually appear in production.

The Tooltri Markdown Previewer renders with styling that respects your content. Headings have proper visual hierarchy. Code blocks look like code blocks: monospace font, distinct background, clearly separated from regular text. Blockquotes have a left border accent. Tables have bordered cells with alternating row backgrounds so they're actually readable. Links open in a new tab. Images render from URLs. Task list checkboxes render as actual checkboxes.

Everything updates as you type. There's no debounce delay that makes the preview lag behind what you're writing. The rendered output reflects your current content at every keystroke.

Every Standard Markdown Element, Rendered Correctly

Here's a complete reference of what the previewer handles.

Headings

All six heading levels render with proper size hierarchy. H1 is your document title, bold and large. H2 is your primary section divider. H3 through H6 provide nested structure for complex documents. The visual weight difference between each level is clear enough that your document structure reads naturally without needing to count the hash symbols.

Text Formatting

Bold with **double asterisks**, italic with *single asterisks*, and strikethrough with ~~tildes~~ all render correctly. You can combine them: **bold and *italic* together** works as expected.

Inline Code and Code Blocks

Inline code with single backticks renders with a monospace font and a subtle background highlight, making it visually distinct from surrounding prose. Fenced code blocks with triple backticks render with their own distinct block styling: a different background, clear padding, and horizontal scroll for long lines.

Blockquotes

Blockquotes render with a left border accent in the primary color. They're visually clear and handle nested blockquotes correctly.

Lists

Unordered lists, ordered lists, and nested lists all render with proper indentation and spacing. Mixed nesting renders correctly too: an ordered list inside an unordered list, for example, works as expected.

Task Lists

GitHub Flavored Markdown task lists with - [ ] and - [x] syntax render as visual checkboxes. They're read-only in the preview since this is a previewer, not an interactive task manager. But they look exactly as they would on GitHub.

Tables

GFM tables render with bordered cells and alternating row backgrounds. Column alignment specified in the separator row is respected. Tables with many columns get horizontal scroll so they don't overflow the preview panel.

Horizontal Rules

--- and *** both render as visible horizontal dividers, useful for separating major sections of a document.

Links

Inline and reference-style links both render as styled anchor tags. All links open in a new tab so you don't lose your work in the editor.

Images

Images with valid URL sources render inline. If the src is a relative path that can't resolve in the browser context, the alt text is shown as a fallback.

Reading Time, Word Count, and Character Count

These three stats live in the toolbar and update in real time as you write.

Reading time is calculated at 200 words per minute, which is the standard average reading speed used across publishing, content strategy, and academic research. For a 1,000 word document you'll see "5 min read". For anything under a minute it shows "less than 1 min read" rather than "0 min read", because even a 50 word paragraph takes some time to read.

Word count counts every whitespace-separated token in your content. This includes words in headings, list items, code blocks, and blockquotes: everything visible in the editor. It does not count markdown syntax characters like asterisks, hash symbols, or backticks as words.

Character count is the total length of the raw markdown content including spaces, punctuation, and newlines. This is useful for platform-specific limits. Some CMS platforms have character limits on post content, and some API contexts require you to know the rough size of your content before sending it.

All three stats are calculated using the same logic as the Word Counter tool on Tooltri, so the numbers are consistent if you copy content between the two tools.

Import: Open .md and .mdx Files Directly

The Import button opens your device's file picker filtered to .md and .mdx files only. Select any Markdown file from your filesystem and its full contents load directly into the editor.

This is useful in a few different ways.

You can open a README file you're working on, check how it renders without pushing to GitHub, fix any formatting issues, and save the corrected version. This is faster than the push-refresh-fix cycle.

You can open an existing blog post and see exactly how it will render before publishing. This is particularly useful if you're migrating content between platforms and want to verify the markdown is compatible with the new renderer.

You can open MDX files to check the non-component parts: headings, text, tables, code blocks, without needing a full development environment running.

After import the file type badge automatically reflects the file extension, all stats update immediately, and the editor receives focus so you can start editing right away.

Export: Download Your Work as a File

The Export button downloads the current editor content as a file to your device. The filename is tooltri-markdown-export.md or tooltri-markdown-export.mdx depending on what the file type badge is showing.

This is straightforward but genuinely useful. You can use the editor as a scratch pad for writing Markdown content, then export it when you're ready to drop it into your project. You can copy content from a CMS, clean it up in the editor, and export it as a proper .md file. You can make quick edits to imported files and export the corrected version.

No sign-up, no cloud save, no account. Your content never leaves your browser. Export downloads directly from the client side.

Copy: Raw Markdown to Clipboard

The Copy button copies the raw markdown text from the editor to your clipboard in one click. Not the rendered HTML: the actual markdown source.

This is useful when you've been writing in the editor and want to paste the content somewhere else: a GitHub PR description, a Notion page, a CMS editor, or a Slack message with markdown support. One click and it's in your clipboard.

Common Markdown Workflows Where This Tool Helps

README files before pushing to GitHub

You write the README, paste it into the previewer, check that all the tables look right, all the code blocks are formatted correctly, and all the heading levels make sense. Fix anything that looks off before committing. This takes thirty seconds and saves you the embarrassment of a broken README on your public repo.

Blog posts before publishing

If you write blog posts in Markdown before pasting into your CMS, use the previewer to check the final render. Different CMS platforms handle edge cases differently: nested lists, tables, task lists. Catching those discrepancies before publishing is easier than fixing a live post.

Documentation drafts

Technical documentation often has complex structure: multiple heading levels, lots of code blocks, tables with many columns. The previewer lets you see the full rendered document as you build it out, which makes structural decisions much easier.

Learning Markdown syntax

If you're new to Markdown and trying to understand how different syntax elements render, the live preview is one of the fastest ways to learn. Type a syntax pattern, see immediately what it produces. The feedback loop is instant.

MDX content verification

If you're working on MDX content for a Docusaurus site, Next.js blog, or Contentlayer project, you can verify the non-component parts of your MDX files render correctly without running your full development server. Useful for quick checks on content-heavy files.

Why Everything Runs in Your Browser

No file you import or text you type in this tool ever leaves your browser. There is no server receiving your content. There is no database storing your documents. There is no analytics tracking what you write.

This matters more than it might seem. Documentation files contain technical details about your systems. README files describe your project architecture. Blog posts might contain embargoed announcements or unreleased content. Pasting any of that into a tool that sends it to a server is a real privacy consideration.

The Markdown Previewer processes everything locally using JavaScript running directly in your browser tab. The import reads your file using the browser's FileReader API and the file never uploads anywhere. The export creates a blob in memory and downloads it directly with no server involved. The rendered preview is computed in the browser tab and nothing is transmitted.

This is the same privacy-first architecture behind every tool on Tooltri. No sign-up required to use any of it.

Markdown Syntax Quick Reference

If you're writing in the editor and need a reminder of the syntax, here's the most commonly used subset.

Headings: # H1 through ###### H6

Bold: **bold text**

Italic: *italic text*

Strikethrough: ~~strikethrough~~

Inline code: `code`

Link: [link text](https://url.com)

Image: ![alt text](https://image-url.com)

Unordered list: - item or * item

Ordered list: 1. item

Blockquote: > quoted text

Horizontal rule: ---

Table:

| Column 1 | Column 2 |
|----------|----------|
| Cell 1   | Cell 2   |

Task list:

- [ ] Unchecked item
- [x] Checked item

Frequently Asked Questions

Does this support GitHub Flavored Markdown?

Yes. The previewer supports GFM which includes tables, task lists, strikethrough, and auto-linking URLs. These are the extensions that GitHub adds on top of standard CommonMark, and they're the ones most commonly used in README files and documentation.

Will my MDX components render in the preview?

No, and this is intentional. Rendering JSX components requires the actual component code and a full React runtime with access to your project's imports. A browser-based previewer can't execute your custom components without your entire project running. The previewer handles MDX gracefully by rendering all the standard Markdown content correctly and showing component tags as text so the preview doesn't break. For verifying component rendering you need your development server running.

What happens if my Markdown has syntax errors?

Markdown is extremely forgiving. There aren't really hard syntax errors in the same way code has syntax errors. Unrecognized patterns just render as plain text. If you type **bold without closing it, it renders as the literal text **bold. The preview will never crash or show an error state due to Markdown content.

Can I use this for very long documents?

Yes. There's no character limit on the editor. Very long documents containing tens of thousands of words will continue to preview correctly, though the real-time update may have a slight delay on extremely large files depending on your device's performance.

Is there a way to save my work between sessions?

Currently the editor does not persist content between browser sessions. If you close the tab your content is gone. Use the Export button to download your work before closing. This is a deliberate design choice: storing user content raises privacy and storage questions that don't exist when everything stays ephemeral and local.

Does the reading time account for code blocks?

The reading time is calculated based on total word count including words inside code blocks. This means technical documents with heavy code content may show a reading time that's higher than how long most readers would actually take, since code is typically skimmed rather than read word by word. For editorial content without much code the reading time estimate is accurate.

What's the difference between this and just using VS Code preview?

VS Code's built-in Markdown preview is excellent if you're already in VS Code with the file open locally. The Tooltri previewer is useful when you don't want to open a full editor: when you're pasting content from a CMS, checking a snippet someone shared with you, writing something quickly in a browser, or working on a device where VS Code isn't installed. It's a complement to local tooling, not a replacement.