Comparison
DraftView vs the Docusaurus “Edit this page” Link
Docusaurus, VitePress, and MkDocs all ship an “Edit this page” link that points at GitHub's raw Markdown editor. It works for engineers, but most readers who spot a typo will never finish the fork-and-PR dance. Here's how that default link compares to pointing it at DraftView instead.
Feature Comparison
| Capability | DraftView | Default Edit Link |
|---|---|---|
| One-click edit from the docs page | ✓ | ✓ |
| Visual, rendered editing (no raw Markdown) | ✓ | ✗ |
| No Markdown knowledge required | ✓ | ✗ |
| Handles fork + branch + PR for the reader | ✓ | ◐ |
| Renders MDX, admonitions, and components | ✓ | ✗ |
| Resolves AsciiDoc includes across files | ✓ | ✗ |
| Reader can preview before submitting | ✓ | ✗ |
| Start editing before logging in | ✓ | ✗ |
| Opens a real GitHub PR on submit | ✓ | ✓ |
| Works with Docusaurus, VitePress, MkDocs, Hugo | ✓ | ✓ |
| Setup is a one-line editUrl change | ✓ | ✓ |
✓ = Full support ◐ = Partial support ✗ = Not supported
How They Compare in Practice
What the Default Link Does Today
Default edit link: Docusaurus builds the link from your editUrl config and sends the reader straight to GitHub's in-browser file editor. To contribute, the reader must already have a GitHub account, fork the repository, edit raw Markdown by hand, commit to a branch, and open a pull request. Each step sheds contributors.
DraftView: Point editUrl at https://draftview.app/edit?url=… and the same link opens the rendered page in a Google Docs-style editor. The reader edits what they see; DraftView handles the fork, branch, commit, and PR on submit.
The Drop-Off Problem
Default edit link: A reader who spots a typo and clicks “Edit this page” is met with a wall of raw Markdown and a fork prompt. Non-technical readers bounce immediately, and even engineers often abandon a one-character fix that costs five GitHub steps.
DraftView: The reader fixes the typo in place and clicks submit. The friction that kills drive-by contributions is gone, so more of the small corrections that keep docs accurate actually get made.
Rendering and Includes
Default edit link: GitHub's editor shows the raw source only. MDX components, admonitions, and AsciiDoc includes are opaque text, so a reader can easily break a component or edit the wrong fragment without realizing it.
DraftView: DraftView renders MDX, Markdown, and AsciiDoc the way the published page looks, and it resolves AsciiDoc includes so multi-file content is editable in context.
Setup
Swapping the link is a one-line change. See the Edit this page integration guide for Docusaurus, VitePress, and MkDocs snippets. The default GitHub behavior remains available for anyone who prefers it.
When the Default Link Is Fine
- Your entire audience is engineers comfortable with forks and pull requests
- Contributions almost always come with code changes reviewed in GitHub anyway
- You want zero third-party services in the contribution path
When to Switch to DraftView
- Non-technical readers, customers, or SMEs land on your docs and notice mistakes
- You want more drive-by typo fixes and small corrections to actually convert
- Your docs use MDX, admonitions, or AsciiDoc includes that confuse the raw editor
- You want every contribution to still arrive as a clean GitHub PR
Turn “Edit this page” into an editor anyone can use.
Point your docs site's edit link at DraftView. Readers edit the rendered page; DraftView forks the repo and opens the PR for them — no Markdown required.
See the integration guideOne-line editUrl change — works with Docusaurus, VitePress & MkDocs