MarkRight

Your documents shouldn't break when you switch tools.

Markdown spawned 44 flavors with no authoritative spec. Documents drift between tools, syntax shifts, formatting breaks. MarkRight ends that with one fixed spec, one canonical syntax, and zero extensions.

Try MarkRight

Why it matters

Every claim on this page maps to the formal spec (spec/markright-v1.right) and the reference parser test suite.

Markdown's original 2004 blog post is all the specification it ever got. Since then, 44+ incompatible flavors emerged, each adding features with different syntax. A document written for one tool often breaks in another.

MarkRight distills the best from all 44 Markdown flavors into one unambiguous, formally specified language. One way to do each thing. No inline HTML. No extension mechanism. No fragmentation.

Current state

The claims stay narrow, direct, and backed by the spec.

Flavors studied: 44 Markdown flavors analyzed and distilled into one fixed spec.
File format: .right files, or .md with syntax: markright front matter.
Parser: Reference parser in Rust. Two-phase: block scanning, then inline parsing.
Test suite: 1,593 fixtures across 28 categories verify every change.

Why it is different

The language makes a few clear promises and then holds them.

Spec

One fixed spec, no extensions

Every feature has exactly one syntax. No flavor variants, no extension mechanism, no fragmentation. The spec is fixed, so your documents stay portable.

Security

No inline HTML

Inline HTML is gone. The format is self-sufficient and eliminates the XSS attack surface that every Markdown renderer has to work around.

Tasks

8 task list states

Open, done, in progress, assigned, cancelled, blocked, deferred, and question. Fixed set: [ ], [x], [~], [@], [-], [!], [>], [?].

Bundles

Single file, directory, or .rightz zip

Documents can be one file, a directory bundle, or a packed .rightz archive. No build step, no external dependencies.

Admonitions

Prefix admonitions, not fenced divs

Notes, tips, warnings, important blocks, and cautions use N>, T>, W>, !>, and X> prefix syntax. Cleaner than fenced divs, unambiguous to parse.

Parser

Reference parser in Rust

Two-phase architecture: block scanning, then inline parsing. Zero runtime dependencies beyond serde for JSON output.

Embedded example

One preview surface, reused across routes.

The specimen below shows real MarkRight syntax rendered with the same preview system used in the editor. What you see is what the parser produces.

See it in action

Real MarkRight syntax, rendered live

This specimen shows actual MarkRight features: front matter, block IDs, admonitions, task states, and transclusion. What you see is what the parser produces.

Syntax

Everything the spec promises, in one example

Front matter, headings with block IDs, admonitions, task lists, and file transclusion.

MarkRight keeps semantic features in the language itself: admonitions, task states, block IDs, bundles, and citations are all part of the fixed spec.

right

---
title: My Document
syntax: markright
---

# Heading {#intro}

N> This is a note admonition.

- [ ] Open task
- [x] Done task
- [~] In progress
- [!] Blocked

![[chapter.right]]

Status

Where the parser and tooling stand today

Reference parser implemented in Rust.
Two-phase architecture: block scanning, then inline parsing.
Bundle format supports single files, directory bundles, and .rightz packed archives.

Fixture suite: 1,593 fixtures across 28 categories
HTML stance: Rejected inline HTML

Proof links

Verified references for claims on this page

Formal spec MarkRight repository

Boundaries

The language removes ambiguous features instead of carrying them along.

No inline HTML.
No extension mechanism.
No underscore emphasis.
No indented code blocks.
No alternate math delimiters.

Open the editor

Write MarkRight with live preview and syntax highlighting.

Open the workspace

See the planned local workspace path and when to use the editor instead.