Markdown Preview
Type markdown on one side and read it rendered on the other. Drop .md files to read several as one continuous document.
How it works
Type or paste markdown into the Write pane. It re-parses on every keystroke with marked, and the HTML passes through DOMPurify before it reaches the page.
Drop one or several .md / .markdown files onto the Write pane, or press ⌘O (Ctrl+O) to browse. Each file becomes a document you can edit in place.
Reorder documents with the arrow buttons, or drag a row by its handle on a mouse. The order in the rail is the order they render in.
Select a document to load it into the editor and jump the preview to its section. Removing the last one leaves an empty scratch document rather than an empty tool.
Read everything as one continuous document in the Preview pane. Word count and reading time sit in the header, and the hairline under it tracks how far the preview has scrolled.
The render pipeline
Markdown is parsed to HTML by marked, and that HTML is sanitised by DOMPurify before it is inserted. Sanitising is not optional here: markdown permits raw inline HTML, so a document can carry a script tag or an onerror attribute, and rendering it unfiltered would execute that code on this origin with this origin's storage in scope. The allow-list is widened by exactly two things — the input element, and its type, checked and disabled attributes — which is what lets GFM task lists render as checkboxes instead of being stripped.
markdown → marked.parse → DOMPurify.sanitize → innerHTML
Use cases
Check a README before pushing
Paste README.md and confirm the headings, the fenced code blocks and the tables land the way you meant, without the commit-refresh-amend loop.
Read a docs folder as one document
Drop every .md in the folder at once, order them in the rail, and scroll the set as a single continuous read instead of opening one tab per file.
Draft without a build step
Write the piece in the left pane and watch the right one. No dev server, no hot reload, no framework — the parse happens in the tab as you type.
Verify GFM task lists and tables
Two constructs that differ most between renderers. Task lists come through as real disabled checkboxes and pipe tables as bordered tables, so you can see which of your dashes and pipes the parser actually accepted.
Inspect markdown a model produced
Model output is markdown with the fences and the escaping already applied. Pasting it here shows what a renderer will do with it before it goes anywhere that renders it for other people.
Read a spec without the site around it
Save the .md, drop it in, and read the prose on its own — no navigation, no comment rail, no cookie banner over the fold.
Compare two drafts
Load both files, select one to edit and let the other stay rendered beneath it in the preview. They stay in the same scroll container, so the comparison is a scroll rather than a tab switch.
Questions
- Do the files leave my device?
- No. Files are read with the browser FileReader API, parsed by marked and sanitised by DOMPurify, all in this tab. There is no upload endpoint and no request is made.
- What markdown flavour is supported?
- GitHub Flavored Markdown, which is marked's default: headings, lists, tables, fenced code, task lists, links, blockquotes, images, strikethrough, and inline HTML.
- Is inline HTML allowed?
- Yes, after sanitising. DOMPurify keeps structural markup and strips what can execute — script and style elements, on* handlers, javascript: URLs. A document is rendered, never run.
- Can I export the rendered output?
- Copy HTML puts the sanitised HTML of every document on the clipboard, in rail order. There is no PDF export: printing this page would carry the site header and footer into the file, which is not what anyone printing a document wants.
- Is there syntax highlighting in code blocks?
- No. Fenced blocks get a monospace face, padding, a border and horizontal scroll, and the language tag is preserved in the class. Per-language token colouring means shipping a grammar set to every visitor, and this page renders one theme in greys.
- Why is there only one theme?
- Because a reading theme that disagrees with the site around it reads as a different website. The /writing section here shipped a cream paper theme once and it was deleted for the same reason. The preview uses the site palette, which means it tracks the palette rather than drifting from it.
- Why render several files as one document?
- Most real markdown reading is multi-file — chapters, a docs tree, a set of drafts. One scroll container over the set beats N tabs, and the word count and reading time then describe the whole thing rather than a fragment of it.
More tools
One of 18 free tools here. They come out of building utility apps for macOS, iOS and the browser — all of it by one person.
See the apps