Markdoc is a shared Markdown editor that places the raw source and an editable rendered preview side by side in the same document, live for everyone who has it open. You can type in either surface — the Markdown source or the rich preview — and the other follows instantly, cursors included. The Product Hunt listing describes it as "a shared Markdown editor for people and their agents," which captures its two audiences: people who write and review Markdown, and the AI agents they bring into the document. Its stated purpose is straightforward: write Markdown together in real time, review with comments and suggestions, keep every version, and publish straight to a gist or a repository file. Access is free while the product is in preview, and a GitHub account is required to get started.
Markdown has become a common format for documentation, notes, READMEs and repository files, but the act of writing it has largely stayed a solitary, file-based job. Files typically live in gists and repositories, and review tends to happen after the writing is done, through commits and whatever commentary travels alongside them. Markdoc's framing — "Markdown, together" — positions the editor as the place where those activities converge instead of being scattered. Rather than writing in one tool, previewing in another, discussing changes in a third and publishing from a fourth, the product brings authoring, review, versioning and publishing into a single shared document on the web. The tagline "A shared Markdown editor for people and their agents" also signals a newer kind of collaborator: software agents can take part in the same document through MCP, so human and machine editing can happen against the same live text.
The first capability Markdoc highlights is its dual-surface editing model: "Two surfaces, one document." A code editor and a rich preview sit side by side, and you can type into either one. Type in the source and the rendered page updates; type in the rendered page and the source follows. The update is described as instant and includes cursors, so both surfaces stay visually in step. Because both views are driven by the same document, there is no need to switch tools to check how your Markdown will render — you see it as you write it. Real-time collaboration is layered on top: presence, live carets and selections, and conflict-free merging on both surfaces. That means multiple people can be in the same document at once, each seeing where the others are working, with concurrent edits merged rather than clobbering each other. The editor also works offline and catches up when you reconnect, so a dropped connection or a flight does not stop the writing.
Review in Markdoc happens inside the document. Comments are designed to stick: threads are anchored to text, and they follow the words as the document changes, so a comment stays attached to its subject even after paragraphs move or are rewritten. Threads can be replied to, resolved, and reopened, which supports a back-and-forth review that continues over time rather than a one-off note. Alongside comments, Suggesting mode lets a collaborator propose edits as tracked changes instead of editing the text directly. Owners — the people responsible for the document — can accept or reject each proposed change individually, or accept or reject all of them at once. Together these two features cover the familiar review loop: leave a note where something needs discussion, or make a concrete proposal that someone else decides on, without either side overwriting the other's work.
Version history gives the document a memory. Markdoc takes automatic snapshots while you work, so recent states are captured without anyone having to remember to save a copy. When a particular state matters, you can create a named version. Comparing versions is done with word-level diffs, and restoring is a one-click action. For storage, Markdoc 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. In other words, the document's home remains the place the file already lives — a gist or a repo — and publishing is not a copy-paste export but a commit. The Product Hunt description adds one more route in and out of the document: you can bring your own agent over MCP, letting an assistant work with the same Markdown file alongside the people in it.
The distinctive approach is that everything happens in one place, on one document, in real time. Editing, previewing, discussing and versioning are not separate stages handed off between tools; they are concurrent activities on the same live text. The two-surface design makes the source and its rendered output equal, editable views of that text, and the collaboration layer — presence, carets, conflict-free merging and offline catch-up — keeps every participant, including ones who were disconnected, on the same state. Comments anchored to text and tracked suggestions keep feedback attached to the exact words it concerns. Version snapshots and named versions record how the document evolved, while GitHub-native storage and publishing tie the working copy back to a gist or a repository through real commits. Agents participate through MCP, so they are not a separate chat window but another participant in the document.
The benefits follow from that consolidation. Because the preview is always beside the source and updates as you write, you can see how your Markdown renders without leaving the editor or opening a separate preview window. Because collaboration is real time with presence and conflict-free merging, several people can work on one file at once instead of taking turns or merging changes later by hand. Because comments anchor to text and suggestions are tracked, review feedback stays attached to what it refers to and nothing is silently overwritten. Because snapshots are automatic and restore is one click, experiments are less costly and earlier states are recoverable. And because publishing is a real commit to a gist or repository, the file you wrote stays in the place your team already looks for it.
Concrete workflows the content describes include writing Markdown alongside other people in the same document, with everyone's cursors and selections visible as they work. A reviewer can comment on a specific passage and hold a discussion in the thread, resolving and reopening it as needed, or switch to suggesting mode and propose edits as tracked changes that the document owner accepts or rejects. Teams can start from an existing Markdown file by opening it from a gist or a repository, work on it together in Markdoc, then publish back — creating a real commit on a chosen branch — when the document is ready. Someone can draft offline and let the editor catch up on reconnection. And a team that uses an agent can bring it into the document over MCP so it works on the same Markdown file as the people.
Markdoc is aimed at anyone who writes Markdown collaboratively — the Product Hunt topics list Productivity, Writing and Developer Tools, which matches a product that appeals both to writers who care about the rendered result and to developers who treat Markdown files as part of their repositories. The stated integrations are GitHub-specific: opening files from gists and repositories, publishing as commits to a branch, and the requirement of a GitHub account to get started. Agents integrate over MCP. Pricing is free while the product is in preview. No other technology stack details are stated in the provided content.
Markdoc's core promise is simple to state: Markdown, together. It puts source and preview side by side in one live document, lets people edit either surface at the same time, anchors comments and tracked suggestions to the text they concern, keeps automatic and named versions with word-level diffs and one-click restore, and publishes to a gist or repository as a real commit on the branch you choose. Agents can join over MCP. Free while in preview and requiring only a GitHub account, it offers a single shared place for writing, reviewing, versioning and shipping Markdown.