Home

One unambiguous markup language for documents that should not drift.

MarkRight distills the best from 44 Markdown flavors into one unambiguous, formally specified language designed for the AI era.

Source context

This page stays grounded in README.md and spec/markright-v1.right so product framing and syntax proof stay aligned.

Markdown never gained an authoritative specification, so documents move across tools with syntax that shifts underneath them.

MarkRight keeps one canonical path: a fixed spec, no extensions, and no flavor fragmentation.

Current state

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

Format: .right is canonical, or .md with syntax: markright front matter.
Bundle: A document can be a single file, a directory bundle, or a .rightz zip.
Parser: Reference parser implemented in Rust with block scanning, then inline parsing.
Verification: 1,593 fixtures across 28 categories verify the language on every change.

Why it is different

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

Spec

Fixed spec, no extensions

One way to do each thing keeps MarkRight from repeating the fragmentation that spread across Markdown flavors.

Security

No inline HTML

Inline HTML is excluded from the language so the format stays self-sufficient and removes that XSS attack surface.

Tasks

8 task list states

The state set is fixed: [ ], [x], [~], [@], [-], [!], [>], and [?].

Bundles

Single file, directory, or .rightz zip

The bundle model stays compact: single file, directory, or .rightz zip, without adding a second content model.

Admonitions

Prefix admonitions, not fenced warning cards

Notes, tips, warnings, important blocks, and cautions use N>, T>, W>, !>, and X> prefix syntax.

Parser

Reference parser implemented in Rust

Today the parser uses a two-phase architecture: block scanning, then inline parsing, with zero runtime dependencies beyond serde for JSON output.

Embedded example

One preview surface, reused instead of restyled into marketing chrome.

The example below uses the shared preview foundation from Task 5. It keeps the landing page honest by showing a real syntax specimen instead of decorative panels.

It also keeps later routes aligned because the same renderer can carry this language into the editor and workspace without a second composition system.

Quick look

A small specimen from the fixed spec

The embedded example uses the shared preview foundation so the landing page shows real syntax without inventing a second renderer.

Syntax

One syntax surface with explicit constraints

The example stays close to the README quick look while calling out the parts this landing page promises.

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

Parser and bundle model already have concrete shape

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

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 like \(...\).

Open the editor route

Author with the shared preview foundation already in place.

Open the workspace route

Keep files, bundles, and future review flows in the same shell.