Markdown Editor/Preview

Write and preview Markdown with live rendering and syntax highlighting

How to Use

The Markdown Editor/Preview is a live, browser-based writing environment that renders your Markdown as you type. It splits the screen into an editing pane and a rendered preview, so you always see exactly how your document will look before you publish it. Built on GitHub Flavored Markdown (GFM), it handles the syntax you actually use day to day: headings, bold and italic text, links, nested lists, tables, task lists, strikethrough, blockquotes, and fenced code blocks. Everything runs locally in your browser, so your draft is never uploaded to a server. It is a practical tool for writing README files, documentation, blog posts, release notes, and issue descriptions without installing an editor or signing up for an account.
1

Type or paste your Markdown into the editor pane. The editor opens with a short sample document already loaded so you can see the syntax in context, and you can replace it with your own text at any time. Line breaks, indentation, and blank lines are preserved exactly as you enter them, which matters because Markdown uses blank lines to separate paragraphs and indentation to nest list items.

2

Watch the preview pane update as you type. There is no render button and no delay to wait through: every keystroke re-renders the document immediately, so a broken table or an unclosed code fence shows up the moment you create it rather than after you publish.

3

Switch the view mode to match what you are doing. Split View shows the editor and preview side by side and is the best default for active writing. Editor Only gives the full width to your text, which helps when you are working with wide tables or long code blocks. Preview Only shows just the rendered result, which is what you want for a final proofread.

4

Use the statistics row to keep track of length. The tool counts characters, words, lines, and paragraphs continuously. This is useful when you are writing to a limit, such as a package description, a pull request summary, or a documentation section that needs to stay scannable.

5

Click Copy Markdown to put the raw source on your clipboard. This is the version you paste into GitHub, GitLab, a static site generator, or any other system that accepts Markdown, and it is the version you should keep as your editable original.

6

Click Copy HTML to get the rendered markup instead. Use this when the destination expects HTML rather than Markdown, such as a CMS rich-text field, an email template, or a page where you are pasting directly into an HTML block.

7

Click Download to save your work as a document.md file. Because the editor does not save drafts between visits, downloading is how you keep a document you want to come back to. Do this before closing the tab on anything you care about.

8

Use Load Sample to bring back the demo document if you want to check how a particular piece of syntax should be written, and Clear to empty the editor and start fresh. Both replace the current content, so download anything you still need first.

Pro Tips

  • Your work is not saved between visits. There is no autosave and no browser storage, so a refresh, a closed tab, or a crash loses the draft. Download the .md file whenever you have written something you do not want to retype.
  • Code blocks are rendered as monospaced, correctly formatted blocks, but they are not colour-highlighted here. Fenced blocks with a language tag such as ```javascript will still highlight correctly once you paste them into GitHub or a site that applies its own highlighting.
  • Tables need a separator row of dashes directly under the header row, and the pipe characters do not have to line up. If a table renders as a single paragraph, the separator row is almost always what is missing.
  • Leave a blank line before and after tables, lists, and code fences. Markdown treats a block that is jammed against the previous paragraph as part of that paragraph, which is the single most common reason a list renders as one run-on line.
  • Task lists use the syntax - [ ] for an unchecked item and - [x] for a checked one, with a space inside the brackets. They render as checkboxes on GitHub and GitLab, which makes them useful for pull request checklists.
  • Raw HTML is passed through and rendered, so you can drop in a tag when Markdown has no equivalent. Only do this on content you wrote yourself, and remember that many platforms strip HTML from Markdown for security reasons, so test before relying on it.
  • Copy Markdown and Copy HTML are not interchangeable. Keep the Markdown as your source of truth and treat the HTML as a one-way export, because converting HTML back into clean Markdown later is considerably more work.

Use Cases

Markdown is the default writing format for software documentation, repository files, and most modern publishing platforms. A live editor removes the guesswork from writing it: instead of committing a README and discovering the table is broken, you see the rendered result while you write. These are the situations where that matters most.

Writing and Fixing README Files

Draft a project README with headings, install instructions, code samples, and a feature table, then confirm it renders correctly before you commit it.

Example: A developer is publishing a small library and needs a README with an installation section, a usage example, and a table of configuration options. Writing it directly in the repository means pushing a commit to see the result, and a misplaced separator row means another commit to fix it. Drafting it here shows the rendered table immediately, and the finished source goes onto the clipboard with Copy Markdown as a single clean commit.

Technical Documentation and Wikis

Write documentation pages with a proper heading hierarchy, nested procedures, and code examples for systems that accept Markdown.

Example: A technical writer is documenting an API endpoint. They need three heading levels, a parameter table, a request example in a fenced code block, and a bulleted list of error responses. The split view lets them confirm the heading hierarchy reads correctly and the parameter table lines up, and the paragraph count helps them keep each section short enough to scan.

Pull Request and Issue Descriptions

Compose long pull request descriptions and bug reports with checklists, code snippets, and structured reproduction steps before pasting them into your tracker.

Example: An engineer is opening a pull request that touches several files and wants the description to include a summary, a task list of what reviewers should check, and a snippet of the changed logic. The tracker's comment box has no preview, so they draft it here, confirm the task list renders as checkboxes and the code fence is closed, then paste the source into the pull request.

Blog Posts for Static Site Generators

Draft posts for Jekyll, Hugo, Astro, Next.js, or any generator that reads Markdown files, and check the structure before adding front matter.

Example: A writer is preparing a tutorial post for a Hugo site. They draft the body here to get the heading structure, code samples, and image references right, use the word count to keep the piece at the length they planned, then download the .md file and add the site's front matter block at the top before committing it.

Learning Markdown Syntax

See immediately what each piece of syntax produces, which is faster than reading a reference table and guessing.

Example: Someone new to Markdown has been asked to update a team wiki. They load the sample document, change one thing at a time, and watch what happens in the preview: what two asterisks do versus one, how a nested list needs to be indented, why a table needs its separator row. Ten minutes of this teaches more than a syntax cheatsheet.

Converting Markdown to HTML

Turn a Markdown document into HTML for a CMS field, an email template, or a page section that does not accept Markdown.

Example: A marketer has release notes written in Markdown but the company's CMS only offers an HTML block. They paste the Markdown in, confirm the preview matches what they expect, and use Copy HTML to get markup they can paste straight into the CMS, keeping the original Markdown file as the version they will edit next time.

Frequently Asked Questions

Is my document saved if I close the tab or refresh the page?

No. The editor keeps your text only in the page's memory, and it does not use browser storage or a server, so refreshing, closing the tab, or navigating away discards the draft with no recovery option. If you are writing something you want to keep, click Download to save it as a .md file before you leave. This is a deliberate trade-off: nothing is stored anywhere, which is why nothing needs to be trusted with your content, but it does mean you are responsible for saving your own work.

Which Markdown syntax is supported?

The editor renders GitHub Flavored Markdown, which covers standard Markdown plus the extensions most people expect: tables, task lists with checkboxes, strikethrough with double tildes, and automatic linking of bare URLs. Standard elements such as the six heading levels, bold, italic, ordered and unordered lists with nesting, blockquotes, horizontal rules, inline code, and fenced code blocks all work. Raw HTML embedded in your Markdown is also passed through and rendered.

Why are my code blocks not colour-highlighted?

This preview renders code blocks as correctly formatted monospaced blocks but does not apply syntax colouring. The language tag you write after the opening fence, such as ```python, is preserved in the source, so the block will highlight normally once you paste it into GitHub, GitLab, or a site that applies its own highlighting. Keep writing the language tags; they simply have no visible effect in this particular preview.

