Markdown-Editor

No, your Markdown content is never sent to any server. The editor runs entirely in your browser using JavaScript: text you type is held in the editor's state object in memory, file imports are read using the FileReader API which loads file bytes locally without any network request, and the live HTML preview is generated client-side by a Markdown parsing library — typically Marked.js or a similar pure-JavaScript renderer — that processes your text synchronously in the browser process. There is no backend, no autosave endpoint, no analytics pipeline collecting your document content, and no cloud storage involved at any stage. This privacy-first design is deliberate: Markdown files often contain draft articles, private notes, technical documentation, internal project plans, or personally sensitive writing that you should not need to trust to a third-party server. You can verify this by opening your browser's DevTools Network tab and observing that no POST or PUT requests are made as you type or as the preview updates. The tool works fully offline after the initial page load — if you disconnect from the internet and continue editing, everything continues to function because no network calls are made during normal use. Auto-save behavior, if implemented, writes to the browser's localStorage or sessionStorage API, which is local to your device and never synchronized externally. As a practical tip, if you are editing a sensitive document, load the page once while connected, then enable airplane mode or disconnect from the internet before typing — your work remains fully functional and completely private.

The editor supports CommonMark-compliant Markdown syntax, which is the widely adopted formal specification that resolves ambiguities in John Gruber's original Markdown. This includes all standard inline elements: emphasis and strong emphasis using single and double asterisks or underscores, inline code with backtick fences, hyperlinks in both inline and reference formats, images with alt text, and strikethrough using double tildes. Block-level elements include all six heading levels using ATX-style hash prefixes, fenced code blocks with triple backticks and optional language identifiers for syntax highlighting, blockquotes using the greater-than character, ordered and unordered lists with nested indentation, horizontal rules, and HTML passthrough for inline HTML elements. Extended GitHub Flavored Markdown (GFM) features are typically included as well: task lists with checkbox syntax, tables using pipe-delimited columns with a separator row, and autolinked URLs. Mathematical notation via LaTeX syntax rendered by KaTeX or MathJax may or may not be available depending on the specific build. The preview pane renders the HTML output in real time as you type, applying a clean typographic stylesheet so you can evaluate both semantic structure and visual appearance simultaneously. All parsing runs entirely in your browser — no data leaves your device. As a practical tip, for code blocks, always specify the language identifier after the opening triple backtick — for example, triple backtick followed by javascript — to enable syntax highlighting in the preview, which makes reviewing code-heavy documentation significantly easier.

Yes, the Markdown editor works excellently as a README viewer. You can open any local .md file by using the file import button or by dragging the file onto the editor area; the FileReader API loads the raw text into the editor pane, and the live preview renders it immediately as formatted HTML. This is particularly useful for reviewing README.md files from downloaded repositories before opening them in a full development environment, or for reading documentation files without needing GitHub, a code editor, or any installed application. GitHub Flavored Markdown (GFM) features commonly found in README files — such as tables, task lists with checkboxes, fenced code blocks with language syntax highlighting, and relative image links — are rendered correctly in the preview. Note that relative image paths referenced in a README file, such as ./screenshots/demo.png, will not load because the tool does not have access to the surrounding directory structure; only images with absolute URLs will display in the preview. Embedded HTML blocks, which GitHub allows in README files, also render in the preview, though the tool may sanitize certain HTML tags for security. The preview styling does not identically replicate GitHub's exact CSS, but the structural rendering is faithful to GFM semantics. All processing runs entirely in your browser — no data leaves your device. As a practical tip, paste the raw README content directly into the editor if the file contains relative image paths — you can then see the full text rendering without missing image placeholders distracting from the documentation structure.

To download your document as an HTML file, use the export button in the toolbar — typically labeled Export HTML or Download HTML. When triggered, the tool takes the current rendered HTML from the preview pane, wraps it in a minimal HTML5 document structure including a DOCTYPE declaration, a head element with a UTF-8 charset meta tag, and a body element, and then creates a downloadable file using the Blob API with a MIME type of text/html and a .html extension. The download is initiated via a dynamically created anchor element with the download attribute set, triggering the browser's native save dialog or auto-saving to your downloads folder depending on your browser settings. The exported HTML is self-contained in the sense that the Markdown content is fully converted — there is no dependency on the original .md file or on the WikiPlus site being available. However, the default export typically includes only inline styles or a basic stylesheet link; it does not bundle images referenced by URL into the file. If you need a fully portable self-contained document, you would need to manually add styles or inline CSS to the exported file. The Markdown source can also be downloaded separately as a .md file if you want to preserve the source alongside the rendered version. All processing runs entirely in your browser — no data leaves your device. As a practical tip, before exporting, check the preview carefully and ensure all headings, code blocks, and tables look as intended, since the exported HTML will exactly reflect what you see in the preview pane.