markdown-editor turns a markdown file in VS Code into a WYSIWYG editor
A vscode extension to make your vscode become a full-featured WYSIWYG markdown editor
At a glance
- What is it?
- markdown-editor is an MIT licensed VS Code extension that opens a markdown file in a webview editor with instant rendering, split screen and diagram support, and it is a thin wrapper around vditor that keeps the file on disk as plain markdown the whole time.
- Who is it for?
- markdown-editor fits a writer who wants a Typora style editor without leaving VS Code, and the auto sync between the source and the webview is what makes that possible rather than a separate application.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.
Editorial analysis
Ten features, three editing modes and one underlying editor
The extension's stated aim is to make VS Code a full-featured WYSIWYG markdown editor, and the feature list is numbered, which makes it easy to take in.
The first is what you would expect, WYSIWYG editing. The second is the mechanism that makes it work: auto sync changes between the VSCode editor and webview. Third, copy markdown or html. Fourth, uploaded, pasted or drag-dropped images are auto-saved to an assets folder, which is the detail that decides whether the extension is usable for anything with screenshots in it. Fifth, multi-theme support. Sixth, shortcut keys. Seventh, multiple editing modes: instant Rendering mode, which the list marks as recommended, a WYSIWYG mode and a split screen mode. Eighth, markdown extensions. Ninth, multiple graph support including KaTeX, Mermaid, Graphviz, ECharts and abc.js for notation, and tenth is a pointer to vditor for more usage.
That last point is the key to the whole project. The extension is not a markdown engine of its own, it is a VS Code shell around vditor, the editor that the acknowledgements name alongside VS Code itself. The topic tags make the lineage explicit, listing marktext, typora and music-notion, the other applications in this family.
The consequence is that the extension inherits vditor's capabilities and its constraints, and that a question about a diagram or a math formula is really a question about vditor.
Five ways to open the editor, and one keyboard shortcut
Opening a markdown file in the editor is documented five ways, which is generous and reflects that the extension registers itself in several of VS Code's menus.
The command route is to open a markdown file, type cmd-shift-p to enter command mode, and type markdown-editor: Open with markdown editor. The keyboard route is ctrl+shift+alt+m on Windows or cmd+shift+alt+m on macOS.
The Explorer context menu route is to right click a markdown file and click Open with markdown editor, and the editor title context menu route is the same action on the tab title of an already open markdown file. The fifth is the Open With... menu, where you can select Markdown Editor to open the file temporarily, or click Configure default editor... and select Markdown Editor to make it the default.
Those last two are the ones that matter for a workflow. Making the extension the default editor for markdown changes the experience of every markdown file you open, including the ones you only meant to read, and the customEditors entry in the manifest gives it a priority of option, which means VS Code may still choose another editor for some files. The extension therefore registers itself as an option rather than taking over.
The manifest shows exactly how it hooks into VS Code
The package metadata is where the integration becomes precise, and the four activation events tell you when the extension wakes up:
"activationEvents": [
"onCommand:markdown-editor.openEditor",
"onWebviewPanel:markdown-editor",
"onLanguage:markdown",
"onCustomEditor:markdown-editor.customEditor"
],Two of those are interesting. onLanguage:markdown means the extension activates for any markdown file, which is what allows the context menu entries to appear. onCustomEditor:markdown-editor.customEditor points at a custom editor that, as the Todo section explains, is not finished yet.
The custom editor entry in the manifest is the part that is registered but not finished:
"customEditors": [
{
"viewType": "markdown-editor.customEditor",
"displayName": "Markdown Editor",
"selector": [
{
"filenamePattern": "*.md"
},
{
"filenamePattern": "*.markdown"
}
],
"priority": "option"
}
],The two menus are scoped to markdown files with a when clause of resourceLangId == markdown, one in the explorer context and one in the editor title context, and the command they point at is markdown-editor.openEditor with the title Open with markdown editor and the category markdown-editor.
The remaining details are conventional: the extension requires VS Code ^1.47.0, its entry point is out/extension.js, its version is 0.1.21 and its publisher is zaaack.
Custom CSS reaches into the vditor layer
The extension lets you configure custom JavaScript and CSS without rebuilding, and the setting is called markdown-editor.customCss. The documentation shows the shape of the setting and then a full example:
"markdown-editor.customCss": "my custom css rules"
// Eg: "markdown-editor.customCss": ".vditor-ir pre.vditor-reset {line-height: 32px;padding-right: calc(100% - 800px) !important; margin-left: 100px; font-family: system-ui !important;}"Look at the class names in the example, because they tell you how deep the setting goes. The selector targets .vditor-ir, which is vditor's instant rendering mode, and the nested pre.vditor-reset, which is the reset class on the code blocks. The properties adjust line height, right padding, a left margin and the font family.
So the setting is not a theme hook, it is a raw CSS injection point into the editor that vditor renders, and the documentation expects you to know vditor's class names to use it. That is a fair trade for a power user and a barrier for everyone else, and it is a consequence of the extension being a thin wrapper rather than an editor with a theme API.
The features that carry the same lesson are the theme support and the diagram support. Themes are vditor's themes, and KaTeX, Mermaid, Graphviz, ECharts and abc.js are vditor's renderers, so anything you expect from those libraries inside a WYSIWYG markdown editor is available, and anything missing from them is missing here too.
The Todo list shows what is not finished
The repository has a Todo section with one unchecked item: using the Custom Text Editor API, with a link to the VS Code documentation for that API and a demo repository, markmap-vscode, by gera2ld.
That single line explains the manifest. The extension already registers a customEditors entry with a viewType, a display name, a filename pattern for .md and .markdown files and a priority of option, and it already has an activation event for onCustomEditor:markdown-editor.customEditor. What is missing is the custom editor implementation itself, which is why the editor is currently opened as a webview panel through the command, the keybinding and the context menus, rather than as VS Code's own custom text editor.
The difference matters more than it looks. A custom text editor is how a VS Code extension replaces the whole editor surface for a file type, which is how you get a true split view with the rendered and source panes side by side, and how the extension gets the editor title bar and tab affordances it wants. The current implementation is a webview panel that sits alongside the standard editor, which is why the auto sync between the VS Code editor and the webview is listed as a feature rather than being implicit.
So the split screen mode in the feature list is vditor's split, inside a webview, not VS Code's native editor split. That is a workable compromise, and the Todo says the project intends to replace it.
Where it fits, and how the project is maintained
The honest comparison is with the other members of the family. MarkText and Typora are standalone applications, and Notion is a hosted editor, and this extension is the VS Code version of that idea. Its advantage over the standalone tools is that the file stays in your project, in version control, next to the code, and that the editor is the one you already have open. Its disadvantage is that you are inside an editor that was designed for text, so a few affordances are second hand.
The maintenance picture is modest and worth reading carefully. The repository has no GitHub releases, and the version in the package metadata is 0.1.21. The last push was on 2026-09-02, so the project is not archived and is being worked on, but there is no release history to track and no changelog to consult.
The build setup is small and modern in the parts that matter. The repository has a src/ directory for the extension, media/ and media-src/ for the icons, a pnpm workspace with a lock file, a tsconfig.json and a Foyfile.ts, which is a TypeScript build tool, so the project builds with a tool that is defined in code rather than in a shell script. The licence is MIT, the extension is published in the Visual Studio Marketplace under the item name zaaack.markdown-editor, and the author asks for stars and accepts donations through PayPal.
Editorial conclusion
markdown-editor fits a writer who wants a Typora style editor without leaving VS Code, and the auto sync between the source and the webview is what makes that possible rather than a separate application. It does not fit a team that wants a custom editor registered for markdown files, because the custom editor entry in the manifest is still an unchecked item on the project's own list, and it does not fit anyone who needs a stable extension, since there are no GitHub releases and the version in the tree is 0.1.21. Before adopting it, decide which of the three editing modes you actually want, because the instant rendering mode is a different writing experience from the WYSIWYG one, and check the custom CSS setting if the default layout does not suit you.
Frequently asked questions
How do I open a markdown file in the markdown-editor extension?
There are five routes: the command palette with cmd-shift-p and markdown-editor: Open with markdown editor, the keyboard shortcut ctrl+shift+alt+m on Windows or cmd+shift+alt+m on macOS, the Explorer context menu, the editor title context menu, and the Open With... or Configure default editor... entries.
Which editing modes does the markdown-editor extension offer?
Three: instant Rendering mode, which the feature list marks as recommended, a WYSIWYG mode, and a split screen mode. The extension is built on the vditor editor and keeps the source and the webview in sync automatically.
What can I customise in the markdown-editor extension?
The markdown-editor.customCss setting injects your own CSS, with the documented example targeting vditor classes such as .vditor-ir and pre.vditor-reset to change line height, padding, margin and font family. Themes and diagram renderers come from vditor.
Does the extension register itself as a custom editor for markdown files?
The manifest contains a customEditors entry with the view type markdown-editor.customEditor matching *.md and *.markdown with a priority of option, but the project's own Todo lists the Custom Text Editor API as unfinished, so the editor is currently opened as a webview panel through the command, keybinding and context menus.
What licence is the markdown-editor extension released under?
MIT. The extension is published in the Visual Studio Marketplace as zaaack.markdown-editor, the version in the package metadata is 0.1.21, the repository has no GitHub releases, and the last push was on 2026-09-02.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/zaaack-vscode-markdown-editor)Was this useful?