Why does my table render as a single line of text?

A Markdown table needs a separator row of dashes immediately below the header row, like |---|---|, and that row is what is usually missing. The other common cause is a missing blank line between the table and the paragraph above it, because Markdown then treats the whole thing as a continuation of that paragraph. The pipe characters do not need to be aligned and trailing pipes are optional, so neither of those is the problem.

What is the difference between Copy Markdown and Copy HTML?

Copy Markdown gives you the raw source exactly as you typed it, which is what you paste into GitHub, a repository file, or a static site generator, and it is what you should keep as your editable original. Copy HTML gives you the rendered markup instead, for destinations that only accept HTML such as a CMS rich-text field or an email template. Treat the HTML as a one-way export, since converting it back into clean Markdown afterwards is significantly more work than keeping the original.

Is there a limit on document length?

There is no fixed character or word limit. Because the preview re-renders on every keystroke and everything runs in your browser, very large documents of many thousands of lines may start to feel less responsive, particularly on older devices. If you notice typing lag on a long document, switching to Editor Only stops the preview from re-rendering as you type and restores normal speed.

Is my content uploaded anywhere?

No. All editing and rendering happen in your browser using JavaScript, and your text is never sent to a server. That makes the tool safe to use for internal documentation, unreleased release notes, or anything else you would not paste into an online service. The trade-off is the one described above: since nothing is stored, nothing persists after you close the tab.

Can I use this on a phone or tablet?

Yes. The layout adapts to small screens, though the split view is cramped on a phone because two panes have to share the width. On mobile it is usually better to write in Editor Only and switch to Preview Only to check the result, using the view mode buttons to move between them rather than trying to keep both visible at once.

Why Use This Tool?

Writing Markdown without a preview means finding out whether it worked only after you publish it. A live editor closes that gap, and doing it in the browser removes the setup and the privacy questions that come with installing an editor or signing into a service.

  • See errors while you write: A broken table, an unclosed code fence, or a list that will not nest appears in the preview the moment you create it, instead of after a commit and a page reload.
  • Nothing to install or sign up for: The tool opens in a browser tab and works immediately, which makes it practical on a machine you do not administer or when you just need to fix one file.
  • Your content stays on your device: Rendering happens entirely in your browser, so drafts of internal documentation or unpublished notes are never transmitted to a server.
  • Both output formats available: Copy the Markdown source for repositories and static sites, or copy rendered HTML for systems that only accept markup, without needing a separate converter.
  • Length feedback as you go: Live character, word, line, and paragraph counts help you write to a limit and keep documentation sections short enough to actually be read.
  • A fast way to learn the syntax: Changing one thing and immediately seeing the effect teaches Markdown considerably faster than working from a reference table.
  • View modes for each task: Split view for drafting, editor only for wide tables and long code, preview only for a final read-through, so the layout matches what you are doing.

Related Tools