A Markdown Editor with Live Preview: Write on the Left, See It Render on the Right

I write almost everything in Markdown now: weekly reports, READMEs, meeting notes, the docs for an internal API. The format is plain text, so it survives copy-paste, version control, and the next tool I happen to switch to. The one thing plain text doesn't give you is feedback. You type ## Setup and you have to imagine the heading. You build a table out of pipes and dashes and you cross your fingers that the columns line up. A live editor closes that gap: you write on the left, and the rendered result appears on the right as you type. No render button, no round trip — the preview shows exactly what the heading, the list, the code block, and the table will look like, updated on every keystroke.

That immediate feedback is the whole point, so let me show you what the common syntax actually does before getting into the longer documents.

The syntax you'll use 90% of the time

Markdown is small. Five or six constructs cover almost everything you write.

Headings are one to six # characters. # Title is an H1, ### Subsection is an H3. The number of hashes sets the level; that's it.

Lists come in three flavors. Unordered lists start each line with -. Ordered lists start with 1. (and you don't have to renumber — 1. on every line still renders 1, 2, 3). Task lists use - [ ] for an open box and - [x] for a checked one, which is perfect for action items.

Code is two kinds. Inline code wraps a ` word ` in backticks for things like file names. Block code uses a fenced block — three backticks, an optional language tag, your code, three backticks to close. The language tag is what turns on syntax highlighting.

Links are [visible text](https://url). Bold is **two asterisks**, italic is *one asterisk*.

Tables are pipes and dashes:

| Field | Type   | Required |
| ----- | ------ | -------- |
| id    | string | yes      |
| name  | string | no       |

Here's a small worked example. Type this on the left:

## Quick start

1. Install with `npm i widget`
2. Import it:

import { Widget } from "widget"; const w = new Widget({ theme: "dark" });

- [x] Read the docs
- [ ] Ship it

The right pane renders it as a level-two heading "Quick start", a numbered list where npm i widget shows in monospace, a JavaScript code block with import, const, and the string "dark" colored as keywords and strings, and a two-item checklist with the first box ticked. You never had to picture it — it's just there, sitting next to the source.

Writing READMEs, notes, and docs

Once the syntax is muscle memory, the editor earns its keep on real documents.

A README is mostly headings and code blocks: Install, Quick start, API, License. As you add headings, a live outline (a table of contents built from your # lines) gives you the document's shape at a glance — handy for spotting that you wrote three H2s and then jumped straight to an H4. Export the file as .md, commit it, and GitHub re-renders it with the same heading anchors the preview showed you, so your in-page links keep working.

Meeting notes lean on task lists. A skeleton of Goals / Discussion / Decisions / Action items, with each action written as - [ ] owner — task by Friday, renders as a clean checklist. The boxes are read-only in the preview on purpose, so nobody accidentally toggles one mid-meeting.

Technical docs are where code fences and tables matter most. A function reference with a parameter table, a fenced example, and a notes section is readable in plain Markdown and stays readable after you paste it into Notion or Confluence — both read the rich-text payload and keep the code block monospaced.

If you're keeping a running tally of how long a draft has gotten, the editor also shows word count and read time live; for a deeper pass on length and density you can drop the text into the word counter.

My own workflow

I'll be honest about the moment this clicked for me. I used to write weekly reports in a chat box, send them, and then get a DM asking why the code snippet was one unreadable line. So I started drafting in the live editor instead. I pick the weekly-report template, fill in the bullets on the left, and watch the right pane format them as I go. When it looks right, I hit "Copy rich" and paste straight into the team chat — the headings, the bold text, the code block, and the links all land formatted. The same copy, pasted into a plain-text field, gives back the raw Markdown source. One copy, two destinations. That single habit cut my "can you reformat that?" replies to roughly zero, and I stopped dreading the report.

The autosave matters more than I expected, too. The draft writes to your browser's local storage every 800ms, so a tab crash or an accidental close doesn't cost you the paragraph you were halfway through. I've reopened the page the next morning and found exactly where I left off.

Local processing and export

Everything here runs in your browser. The parser, the syntax highlighter, the word count, the autosave, and all three export paths execute on your device — nothing is uploaded, logged, or sent to a server. You can open the page, disconnect from the network, and keep writing. That's the right default for anything with internal product names, unreleased numbers, or client details in it.

Export comes in three shapes. Copy rich puts two payloads on the clipboard at once — an HTML version with rendered tags and a plain-text version with the original Markdown — so the destination picks whichever it understands. Download .md gives you the source file for your repo or static-site content folder. Download .html produces a single self-contained file with the CSS inlined, which opens in any browser, drops onto GitHub Pages, or attaches to an email. For a PDF, open that .html and use the browser's Print, then Save as PDF — it consistently beats the client-side PDF libraries I've tried.

When you want to go the other direction or do a one-shot conversion, the editor has neighbors that pair with it. If you just need to paste Markdown and grab HTML once, the Markdown to HTML converter is the focused tool for that, while the Markdown TOC generator builds a standalone table of contents you can drop at the top of a long doc.

Where to start

Open the live Markdown editor, pick a template that matches what you're writing — report, blog post, README, meeting notes, or function doc — and start typing. Watch the right pane. The fastest way to learn Markdown is to see it render the instant you write it, and the fastest way to ship a clean doc is to never lose the formatting between the editor and wherever it's going.

---

Made by Toolora · Updated 2026-06-13