Markdown Editor
Write Markdown with a live side-by-side preview. Supports GitHub Flavored Markdown (GFM) including tables, task lists, and fenced code blocks. Download as a file or convert to HTML.
Key features
- See results instantly with live side-by-side preview
- GitHub-compatible (GFM) rich text support
- Automatic formatting for code blocks and tables
- Download as a file or convert to HTML
Guide
Markdown is a lightweight markup language created by John Gruber in 2004. The idea was simple: let people write formatted text using plain characters that are easy to read even without rendering. A heading starts with hash marks. Bold text gets wrapped in double asterisks. Links use square brackets and parentheses. Lists use dashes or numbers. The syntax is so intuitive that most people can read raw Markdown and understand the structure without any training. This simplicity is why Markdown became the default writing format for software documentation, technical blogs, README files, wikis, and static site generators. WebRecast Markdown Editor gives you a split-screen workspace where you type raw Markdown on the left and see the rendered output on the right, updating in real time. Every keystroke is reflected immediately in the preview pane, so you never have to switch between editing and previewing modes. The editor supports GitHub Flavored Markdown (GFM), which extends standard Markdown with features that developers and technical writers use constantly: fenced code blocks with syntax highlighting hints, tables with alignment, task lists with checkboxes, strikethrough text, and auto-linked URLs. Let's walk through the Markdown syntax that covers the vast majority of use cases. Headings use hash marks. One hash gives you an H1, two hashes give you an H2, and so on up to H6. Most documents use H1 for the title, H2 for major sections, and H3 for subsections. Going deeper than H4 is rare and usually a sign that the document structure needs rethinking. Good heading structure matters for accessibility because screen readers use heading levels to let users navigate a document by section. It also matters for SEO because search engines use heading hierarchy to understand content structure. Paragraphs are separated by blank lines. A single line break within text does not create a new paragraph in standard Markdown. This catches new users by surprise. If you want a hard line break within a paragraph, end the line with two spaces before pressing Enter, or use a backslash followed by Enter in some Markdown flavors. This two-space trailing convention is invisible and easy to forget, so many writers prefer using blank lines for all separations. Bold text uses double asterisks: **bold text** renders as bold text. Italic uses single asterisks: *italic text* renders as italic text. You can combine them: ***bold and italic*** renders as bold and italic text. Strikethrough, a GFM extension, uses double tildes: ~~deleted text~~ renders with a line through it. These inline formatting options cover the vast majority of emphasis needs. Unlike word processors that offer dozens of formatting choices, Markdown keeps things focused on three levels of emphasis: italic for mild emphasis, bold for strong emphasis, and strikethrough for deprecated or removed content. Links follow the pattern [display text](URL). For example, [WebRecast](https://webrecast.com) creates a clickable link. If you want to add a title that appears on hover, add it in quotes after the URL: [WebRecast](https://webrecast.com "Visit WebRecast"). For documents with many links, reference-style links keep paragraphs clean. You place a reference marker like [WebRecast][1] in the text and define the URL elsewhere in the document: [1]: https://webrecast.com. Reference-style links are especially valuable in academic and technical writing where the same source is cited multiple times. Change the URL in one place, and every reference updates. Images use the same syntax as links but with an exclamation mark prefix: . The alt text is important for accessibility and SEO. It describes the image for screen readers and appears if the image fails to load. Write alt text that conveys the information or function of the image, not just its appearance. "Bar chart showing revenue growth from $1M to $5M over 2020-2025" is more useful than "chart image." Code can be inline or block-level. Inline code uses single backticks: `const x = 5` renders in a monospace font within the line. This is the standard way to reference variable names, function names, file paths, command names, and other code elements within prose. Code blocks use triple backticks on their own lines, with an optional language identifier for syntax highlighting hints: ```javascript function greet(name) { return `Hello, ${name}`; } ``` This renders as a formatted code block. The language identifier (javascript, python, html, css, bash, sql, json, yaml, etc.) tells renderers which syntax highlighting rules to apply. Always include the language identifier because colored syntax highlighting dramatically improves code readability. Tables use pipes and hyphens. The first row is the header, the second row contains separator hyphens (with optional colons for alignment), and subsequent rows are data: | Feature | Supported | |---------|----------| | Tables | Yes | | Lists | Yes | Colons on the left, right, or both sides of the separator hyphens control left, right, or center alignment respectively. Tables in Markdown are limited to simple grid structures. For complex tables with merged cells, row spans, or nested tables, HTML within the Markdown document is the fallback. Most Markdown renderers allow inline HTML for cases where Markdown syntax is insufficient. Unordered lists use dashes, asterisks, or plus signs at the start of each line. Ordered lists use numbers followed by periods. Nested lists are created by indenting with spaces (typically two or four spaces per level). Task lists, a GFM extension, use square brackets: - [ ] creates an unchecked box and - [x] creates a checked box. Task lists are widely used in GitHub issues and pull request descriptions to track completion of sub-tasks within a larger work item. Blockquotes use the greater-than symbol at the start of each line. They are commonly used for quoting external sources, highlighting important notes, or creating callout sections in documentation. Nested blockquotes (using multiple greater-than symbols) are possible but rarely needed. Many documentation sites use blockquotes with specific prefixes to create styled callout boxes for warnings, tips, and notes. Horizontal rules use three or more hyphens, asterisks, or underscores on their own line. They create visual section breaks in long documents. Use them sparingly because heading changes already signal section transitions. Now let's talk about practical applications in detail. README files are the front page of every GitHub repository. A well-structured README uses H1 for the project name, H2 sections for Installation, Usage, Configuration, and Contributing, code blocks for command examples, and a table for configuration options. Writing this in the Markdown editor lets you see exactly how it will render on GitHub before you commit it. A good README should answer four questions immediately: what does this project do, how do I install it, how do I use it, and how do I contribute. Badge images at the top (build status, test coverage, npm version, license) give visitors instant context about the project's health. Technical documentation benefits enormously from Markdown. Tools like MkDocs, Docusaurus, GitBook, and VuePress all consume Markdown files and generate documentation websites. Writing in the Markdown editor gives you live preview while you draft, and the resulting .md files slot directly into your documentation build pipeline. API documentation, user guides, architecture decision records, and runbooks all work well in Markdown. The format enforces a clean structure that prevents the visual clutter common in word processor documents. Blog posts for static site generators like Hugo, Jekyll, Gatsby, and Astro are written in Markdown with front matter (YAML metadata at the top of the file). Front matter defines the title, date, author, tags, description, and other metadata that the generator uses to build the page. The editor handles the Markdown body content, and you can add front matter manually at the top. Many technical bloggers write exclusively in Markdown because it keeps the focus on content and lets the static site generator handle design and layout. Note-taking in Markdown has become popular because the files are plain text, portable, and future-proof. Applications like Obsidian, Logseq, and Notable all use Markdown as their storage format. Obsidian has popularized bidirectional linking between Markdown notes using [[double bracket]] syntax. Practicing Markdown syntax in this editor builds the muscle memory that makes those tools more effective. Students who take lecture notes in Markdown can later search, link, and reorganize their notes using any Markdown-aware tool. Project management documentation often uses Markdown. GitHub and GitLab issues, pull request descriptions, and wiki pages all support Markdown. Writing clear issues with headings, code blocks, task lists, and screenshots in Markdown makes them easier to scan and act on. A bug report formatted with a Steps to Reproduce section (as an ordered list), an Expected vs. Actual section, and a code block showing the error message is far more useful than an unformatted wall of text. The editor includes a toolbar for common operations. Buttons for heading levels, bold, italic, link insertion, image insertion, code blocks, and lists let you insert the correct syntax without memorizing it. This is especially helpful when you are learning Markdown or when you need to insert a table and cannot remember the exact pipe-and-hyphen format. The toolbar reduces the learning curve without limiting what you can do, since you can always type Markdown syntax directly. Exporting options include downloading the raw Markdown as a .md file and copying the rendered output as HTML. The HTML export is useful when you need to paste formatted content into a CMS, email editor, or web page that accepts HTML. The generated HTML is clean and semantic, using proper heading tags, paragraph tags, and list elements. This HTML can serve as a starting point for web content, newsletters, or documentation that will be served outside a Markdown rendering pipeline. The editor saves your work to browser local storage automatically. If you accidentally close the tab or your browser crashes, your content is preserved. When you reopen the editor, your last session is restored. This auto-save feature means you can use the editor as a persistent writing workspace without worrying about losing your progress. For long writing sessions, this safety net prevents the frustration of losing work to an unexpected browser event. Performance remains smooth even with long documents. The real-time preview uses an efficient Markdown parser that processes incremental changes rather than re-rendering the entire document on every keystroke. Documents of 10,000 words or more render without noticeable lag. The preview pane scrolls in sync with the editor pane, so the section you are editing is always visible in both panels. Here are some workflow tips for different user types. For developers writing README files: structure your README with a clear hierarchy. Start with the project name and a one-sentence description. Follow with badges for build status, license, and version. Add Installation, Quick Start, Usage, Configuration, API Reference, Contributing, and License sections. Use code blocks for every command and code example. Include both the command and its expected output when demonstrating CLI tools. Test your README in the editor before pushing. For technical writers: use reference-style links to keep paragraphs readable. Use tables for feature comparisons and configuration options. Use admonition-style blockquotes for warnings and notes. Export to HTML when your CMS does not support native Markdown rendering. Maintain a style guide for your team that specifies heading levels, code block language identifiers, and link formats to ensure consistency across documents. For students and researchers: use Markdown for note-taking during lectures. Headings for topics, lists for key points, code blocks for formulas (or LaTeX if your renderer supports it). Export your notes as .md files and open them in any text editor on any device. When writing research papers, draft the content in Markdown and convert to the required format (Word, PDF, LaTeX) using Pandoc. For content marketers: draft blog posts in Markdown to focus on content structure without getting distracted by formatting tools. The heading hierarchy forces you to think about content organization. Export to HTML and paste into your CMS. Using Markdown for drafting also makes it easy to maintain a content archive in a version-controlled repository. The Markdown editor processes everything locally in your browser. Your documents are not uploaded to any server. The auto-saved content lives in your browser's local storage on your device. This makes it suitable for writing confidential documentation, internal notes, and draft content that should not exist on third-party servers. The Markdown ecosystem extends well beyond text editors. Markdown is used in communication tools (Slack, Discord, and Microsoft Teams all support Markdown formatting in messages), project management tools (Jira, Linear, and GitHub Issues use Markdown for descriptions), documentation platforms (Notion, Confluence, and GitBook accept Markdown input), and even email (some email clients support Markdown composition). Learning Markdown in this editor gives you a skill that transfers to dozens of other tools you likely already use. For writers transitioning from word processors to Markdown, the biggest adjustment is trusting the formatting to happen automatically. In Word or Google Docs, you select text and click a button to apply formatting. In Markdown, you type the formatting characters alongside the text. This feels slower at first, but it keeps your hands on the keyboard and eliminates the mouse-dependent formatting workflow. Most writers who switch to Markdown report that their overall writing speed increases after a few weeks because they spend less time formatting and more time writing. Keyboard shortcuts accelerate writing in the editor. Learning a few shortcuts makes the writing experience significantly faster. Ctrl+B (or Cmd+B on Mac) inserts bold markers. Ctrl+I inserts italic markers. Ctrl+K inserts a link template. These shortcuts follow the same conventions used in most text editors and word processors, so the muscle memory transfers. For heading insertion, the toolbar buttons are typically faster than typing hash marks manually, especially for deeper heading levels. A common mistake new Markdown users make is over-formatting their documents. Markdown's strength is its restraint. A document that uses every available formatting option (bold, italic, strikethrough, blockquotes, nested lists, and tables all in the same section) is harder to read than one that uses formatting sparingly. Bold should highlight key terms or important information. Italic should indicate emphasis or titles of works. Headings should create a logical hierarchy. The best Markdown documents use formatting purposefully, not decoratively. Another common issue is inconsistent syntax. Markdown allows multiple ways to express the same formatting. Both * and - create unordered list items. Both ** and __ create bold text. Both * and _ create italic text. Pick one convention and stick with it throughout a document. Most style guides recommend * for emphasis and - for lists. Consistency makes documents easier to read in raw form and avoids rendering inconsistencies across different Markdown processors. The relationship between Markdown and HTML is worth understanding. Markdown was designed to produce HTML output. Every Markdown element has a corresponding HTML element: # becomes h1, ** becomes strong, * becomes em, - list items become li inside ul, and so on. Most Markdown renderers also allow raw HTML within Markdown documents. This means you can use HTML tags for elements that Markdown does not support, like details/summary for collapsible sections, div elements with custom classes for styled blocks, or sup/sub for superscript and subscript text. The HTML is passed through to the rendered output alongside the converted Markdown elements. For teams working on documentation collaboratively, Markdown provides a significant advantage over word processor formats: it works with version control. A .md file is plain text, which means Git can track changes line by line, show diffs between versions, and merge contributions from multiple authors. Try doing that with a .docx file. Collaborative documentation workflows using Markdown and Git have become standard practice in software companies, and many non-technical organizations are adopting similar approaches for policy documents, style guides, and knowledge bases. Markdown's longevity is one of its strongest features. A .md file you write today will be readable 20 years from now in any text editor, because it is just plain text with lightweight formatting conventions. Word processor formats change, proprietary note-taking app formats disappear when companies shut down, but plain text is permanent. Writing in Markdown is an investment in portability and future-proofing. Your content will never be locked into a format that requires specific software to read.
Frequently asked questions
Can I add images?
Yes, you can link your images on the internet with standard Markdown syntax.
Is it hard to use?
No, it is a simple markup language; you can learn the basic rules from our help section.
Is this a free StackEdit or Dillinger alternative?
Yes! Live Markdown editing with side-by-side preview, just like StackEdit and Dillinger - no account, no cloud storage required.
