Markdown is a plain-text writing format: you write ordinary text with a few simple markers — # for headings, * for emphasis, - for lists, backticks for code — and a renderer turns it into formatted output. It is popular because the source stays readable even before rendering, and because it works everywhere from documentation to notes to README files. But Markdown has a quiet drawback: the source and the result are different things, and a small slip in the source — a missing blank line, a list indented by one space too many, a link bracket left unclosed — can change the rendered output in ways that are hard to predict from the source alone.

Writing with a live preview solves that problem. You see the formatted result beside the text as you type, so a formatting mistake shows itself immediately, while it is still cheap to fix. The Markdown Editor and Preview provides that side-by-side view in your browser, with no installation and no account, and your document stays on your device while you work.

How the tool works

The editor half is a plain-text area where you type Markdown. The preview half is a renderer that converts that text into formatted HTML and displays it, updating as you type. The two halves show the same document in two forms, and the discipline of using them together is simple: whenever the preview does something you did not expect, the source is wrong, not the preview. That rule sounds obvious, but it reverses the usual debugging instinct, which is to blame the tool. In Markdown, the renderer is doing exactly what the markers say; the task is to learn what the markers actually say.

The core markers are few. A heading is one to six # characters followed by a space and the heading text; more # characters mean a smaller heading. Bold is double asterisks or underscores around text; italic is single. A link is descriptive text in square brackets followed by a URL in parentheses. An image uses the same shape with an exclamation mark in front. A list item starts with a dash, asterisk, or number at the start of a line. A code span uses single backticks; a code block uses three backticks on their own lines before and after the code. A horizontal rule is three or more dashes, asterisks, or underscores on a line by themselves. That is most of everyday Markdown, and most documents need nothing more.

The preview also reveals structure that the source hides. A paragraph break requires a blank line: two lines of text with no blank line between them render as a single paragraph, not two. A list continues until a non-list line at the same level interrupts it, which means a paragraph immediately after a list may be swallowed into the last list item if it is indented. A heading needs a space after the # characters; without it, the line renders as plain text starting with hashes. Each of these rules is easy once seen, and the preview is what makes them visible.

A worked example

Type this short document into the editor:

# Weekend Project Notes

## Materials

- Timber offcuts
- Wood glue
- Sandpaper

## Steps

1. Measure the offcuts.
2. Glue and clamp overnight.
3. Sand the edges smooth.

See the [timber guide](https://example.com/timber) for sizes.

The preview should show a large title, a "Materials" heading, a three-item bullet list, a "Steps" heading, a three-item numbered list, and a final paragraph containing a link labelled "timber guide". Count the list items: three bullets and three numbered steps, six in total. If the preview shows fewer, something is off in the source — usually a missing blank line before a heading, or a list item that is indented differently from its neighbours.

Now try breaking it deliberately, because deliberate breakage is the fastest way to learn the rules. Remove the blank line between the title and the "Materials" heading and watch what happens. Join two list items onto one line and see them merge. Remove the space after ## and see the heading turn back into plain text. Each experiment teaches one rule more firmly than any description, and the preview gives you the answer in real time. When you return to writing real documents, those rules will be habits rather than things you have to look up.

A longer document benefits from the same approach at a larger scale. Write the headings first, as an outline, and check in the preview that the hierarchy looks right — one top-level title, sections beneath it, subsections beneath those. Then fill in the paragraphs under each heading. An outline that looks wrong in preview will produce a document that reads wrong too, and fixing the outline takes seconds while restructuring a finished document takes much longer.

Common mistakes

The most common mistake is the missing blank line. Markdown treats a blank line as a structural signal, and omitting it merges things that should be separate: two paragraphs become one, a heading after a paragraph may not register as a heading, and a list may absorb the text that follows it. When the preview merges two blocks you meant to keep apart, add a blank line between them first, before trying anything else.

The second mistake is inconsistent list indentation. Nested lists require the inner items to be indented further than the outer items, consistently — usually by two spaces. If one nested item is indented by two spaces and the next by four, the preview may split them into separate lists or flatten them unexpectedly. Pick one indentation width and use it for every nested item.

The third mistake is unclosed markers. An opening backtick, asterisk, or bracket without its closing partner does not just affect one word; it can swallow the rest of the paragraph, or the rest of the document, into code or emphasis or a broken link. When a large stretch of preview suddenly changes style, search backwards from the change for an unclosed marker. The preview shows you where the effect starts, which is usually close to where the marker was opened.

The fourth mistake is writing links and images from memory instead of checking them. A link with the URL and the text swapped, or with a missing closing parenthesis, renders as literal brackets and parentheses in the output — ugly, and a sign to the reader that the document was not checked. Click the links in the preview before you publish; a preview link that goes nowhere is a link you would otherwise have shipped broken.

Honest limitations

An editor with a preview shows you how Markdown renders; it does not improve your writing, check your facts, or guarantee that the output will look the same everywhere. Markdown has dialects: tables, footnotes, task lists, and strikethrough work in some renderers and not in others, and a document that previews perfectly in one tool may render differently in another. The editor also cannot fix content problems — a confusing paragraph renders just as faithfully as a clear one — and it does not convert your document to other formats. If you need a Word document or a PDF, that is a separate conversion step, with its own formatting decisions. Finally, a preview is a visual check, not an accessibility check: it will not tell you whether your images have useful alt text or whether your heading order makes sense to a screen reader.

Closing

Write in Markdown, watch the preview, and treat every surprise in the preview as a lesson about the source. Outline with headings first, guard your blank lines, keep list indentation consistent, and click your links before you publish. To build tables for your documents, use the Markdown Table Generator, and to convert existing HTML into Markdown, use the HTML to Markdown Converter. For the wider skill of keeping document structure intact across formats, see PDF to Markdown: Why Structure Is Worth Keeping.