Marked 3: the Markdown previewer for people who already have an editor

Most writing applications want to own the text and the rendered result. Marked takes the opposite position. Keep writing in the editor you already chose. Marked watches the file, renders it in a separate window and adds the proofreading, navigation and export tools that plain text deliberately leaves out.

That separation is the product. It works with a minimal editor, a large book project, an Obsidian vault or a folder changed by scripts. The source remains an ordinary file. Closing Marked does not make the document less accessible.

The harder question is fidelity. Markdown is not one language, and a modern publishing site may add MDX components, framework imports, custom remark plugins and styling that a general previewer cannot reproduce. Marked can get surprisingly close through processors and CSS. It should not be confused with the production build.

This article began as a review of Marked 2. Marked 3 is now the current product, so pretending version 2 is still the buying decision would mislead the reader. The review keeps the same question and applies it to the version someone can actually buy.

A previewer without an editor is a useful constraint

Marked does not ask writers to migrate. Open the same Markdown file in Marked and a preferred editor, save, and the rendered view updates. This keeps editing tools replaceable. Vim, VS Code, Obsidian, BBEdit, Scrivener and a small text editor can each supply the source.

I like this model because it respects the file. A writer can select an editor for manipulation and Marked for reading. Those are different activities. The best interface for changing headings quickly is not necessarily the best one for judging whether the finished page flows.

The cost is another window and another application. If an editor already provides an accurate, styled preview and adequate export, Marked can duplicate it. The product earns its place when the independent view catches problems the editing environment hides or when several editors need one consistent renderer.

Save-driven updates also create a useful rhythm. The preview changes when the source reaches disk, not on every unfinished keystroke. Automatic save can make that nearly live. Manual save turns the refresh into a small checkpoint.

Markdown dialects are the real compatibility problem

CommonMark, GitHub Flavoured Markdown, MultiMarkdown, Kramdown and application-specific extensions disagree on details. Tables, footnotes, line breaks, task lists, metadata and fenced content can render differently while each tool claims Markdown support.

Related reading

Marked 3 includes several processors and can switch between them. The current feature list names CommonMark with GFM extensions, Kramdown, MultiMarkdown and Discount among the supported choices. This is more than a checkbox because it lets the preview move closer to the target platform.

The correct processor is the one that matches publication, not the one that makes the sample document look nicest. Create a compatibility file containing every syntax feature the site uses, then render it in Marked and in production. Compare headings, IDs, links, code, footnotes, tables and raw HTML.

MDX is a larger boundary. Imports, JSX components and runtime data are not ordinary Markdown. A generic previewer may show, ignore or fail on those elements unless a custom transformation removes or replaces them. The source can still be useful in Marked, but exact page parity requires the real MDX toolchain.

Custom processors are the bridge to a real workflow

Marked can run pre-processors and custom processors. Version 3 expands this with Custom Rules that can transform source, select processors and invoke commands. This is the feature that moves it from a nice reader to publishing infrastructure.

A custom path can strip frontmatter, resolve includes, convert an internal syntax or call the same Markdown processor used elsewhere. The output then receives Marked’s styles and tools. For a static site, this can close much of the gap between generic Markdown and the actual content model.

It also creates code that needs ownership. A processor can fail after a runtime update, depend on a path that exists on one Mac or execute a tool with access to the document. Keep scripts in version control, pin dependencies where possible and return errors visibly. Silent fallback to a different renderer is dangerous because the preview still looks plausible.

The direct version and Mac App Store version have different sandbox boundaries. Marked’s official FAQ explains that the App Store edition may be unable to execute some binary custom processors. Anyone buying primarily for toolchain integration should validate that path during the trial and choose the distribution accordingly.

Preview fidelity has to be treated as a diff

A preview is not correct because it looks similar. It is correct enough when every difference from the target is understood. Fonts and spacing may be deliberate approximations. A missing code block, changed link or unsupported component is semantic.

Build a small reference corpus from real articles. Include ordinary prose, the longest post, images, captions, tables, code highlighting, footnotes, callouts and malformed input. Render through Marked and the production build. Compare the DOM when possible, then inspect screenshots for styling differences.

Record mismatches in three categories: accepted preview differences, processor configuration gaps and defects that could hide a publishing problem. Repeat after changes to the site pipeline. The document that passed last year may not exercise a new plugin.

I would never remove the final local build from a publishing checklist because Marked looks right. The preview shortens feedback while writing. The build verifies the artefact that will ship.

Refresh speed matters more than launch speed

Marked stays open beside the editor, so cold launch is rarely the important number. The relevant delay begins with saving and ends when the changed paragraph appears. If that gap becomes noticeable, the writer stops using the rendered view as part of the thought process.

Document size is only one variable. Includes, syntax highlighting, diagrams, external processors and image changes may dominate the refresh. A 20,000-word plain document can be easier than a short technical article that launches several tools.

Test at realistic sizes with the actual processor. Record the screen at a known frame rate, change a visible token, save and count frames until the preview settles. Repeat after a cold processor start and several warm runs. Report both instead of selecting the fastest result.

If the preview grows slow, profile the custom path before blaming Marked. A script that installs dependencies, scans a repository or performs network requests on every save will destroy the feedback loop. Preview processing should be local, deterministic and narrowly scoped.

Styles are more than themes

Marked includes built-in preview styles and accepts custom CSS. A style can reproduce the width, typography, code colours and spacing of a website closely enough to reveal editorial problems before publication.

