Markdown is a way of formatting plain text so it stays readable as you type but turns into proper HTML when rendered. A # becomes a heading, **stars** become bold, a -at the start of a line becomes a bullet. It was created by John Gruber and Aaron Swartz in 2004 and has since become the default for GitHub READMEs, documentation, static-site blog posts, chat apps, and note-taking tools, precisely because it's faster to write than HTML and easier to read than a wall of tags.

This tool does two things at once. On the left you write Markdown; on the right you see it rendered live, updating as you type, so you can catch a broken link or a mis-nested list the instant it happens instead of after you've published. And with the Raw HTML toggle, you can flip the preview to show the exact HTML your Markdown compiles to, then copy it with one click to paste into a CMS, an email template, or anywhere that wants HTML rather than Markdown. It's built for the two people who live in Markdown all day: developers writing READMEs and docs, and writers drafting posts they'll publish somewhere that speaks HTML.

The parser handles the common Markdown you'll actually use day to day. Headings from # h1 through ###### h6. Emphasis: **bold**, *italic*, ***bold italic***, and ~~strikethrough~~. Lists in both flavours — unordered with - or *, and ordered with 1. 2. 3., each rendered as a proper <ul> or <ol>. Links as [text](url) and images as ![alt](url). Blockquotes with a leading >. Horizontal rules from ---. And code in both forms: inline with single backticks, and fenced blocks with triple backticks plus an optional language tag.

Code handling deserves a specific note, because it's where naive Markdown converters trip up. Anything inside backticks — inline or fenced — is treated as literal. If you write a code sample that itself contains Markdown characters, like "**not bold**" inside a JavaScript string, the previewer leaves those asterisks exactly as typed instead of turning them into a <strong>tag. That's the correct behaviour and easy to get wrong: code is supposed to show the characters, not interpret them, so the parser pulls code out before it applies any formatting and puts it back untouched afterward.

Before Markdown, formatting text for the web meant one of two bad options. You either hand-wrote HTML — verbose, tag-heavy, and painful to read in source form — or you used a rich-text editor that hid the real structure behind a binary format and produced bloated, inconsistent markup you couldn't trust. Markdown's insight was that the formatting could live in characters people already used for emphasis in plain email and forum posts: asterisks around a word to stress it, a dash to start a list, a line of dashes as a divider. The result reads naturally even before it's rendered, which is why a Markdown file is perfectly legible in a terminal, a diff, or a code review.

That readability is exactly why it took over developer tooling. Because Markdown is plain text, it version-controls cleanly — a one-word change shows as a one-word diff in Git, not a tangle of altered tags — so it became the natural format for README files, changelogs, and documentation that live alongside code. From there it spread everywhere: static site generators, note apps, chat tools, issue trackers, and wikis all adopted it. Learning the handful of rules this previewer supports isn't learning a niche skill; it's learning the lingua franca that a huge amount of modern writing and documentation is authored in.

Markdown is readable in its raw form, which lulls people into publishing without checking the rendered result — and that's where small mistakes hide. A link with a missing parenthesis, a list that didn't get a blank line before it and so ran into the paragraph above, a heading with no space after the # that stays plain text, a code fence you forgot to close so half the document turns monospace. None of these are obvious in the source; all of them are glaring the moment you see the rendered version. Watching the preview update as you type turns those silent failures into instant, visible feedback.

The side-by-side layout is deliberate. You keep your hands in the editor and your eyes flick right to confirm each change did what you meant, without a compile step or a publish-and-refresh loop. For longer documents there's an expand button that blows the preview up to a full reading view, which is useful for judging how a whole README or article actually flows rather than squinting at a narrow column. The point throughout is to shorten the gap between writing a piece of Markdown and knowing whether it's right.

Flipping to Raw HTML shows the markup your Markdown compiles to — semantic tags like <h1>, <ul>, <ol>, <strong>, <blockquote>, and <pre><code>— and Copy HTML puts it on your clipboard. This is the bridge for the common case where you've written something in comfortable Markdown but the destination only accepts HTML: a website builder's custom-HTML block, an email newsletter, a CMS field, a forum or help-desk that doesn't speak Markdown natively. Rather than hand-converting, you draft in Markdown and lift the HTML.

One honest limitation to set expectations: this is a lightweight parser covering the everyday syntax above, not a full CommonMark or GitHub-Flavored-Markdown implementation. It does not do tables, task-list checkboxes, footnotes, nested lists, or automatic syntax highlighting inside code blocks (the language tag is preserved on the <code> element, but no colouring is applied). For a README that leans on those richer features, treat this as a fast drafting-and-preview surface and let GitHub itself render the final result. For the 90% of Markdown that is headings, emphasis, lists, links, quotes, and code, what you copy here is clean, correct, ready-to-paste HTML.

Most Markdown frustration comes down to whitespace, because Markdown is quietly strict about blank lines. A list needs a blank line before it or it gets swallowed into the preceding paragraph; the same goes for headings, blockquotes, and code fences. A very common surprise is that a single newline inside a paragraph does not create a line break in most renderers — you need either a blank line for a new paragraph or specific hard-break syntax. When your output looks like one long run-on where you expected separate lines, a missing blank line is almost always the culprit, and the live preview makes that visible immediately instead of after you publish.

The other frequent trip-up is characters that mean something in Markdown appearing where you wanted them literally. An asterisk in the middle of a sentence, an underscore inside a variable_name, a # starting a line you meant as plain text — each can trigger formatting you didn't intend. When you genuinely need the character itself, wrap it in backticks so it's treated as code, or restructure the line. And when you're showing Markdown or HTML as an example— teaching the syntax rather than using it — fenced code blocks are the right container, because this previewer keeps everything inside them literal, angle brackets and asterisks and all. Seeing the rendered result side by side is the fastest way to learn which characters are "hot" and when you need to escape them.

Rendering user-written Markdown into live HTML is a genuine security concern: if a converter naively injected whatever you typed into the page, someone could slip in a <script> tag and run code. This previewer guards against that by escaping every HTML-special character in your input first — before any Markdown rules run — so a literal <script> you type shows up as visible text, never as an executing tag. The Markdown tokens still work because they're plain characters like # and *that survive escaping; only the dangerous angle-bracket HTML is neutralised. So you can safely paste in someone else's README or a snippet from the web and preview it without risk.

On privacy, the precise picture: all of the parsing, the HTML conversion, and the copy happen in your browser with plain JavaScript. Your draft text is never sent to a server — there is no upload, no document store, no processing endpoint behind this tool, and it would keep working offline. What wouldn't be accurate is to call the whole page "100% isolated from the network": like every page on this site, it loads standard analytics and ads, which are ordinary web requests. The honest and useful claim is the narrow one — whatever you write and preview here stays on your device and is never transmitted — rather than a blanket promise that nothing on the page ever touches the network.