lengyi-markdown-editor: a single HTML file Markdown editor with live preview and local auto-save

What lengyi-markdown-editor is for, and who should open it

The README frames the project around a specific frustration: Markdown tools that are heavy, subscription-based, or that sync content to the cloud without asking. The author describes building it after using tools that did those things. The result is one file, markdown-editor.html, that you double-click and write in. Everything is stored locally and the README states it works offline.

The intended user is narrow. You write Markdown occasionally or constantly, you want a live preview beside the text, and you do not want an account. The README also points at AI-adjacent writing: it names Codex, Claude Code and Openclaw and suggests the editor for drafting AGENTS.md or Skill.md files. That is a real use case, since those are plain Markdown documents with no special syntax.

The project is not for teams. There is no server component in the core app, no sync, no comments, no revision history beyond what Ctrl+Z gives you. If you need any of those, this is the wrong tool and the README does not pretend otherwise. It also is not a static site generator or a note-taking database; it edits one document at a time in a browser tab.

How the editor renders Markdown: marked.js, KaTeX and Mermaid in one page

The README lists the stack plainly: HTML5, CSS3 and vanilla JavaScript, no framework. Markdown rendering comes from marked.js. Math comes from KaTeX, with $...$ for inline and $$...$$ for block. Diagrams come from Mermaid 10, described as supporting mind maps and flowcharts. Image export uses dom-to-image-more. All core styles, structure and logic are inlined into the single HTML file, which is why it runs offline.

The data flow shown in the README's architecture diagram is a textarea on the left, a preview pane on the right, and a sync arrow between them. Below that, two paths branch: the textarea writes to localStorage for auto-save and state restore, and the preview pane feeds KaTeX and Mermaid for formula and diagram rendering. That is the whole pipeline. There is no parser server, no build step, no bundler.

The consequences of that design are worth stating. Because rendering happens in the browser on every keystroke, very large documents will cost more than a native editor would, though the README gives no size guidance. Because KaTeX and Mermaid are loaded as browser libraries, the editor needs network access on first load unless you vendor them locally; the README does not describe a vendored, fully offline bundle, only that the app works offline. If strict offline operation matters to you, that is the first thing to verify in your own copy.

Installing lengyi-markdown-editor and writing your first document

There is no package to install. The README gives three ways to start, and the first is the shortest: clone the repository and open the HTML file directly.

git clone https://github.com/woyin2024/lengyi-markdown-editor.git

After cloning, open markdown-editor.html in a browser by double-clicking it. You should see the editor on the left and the preview on the right, updating as you type.

The README recommends a local server instead of the file:// path, which avoids browser restrictions around local file access. Python 3 or Node.js both work.

cd lengyi-markdown-editor
python -m http.server 8080

With the server running, open http://localhost:8080/markdown-editor.html. The README also shows npx serve . as a Node alternative for the same purpose.

The third option is the optional proxy for converting web pages to Markdown. It is a Python script, web-to-md-proxy.py, and the README lists requests as an optional but recommended dependency. The default port is 8765, and you enable it by checking a box labeled Use local proxy in the editor.

pip install requests
python web-to-md-proxy.py

Once you are in the editor, the workflow is what you would expect. Type Markdown, watch the right pane. Use Ctrl+B and Ctrl+I for bold and italic, Ctrl+K for a link, Ctrl+Shift+K for an image, Ctrl+F for find and replace, and Tab for a four-space indent. The README states that content is auto-saved to localStorage every 500ms, and that content, filename, split ratio, collapsed states, theme and language all survive a page refresh. Test that yourself once before trusting it with anything long.

Export formats and the long-image option for social posting

Export is where this editor does more than the minimum. The README documents five outputs: .md as raw Markdown, .html as a standalone file, .doc as a Word document that opens directly in Office, .pdf through the browser's print-to-PDF, and .png as a long image with 9:16, 4:5, 3:4, 1:1 and 16:9 ratios.

The .pdf path deserves a note. It is not a PDF generator in the library sense; it hands the job to the browser's print dialog. That means pagination, margins and font substitution are whatever your browser decides, so the output will differ between Chrome, Firefox and Safari. The README does not document a way to control page size or margins.

