# Vditor 4.0.0: A Browser Markdown Editor With Three Editing Modes
> Vditor is an MIT-licensed TypeScript Markdown editor for embedding in web apps, offering WYSIWYG, Typora-like instant rendering and split view. The mode you pick changes what your users can do, and that is the real decision.
**Vanessa219/vditor** — ♏ 一款浏览器端的 Markdown 编辑器，支持所见即所得（富文本）、即时渲染（类似 Typora）和分屏预览模式。An In-browser Markdown editor, support WYSIWYG (Rich Text), Instant Rendering (Typora-like) and Split View modes.
- Repository: https://github.com/Vanessa219/vditor
- Website: https://b3log.org/vditor
- Stars: 11,354 · Forks: 1,090
- Language: TypeScript
- License: MIT
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/vanessa219-vditor
## What Vditor Solves That Split-Pane Editors Do Not
The README opens with a gap analysis rather than a feature list. Most embeddable Markdown editors, it argues, either only offer split preview, where the editing area and the preview area are separate, or offer WYSIWYG without full Markdown syntax support. Typora-style instant rendering, where the syntax you type resolves into formatted output in place, is described as almost absent from embeddable editors. Vditor's answer is to ship all three modes in one component and let the integrator choose.
The audience is therefore not end users looking for a writing app. It is developers embedding an editor into a forum, a blog backend, a CMS or a note-taking product. The README's own case list points that way: Symphony, a Java community platform, Solo and Pipe as blog nodes, Tditor as an online Markdown platform, and Arya as an online editor built on Vue. Each of those needs the editor as a dependency, not as a destination.
The three modes map to three user populations. Split view (sv) suits people who already write Markdown and want the source visible. WYSIWYG suits people who do not know Markdown and should never see the syntax. Instant rendering (ir) suits people who know Markdown but want the formatting to resolve as they type. If your product has only one kind of user, the multi-mode design buys you less than it costs in configuration surface.
## How the Editor, the Parser and the Themes Fit Together
Vditor is a browser-side component. The package's only runtime dependency listed in package.json is diff-match-patch, which suggests the editor computes text differences in the browser rather than sending every keystroke to a server. Everything else in the dependency list is build tooling: webpack, ts-loader, less-loader, jest, puppeteer, eslint, prettier.
The rendering pipeline is layered. The editor layer handles input and mode switching. Below it, Markdown parsing follows CommonMark and GFM, and the README states the project implements both specifications, with formatting and syntax tree inspection available. Above the parser sits a theme system with three separate axes: editor themes (classic and dark built in), content themes (ant-design, light, dark, wechat), and code themes (github plus others, 36 in total). Content themes apply to the HTML that Markdown produces, and the README is explicit that this requires the class vditor-reset on the display element. That class is the contract between the editor and any page that renders Vditor output outside the editor itself.
Heavy syntax features are delegated rather than implemented. Mermaid covers flowcharts, sequence diagrams and Gantt charts. Graphviz and PlantUML handle UML. WaveDrom draws digital waveforms. ECharts covers line charts, pie charts and mind maps. abc.js handles staff notation. MathJax and KaTeX both back math formulas. This is a wide feature surface, but it is also a wide set of third-party renderers that your bundle may have to carry, and the README describes most of these as switchable, which implies you should disable what you do not use.
## Installing Vditor and Rendering Your First Editor
The README gives two installation paths. The npm path is for projects with a bundler. The script tag path is for pages that load Vditor from a CDN.
For the npm route, install the package and save it as a dependency:
```bash
npm install vditor --save
```
Then import the class and the stylesheet, and instantiate it against a container element. The README's own snippet names the container argument as id and passes an options object:
```ts
import Vditor from 'vditor'
import "~vditor/src/assets/less/index"
const vditor = new Vditor(id, {options...})
```
The stylesheet import path is worth pausing on. It points into src/assets/less, and the README separately notes that theme colors can be customized by editing variables in index.less. Projects that only want the built CSS should check what the dist folder exposes, because the README's npm example uses the source Less path while the HTML example uses dist/index.css.
For the script tag route, add the stylesheet and the minified bundle. The README carries a warning that production environments should pin a version number:
```html
```
What you should see after either path is an editor mounted inside your container element, with a toolbar. The README states the toolbar contains more than 36 operations, and that each item's shortcut key, tooltip, tooltip position, icon, click event, class name and sub-toolbar can be customized. The README points to demo/index.js for the CommonJS editor example and demo/render.js for rendering without an editor.
## The Mode You Choose Is a Commitment, Not a Setting
Switching between wysiwyg, ir and sv is presented as a feature, but each mode changes what your users can do and what you must support. In split view the Markdown source is always visible, so a user who types a construct the parser mishandles can see the raw text and correct it. In WYSIWYG the syntax is hidden, so a misparse becomes a visible formatting error with no obvious cause. Instant rendering sits between the two and inherits some of both problems.
The README's own framing acknowledges the tension. It describes WYSIWYG as friendly to users unfamiliar with Markdown and usable by those who know it, and instant rendering as theoretically the most elegant way to edit Markdown. Elegant is not the same as predictable. If your product's users paste content from word processors or other web pages, the paste path matters more than the mode, and the README states that pasted HTML is converted to Markdown, with external images optionally uploaded through a specified interface.
There is also a Chinese-language optimization layer that is on by default in the sense that it is listed as a feature: inserting spaces between Chinese and Western text, correcting term spelling, and replacing ASCII commas and periods after Chinese characters with their full-width equivalents. For a product with mixed-language content this is helpful. For a product where users type code or exact strings inside prose, it is a behavior you need to know exists before a user reports that their punctuation changed.
## What Vditor Does Not Do
Vditor is a browser component, and the README does not describe a server-side renderer, a CLI, a desktop application or a headless conversion mode. If you need to render Markdown to HTML on a server, in a build step or in a static site generator, this package is the wrong layer. The render entry point in the demo folder runs in the browser.
Bundle weight is a real constraint, and the README does not resolve it. The feature list includes Mermaid, Graphviz, PlantUML, WaveDrom, ECharts, abc.js, MathJax and KaTeX. The README says most of these can be toggled through configuration, which means the default configuration is likely not the configuration you want in production. The package.json files field ships dist, a few source TypeScript files and the assets directory, so what ends up in your bundle depends on how you import it.
The upload feature is described by capability, not by contract. The README states that drag-and-drop and clipboard paste uploads are supported, that real-time progress is shown, and that CORS cross-origin upload works. It does not, in the excerpt available, specify the response format your endpoint must return. That is the kind of detail you discover by reading the source or the demo, not by reading the feature list.
Finally, the content theme system requires cooperation from the rest of your page. Any element rendering Vditor-produced HTML needs the vditor-reset class. If your application already has its own typography styles, you are now maintaining two style systems that both target the same elements.
## Vditor Against Milkdown and Other Embeddable Editors
The related searches for this project include Milkdown, and the comparison is instructive because the two projects start from opposite ends. Vditor is a complete editor component: it brings its own toolbar, its own theme axes, its own mode switcher and its own set of bundled diagram renderers. You mount it and configure it.
Milkdown, by contrast, is built as a plugin-based editor framework around ProseMirror. The difference in approach is where the decisions live. With Vditor, the decision is which of the three modes and which of the many toggles you enable. With a plugin-based editor, the decision is which plugins you compose, and you are expected to assemble more of the behavior yourself.
That makes Vditor the faster path when you want a Markdown editor that behaves like a product out of the box, and a plugin framework the better path when you need the editor's internal document model to be extensible in ways the component does not anticipate. Vditor's extension points, per the README, are the toolbar items, the content theme interface, and the autocomplete extensions for emoji, at-mentions and topics. Those are meaningful, but they are configuration and theming extensions, not a plugin architecture for the editor core.
## Licence, Maintenance and the Cost of Upgrading
Vditor is MIT licensed. That permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. This is a statement about the licence text, not legal advice; if your organization has specific obligations around attribution in distributed binaries, have counsel read the LICENSE file rather than this article.
The repository is not archived, and the last push was on 2026-09-15, six days before the date used for this review. Release history shows v4.0.0 on 2026-08-30, v3.11.3 on 2026-08-11, and v3.11.2 on 2025-09-02. The gap between v3.11.2 and the v3.11.3 release spans roughly eleven months, which is worth noting if your planning assumes frequent patch releases: the project's cadence is not uniform, and a major version bump from 3.x to 4.0.0 signals that upgrading across that boundary may require code changes. The CHANGELOG.md at the repository root is where those changes would be enumerated; the README does not document a migration path from 3.x to 4.x.
Upgrade cost has a second component beyond the package itself. Because Vditor bundles or delegates to Mermaid, ECharts, MathJax, KaTeX and others, a Vditor upgrade can shift the versions of renderers your application ships. Pinning Vditor to a specific version, as the README advises for the CDN script tag, is also the safer posture for the npm route if you are not prepared to retest diagram and formula rendering on every release.
## Conclusion
Adopt Vditor if your product already renders Markdown as HTML and you need an editor that can switch between split view for power users and WYSIWYG for everyone else, loaded from npm or a single script tag. Do not adopt it if you need a standalone desktop application, a server-side renderer, or a component that ships without its own CSS and theme system. Before committing, verify two things in your own project: that your bundler resolves the stylesheet import path you choose, and that your upload endpoint matches the CORS and response shape Vditor expects, because the README documents the upload feature but not the response contract in the excerpt above.
## FAQ
### Is there a WYSIWYG editor for Markdown in Vditor?
Yes. Vditor supports three editing modes: wysiwyg for rich text, ir for Typora-like instant rendering, and sv for split preview. The README describes WYSIWYG as friendly to users who do not know Markdown while remaining usable for those who do.
### How do I install Vditor in a project?
The README gives two paths. Run npm install vditor --save and import the class plus the stylesheet, or load dist/index.css and dist/index.min.js from a CDN with a script tag, pinning a version number for production.
### Can I use Vditor with Vue or React?
The README states Vditor supports plain JavaScript as well as Vue, React, Angular and Svelte. It links a Svelte demo repository, and the case list includes Arya, an online editor built on Vue.
### Does Vditor render math formulas and diagrams?
The README lists math formula blocks and inline formulas via MathJax and KaTeX, flowcharts, sequence diagrams and Gantt charts via Mermaid, Graphviz, PlantUML, WaveDrom waveforms, ECharts charts and mind maps, and staff notation via abc.js. Most of these are described as switchable through configuration.
## Sources
- [License: MIT](https://github.com/Vanessa219/vditor/blob/master/LICENSE)
- [Project website](https://b3log.org/vditor)
- [README](https://github.com/Vanessa219/vditor/blob/master/README.md)
- [Releases](https://github.com/Vanessa219/vditor/releases)
- [Vanessa219/vditor on GitHub](https://github.com/Vanessa219/vditor)
---
Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/vanessa219-vditor