This matters because line length and type size change reading. A paragraph that appears concise in a wide editor may become a wall of text in the narrow article column. Heading wraps, table overflow and image captions are easier to judge in the intended geometry.

Related reading

Marked 3 adds style management, a generator and a tool for adapting readable website styles. I would still begin from a small hand-maintained stylesheet based on the site’s design tokens. Automatically captured CSS can carry irrelevant rules and fragile selectors.

Custom styles should have a version and a simple test page. When the public site changes, update the preview intentionally. A stale imitation is worse than a neutral theme because it claims visual authority it no longer has.

Proofreading tools work best as signals

Marked analyses spelling, grammar, repeated words, sentence complexity and readability. It can highlight overused terms and provide counts for a selection or whole document. These checks are valuable because they appear in the reading view rather than inside the editor’s writing chrome.

Readability scores are heuristics. Technical names, short headings and code can distort them. A lower grade level is not automatically better, and varied prose is not produced by mechanically shortening every sentence.

I use this class of tool to locate suspicious areas. A cluster of long sentences deserves a reread. Repetition may be accidental or it may be the precise term the article requires. The author makes the decision.

Custom keyword lists are more useful than generic style commandments. Add filler phrases, internal terminology that should not be public and product-name variants that are often mistyped. The check then reflects the publication instead of an abstract idea of good prose.

Reading time is a convention, not a measurement

Marked reports word count and estimated reading time. The calculation is words divided by an assumed reading speed. At 200 words per minute, a 2,400-word article takes twelve minutes. At 250, it takes 9.6. Both are mathematically correct and neither predicts an individual reader.

The word count can also differ between tools. Frontmatter, code, captions, footnotes and embedded components may be included or excluded. A site that shows reading time should define its own counting rules and apply them in the production pipeline.

Use Marked’s number as an editorial indicator. If it says two minutes when the brief called for a substantial guide, the draft is probably thin. Do not adjust paragraphs merely to reach an exact badge.

For this review series, I care about whether an article has room to explain the buying decision, not whether one algorithm displays twelve. Images, code and tables change pace in ways a word count cannot see.

Link validation is helpful but incomplete

Marked can inspect links from the document. This catches typographical errors and obvious dead destinations before publication. For a large archive, even a partial check saves embarrassing failures.

The Marked 2 FAQ notes that validation uses a basic HEAD request and may report Unknown when a server responds differently. Authentication, redirects, rate limits and sites that reject automated requests complicate the result. A non-error is also not proof that the page contains the intended information.

Treat validation as triage. Fix clear malformed URLs and 404 responses, review unknown results manually and check important sources in a browser. Internal relative links should be verified by the site build because only the router knows their final destination.

Network checks should not run on every save. They slow the preview and may send requests to private or draft URLs unnecessarily. Run them as a deliberate pre-publication step.

Export is useful when the recipient does not want Markdown

Marked 3 exports PDF, HTML, DOCX, EPUB and other formats, depending on configuration. Export profiles let repeated settings travel together. This is useful for reports, manuscripts and review copies that begin as plain text but must leave as a conventional document.

Every format has a fidelity boundary. PDF preserves visual layout but not flexible structure. DOCX introduces another style system. HTML can remain close to the preview but may need embedded assets for portability. EPUB adds reader-controlled presentation and stricter packaging.

Create one torture document and inspect every format you intend to send. Check page breaks, headings, code, tables, images, links and metadata. Open the result in the recipient’s actual application, not only in Quick Look.

Related reading

The source remains Markdown, which is the important part. Export should be reproducible output, not the new master copy. If collaborators edit the DOCX, define how their changes return. Marked 3’s change-tracking conversion can help, but the round trip still deserves a rehearsal.

Marked 3 changes the purchase decision

One more cost belongs in the comparison: configuration time. A custom processor and stylesheet can make Marked match a publication closely, but they also need maintenance when the site changes. Save both beside the writing project and test them with the same fixture used for export. The permanent licence is easiest to justify when that configuration serves many documents rather than one article.

The current Marked 3 site lists macOS 11 or newer and offers a trial. Pricing is $2.99 per month, with a permanent unlock currently shown at $69.99 as an introductory price. A separate Marked 3 Pro listing offers the same application as a $69.99 one-time purchase for enterprise licensing and Marked 2 upgrades. Confirm the current pricing before buying.

I prefer the permanent licence for a local writing utility, assuming the application proves useful. A subscription may make sense as a low-cost extended evaluation, but previewing local files is not a service that naturally requires monthly access.

Marked 2 owners need to evaluate the upgrade rather than an entirely new category. Version 3 adds CommonMark and Kramdown processors, stronger custom rules, improved DOCX and EPUB handling, wiki navigation, Obsidian callouts and other substantial changes. If version 2 already matches a stable pipeline, the upgrade is optional. If compatibility or export is the pain point, version 3 addresses the right areas.

Verdict

Marked 3 is a specialist tool for writers who want to keep their editor and their files. Its live rendered view, styles, document analysis and exports provide a reading and publishing surface without turning Markdown into an application database.

The limitation is fundamental rather than accidental. A general previewer cannot automatically reproduce every modern site pipeline, especially MDX with live components. Custom processors can narrow the difference, but the production build remains the final authority.

I would recommend Marked to long-form writers, technical authors and anyone producing several output formats from plain text. Start with the hardest real article, connect the actual processor, compare the result with production and test the export a recipient needs. If the second window stays open because it catches problems early, the permanent licence is defensible. If the editor’s built-in preview already predicts publication accurately, keep the simpler workflow.