Edit Any Markdown, MDX, or AsciiDoc File from GitHub in Your Browser

Every documentation site has the same button somewhere on the page. It usually says "Edit this page" or "Suggest changes". A reader clicks it, expecting to fix a typo or improve a paragraph. What happens next decides whether they actually contribute.

The default destination is GitHub's web file editor: a textarea with no preview, no formatting help, and a fork prompt for anyone who is not already a maintainer. For Markdown that pattern is rough. For MDX, where the file mixes prose with React components, it is hostile. For AsciiDoc, where one file pulls in others through include:: directives, it is effectively unusable.

DraftView's file editor replaces that flow. Open any file from any public GitHub repository, edit it in a real editor, and submit a pull request when you are ready. Reading and editing require no account. Sign-in only happens at submit time, and only so DraftView can fork the repo and open the PR on your behalf.

This post walks through everything the editor does, the two modes it ships with, and the use cases it unlocks.

Open Any File with One URL

The editor accepts any github.com/<owner>/<repo>/blob/<branch>/<path> URL. Both /blob/ and /edit/ links work, so you can paste either form. Supported file types are .md, .mdx, and .adoc.

The simplest way to open a file is to prepend the editor URL to the GitHub link:

https://draftview.app/edit?url=https://github.com/YOUR_ORG/YOUR_REPO/blob/main/docs/page.md

This is also the shape that documentation site frameworks (Docusaurus, VitePress, MkDocs, Starlight, Astro) expect for their "Edit this page" configuration. One config change wires up every page on your site. The integration guide at draftview.app/edit-this-page has copy-paste snippets for the major frameworks.

Two Modes: Visual and Source

The editor exposes two modes through a toggle in the top left. You can switch between them at any time without losing work.

Visual mode renders your document the way it will appear once published. Headings have heading styles, lists look like lists, code blocks are styled, and inline marks (bold, italic, links) behave the way they do in a word processor. For MDX, React components render as interactive cards in the editor: a <Tabs> block becomes a real tab bar; <Card> becomes a labeled container; <Steps> becomes a numbered list with editable steps.

Source mode is a full CodeMirror editor with syntax highlighting tuned for each format. It includes line numbers, the fold gutter, bracket matching, and the keyboard shortcuts you would expect from a serious code editor.

Most prose edits are faster in visual mode. Most structural edits (rewriting a JSX block, reordering tabs, fixing a code fence) are faster in source mode. Having both available means you do not have to commit to one philosophy.

Keyboard Shortcuts in Source Mode

The source editor ships with the shortcut set people expect from VS Code or a modern code editor. The full table:

Shortcut	What it does
Ctrl+B	Wrap selection in bold (format-aware: ** for Markdown/MDX, * for AsciiDoc)
Ctrl+I	Wrap selection in italic (format-aware: * for Markdown/MDX, _ for AsciiDoc)
Ctrl+Z, Ctrl+Y, Ctrl+Shift+Z	Undo and redo
Ctrl+F	Open the find panel
Ctrl+H	Open find and replace
Ctrl+D	Select the next occurrence of the current selection
Ctrl+/	Toggle line comment (Markdown and MDX)
Ctrl+Space	Trigger autocomplete
Tab	Indent, or accept an open autocomplete suggestion
Shift+Tab	Unindent
Esc	Close find panel or autocomplete
Alt+↑, Alt+↓	Move the current line up or down
Ctrl+Shift+K	Delete the current line
Ctrl+Enter	Insert a blank line
Ctrl+[, Ctrl+]	Indent less, indent more
Alt+Click	Add another cursor

The find panel themes itself to match the rest of DraftView, with match-case, regex, and whole-word toggles.

Bracket matching, automatic closing of paired characters ((), [], {}, quotes), and highlighting of every occurrence of the selected word are on by default. Multi-cursor editing through Alt+Click makes batch renames trivial.

AsciiDoc Without a Local Toolchain

AsciiDoc is the format that suffers most from "Edit this page" buttons that send you to GitHub. A real AsciiDoc file pulls in fragments through include:: directives. Editing one part of a topic often means editing five included files at once. Locally, that requires Asciidoctor and a build pipeline.

DraftView's editor resolves include:: directives automatically. When you open an AsciiDoc file, the editor fetches every included file in the background and exposes them in a sidebar. You can navigate between them, edit each one, and submit the combined changes as a single pull request. There is no Asciidoctor install, no Ruby runtime, no local clone required.

This is why a contributor on a phone, a borrowed laptop, or a locked-down work machine can still fix a typo in production AsciiDoc documentation (the kind that ships with Red Hat OpenShift, for example). The browser is enough.

MDX with React Components

MDX is the inverse problem. The file is mostly prose, but the prose is interrupted by JSX expressions and custom components. Editing MDX in a raw textarea means you can break a component's syntax without realizing it until the build fails.

The visual editor recognizes the common documentation components from Docusaurus, Starlight, Nextra, Fumadocs, and Mintlify, then renders them as interactive blocks. Tab labels come from the source attributes (label, value, or the parent's values array). Card titles, step numbers, and accordion headers all stay editable. The JSX import statements and frontmatter sit at the top, dimmed, so you know they are there without having to scroll past them.

If you want to edit a component's props or rewrite a JSX block, flip to source mode. The syntax highlighter colors imports, JSX tags, attribute values, and embedded code fences differently, so you can scan the structure at a glance.

Use Cases by Persona

Documentation site owners swap out their "Edit this page" link for a DraftView URL. Their existing repository stays the single source of truth. Contributions arrive as native GitHub pull requests they already know how to review.

Technical writers fix typos and rewrite paragraphs from any browser, on any device. No clone, no IDE, no build environment. For larger rewrites, they use visual mode for the prose and flip to source mode when they need to touch JSX or front matter directly.

Subject matter experts and external contributors can edit documentation without learning Markdown, MDX, or AsciiDoc syntax. They write in visual mode the same way they would in Google Docs. The DraftView app handles the conversion to source on submit.

Developers who prefer source-first editing get a full CodeMirror experience with the shortcuts they already know. Find and replace, multi-cursor, code folding, autocomplete, and bracket matching are all there. The only thing missing compared to a local editor is the project context, and that rarely matters for documentation edits.

Drive-by contributors (the people who notice a broken sentence in your docs while reading them) get the lowest-friction path from "I spotted a typo" to "here is a PR". No account is required to read or edit. The sign-in step happens exactly once, at submit time.

Free, with No CMS to Maintain

Reading and editing are always free. Sign-in is only required at submit time, and DraftView's GitHub OAuth scope is the minimum needed to fork the repository and open the pull request. Your repo stays the single source of truth. There is no parallel CMS, no separate database of edits, and no risk of content drift.

Public repositories are free forever. The full editor, the visual and source modes, the AsciiDoc include resolution, and the MDX component rendering all work without a paid plan.