Markdoc

Markdoc is a shared editor for Markdown that places a code editor and a rich preview side by side inside a single document. You can type in either surface and the other follows instantly, cursors included, live for everyone in the document. Its purpose is to make Markdown a genuinely collaborative format, where writing, reviewing and publishing all happen in the same place. It is built for people who already work in Markdown and want the presence, comments and version history they expect from modern document tools — writers, developers and teams whose files live in GitHub. Markdown is one of the most durable writing formats there is: plain text, easy to diff, easy to store in Git. Its tooling, however, has traditionally been solitary. Collaborative work in Markdown usually means copying text out into another tool for review, leaving feedback in a separate chat thread or issue, and losing any clean record of who changed what and when. Markdoc addresses that gap by treating a Markdown file as a live, shared document rather than a static blob of text. Collaboration happens on the document itself, comments stay attached to the words they were written about, and versions are captured automatically, so the file remains the single source of truth from first draft through to publication. The core of the product is its two-surface editing model. A code editor and a rich preview sit side by side, and typing in either one updates the other instantly, cursors included. That means a writer can work in the rendered view while a developer works in the source, and both see the same document change in front of them in real time. Real-time collaboration runs across both surfaces, with presence indicators, live carets and selections, and conflict-free merging, so simultaneous edits do not overwrite one another. The editor also works offline and catches up when you reconnect, which keeps writing uninterrupted on an unreliable connection, a plane, or anywhere the network drops out mid-sentence. Review is handled by two complementary features. Comments anchor to specific text and follow those words as the document changes, so a thread stays where it was written even after paragraphs move or text is rewritten; threads can be replied to, resolved and reopened. Suggesting mode turns edits into tracked changes rather than direct modifications: a contributor proposes an edit, and the document owner accepts or rejects each suggestion individually or all at once. Together these give a Markdown file the same review mechanics as a collaborative word processor, without giving up the plain-text format underneath — the source is still the source, it simply now carries a conversation and a decision trail with it. Version history and GitHub-native storage close the loop. Markdoc takes automatic snapshots while you work and lets you name versions when it matters, with word-level diffs and one-click restore, so a bad edit is always recoverable and a good state can be pinned deliberately. Storage is GitHub-native: you can open any Markdown file from a gist or a repository, and publishing creates a real commit on the branch you choose. Markdoc also supports bringing your own agent over MCP, so an AI agent can take part in the same document as a collaborator, and you can publish straight to a gist or a repository file once the work is ready. How the product works overall is defined by keeping everyone on the same document. Both surfaces are backed by the same content, and edits from either side are merged conflict-free, including edits made while offline. Because the underlying file lives in GitHub, publishing is not an export step but a commit: the document you have been editing becomes a change on a branch. That single-threaded approach — one document, two views, one storage backend — removes the copy-paste-and-reconcile cycle that normally sits between writing Markdown and getting it into a repository. The benefits follow directly from that design. Teams stop losing review context because comments travel with the text they annotate, and they stop overwriting each other because merging is conflict-free across both surfaces. Suggestion mode lets an owner keep control of a document without rejecting help outright, since every proposed change can be judged one at a time. Word-level diffs and named versions make it safe to edit freely, knowing any state can be restored in one click. And because publishing is a real commit to a branch, the path from draft to repository is short — no manual formatting pass, no export-and-paste step, and no divergence between what was reviewed and what was shipped. Concrete use cases follow the way Markdown is already used. A team maintaining a README or project documentation can open the file from the repository, discuss changes in anchored comment threads, and accept suggested edits before publishing a commit to the chosen branch. A technical writer and an engineer can co-edit a specification, one working in the source and the other in the preview, seeing each other's cursors as the document evolves. A blogger or newsletter author can draft in Markdown, review with a colleague using comments and tracked suggestions, keep a named version at each milestone, and publish to a gist. Anyone working with an AI agent over MCP can have the agent draft or revise content inside the same document that humans are reviewing, keeping the agent and the people on one shared copy rather than trading files. Markdoc runs on the web and requires a GitHub account. Its integrations are GitHub-centric: gists and repository files for opening and publishing, and MCP for bringing your own agent into the document. The product is priced as free while in preview, with a GitHub account required to get started. Beyond Markdown, GitHub and the two editing surfaces, no further stack details are stated in the available content. For anyone who writes in Markdown and needs other people — or agents — in the document, Markdoc combines live two-surface editing, threaded comments, tracked suggestions, automatic version history and GitHub-native publishing in a single shared editor. The takeaway is simple: Markdown stops being a file you pass around and becomes a document you work on together.