The .doc export is the one to verify first if you need it. The README says Word documents open directly in Office, which is a claim about the output format rather than a tested compatibility matrix across Word versions and LibreOffice. The .png long-image export is the most distinctive feature here: it is aimed at people who post Markdown-rendered content to social platforms that do not accept Markdown, and the fixed aspect ratios make that obvious. Image export relies on dom-to-image-more, which the README lists in the stack.

Where the single-file design becomes a limitation

The absence of a filesystem is the structural limit. A browser page cannot silently write to your disk, so saving means Ctrl+S and a download, or relying on localStorage. That store is per-browser and per-origin, which has two consequences the README does not discuss. First, if you open the file from file:// in one browser and from http://localhost:8080 in another, those are different origins with different storage, so your auto-saved content will not follow you. Second, clearing site data, using private browsing, or switching machines loses the draft. The README states that content survives a page refresh; it does not claim it survives a browser reset, and it should not be read that way.

There is also no version history. Ctrl+Z and Ctrl+Y are the only undo mechanisms listed. For a long document edited over days, that is thin.

The proxy is the other soft spot. It is described as optional and as performing web fetching with anti-bot bypass. Anti-bot measures change constantly and are site-specific, so a script of this kind is inherently fragile: it may work against one site today and fail against the same site next month. The README gives the port and the dependency but no list of supported sites, no rate-limit guidance, and no note on what happens when a fetch fails. Treat it as a convenience, not infrastructure.

Finally, the editor loads marked.js, KaTeX and Mermaid from the page. The README does not pin versions for these libraries, which means a copy of the file can behave differently over time depending on where those assets come from. If you need reproducibility, vendor them and pin them yourself.

How it compares with a desktop editor like Obsidian or Typora

The closest alternatives are desktop Markdown editors that keep files on disk, and the difference is architectural rather than cosmetic. A desktop editor owns the filesystem: it opens a folder, watches files for changes, and saves in place. lengyi-markdown-editor cannot do that, because it is a web page. In exchange it needs no installation, no account, and no platform-specific build, and the README's claim that it works offline follows from the single-file design.

Against a browser-based editor that syncs to a cloud account, the difference is data handling. This project stores content in localStorage on your machine and has no server in the core app. That is a deliberate choice the README states in its opening lines, and it is the main reason to pick it over a hosted alternative.

Against a full static site generator or a notes application, the comparison is unfair in both directions. This tool edits one document. It does not manage a vault, link notes, or publish a site. If your Markdown lives in a Git repository and you want diffs and history, a desktop editor plus Git is the better arrangement, and this project does not compete there.

Licence, maintenance and what an upgrade actually costs you

The licence is MIT, per the LICENSE file and the badge in the README. In practice that means you can copy markdown-editor.html into your own project, modify it, and ship it, provided you keep the licence notice. This is not legal advice; read the LICENSE file for the exact terms.

The MIT licence matters more than usual here because the whole application is one file. Forking is trivial in the technical sense: copy the HTML, change what you want, host it. There is no dependency tree to reconcile and no build pipeline to reproduce. The flip side is that you also inherit the unpinned third-party libraries, so a fork is only as stable as the sources it loads from.

Maintenance status: the repository is not archived, and the last push was on 2026-07-03. There are no releases retrieved, so there is no versioned upgrade path. Upgrading means pulling the latest commit and diffing markdown-editor.html against your copy, or re-forking. Because the app is a single file with inlined logic, a merge can touch anything, and there is no changelog in the README to tell you what moved. If you customize the file, keep your changes in a separate patch or a clearly marked block so the next pull is reviewable.

The i18n dictionary lives in i18n.js rather than inside the HTML, which is the one piece of the app that is already separated. The README lists ten languages and states that the language preference is persisted to localStorage. Adding a language means editing that file, which is the lowest-risk contribution path in the repository.

Editorial conclusion

Adopt lengyi-markdown-editor if you write Markdown in a browser and want the file to stay on your machine: open markdown-editor.html, confirm the editor loads marked.js, KaTeX and Mermaid as documented, and check that auto-save survives a refresh. Skip it if you need multi-file projects, Git integration, or anything that writes to disk, since the README documents no filesystem access. Before relying on it, verify the export paths you actually need, particularly .doc and .pdf, and confirm the version of marked.js you are loading, because the README does not pin one.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. woyin2024/lengyi-markdown-editor on GitHub