The word is easily read as two different things. One is rendering .md into a laid-out page to look at — that is reading, and it belongs to Open MD Files Online. The other is writing the source properly: a blank line where one belongs, a table whose columns line up. This page does the second one — Markdown goes in, Markdown comes out, just tidier. If your goal is to hand the document to someone else, what you probably want is Markdown to Word / PDF.
Markdown has a few whitespace-sensitive spots where a mistake raises no error and simply renders as something else. The most common one is a list pressed against the paragraph above it with no blank line: many renderers treat the whole list as a continuation of that paragraph and print the markers literally. A missing space after a heading's # is the same kind of fault: it does not work on GitHub while looking fine in some editors. Problems like these look harmless in the source and only show up as broken layout when the file is opened somewhere else. The blank-line option is what fixes them, which makes it a correctness fix rather than a cosmetic one.
Putting a space where CJK characters meet Latin letters or digits is the usual typographic convention in Chinese technical writing: Han characters are square and Latin letters are not, so without a gap the two crowd each other. The tool applies that rule, and also replaces half-width commas, periods and question marks misused after CJK with their full-width forms. Two places are deliberately left alone: nothing inside a code block or inline code is touched, not one byte — otherwise an identifier like my_var_name would be mangled. And a period followed by letters, as in 中文.md is not treated as a full stop — only a period genuinely at the end of a sentence is converted. For an English document, simply turn the two “CJK typography” options off.
When you copy from those places the clipboard carries an HTML flavour alongside the plain text, and the headings, lists, tables and bold runs are all in it. So converting to Markdown on paste is a deterministic conversion, not a guess based on what the text looks like. The reverse does not happen: pasted plain text is never given # and -. That kind of guessing is wrong often enough, and the price of a wrong guess is undoing it by hand. If you only want plain text, press Ctrl+Shift+V or untick the “paste” option.
Tidying the source is pure text processing, and rendering the preview can be done entirely in the browser too, so no step has to go to a server. That is not only a privacy benefit: with no upload there is no file size limit, no queue and no usage cap, and the page keeps working after you go offline. Unpublished drafts, internal documents and half-written design notes need not be handed to a server you know nothing about.
No. Tidying the source, rendering the preview, converting rich text and downloading the result all happen locally in your browser via JavaScript. The page has no backend endpoint and never sends what you paste to any server, which makes it safe for unpublished drafts and internal documents. The most direct way to check is to load the page and then disconnect from the network — the tool keeps working.
No. Code blocks fenced with ``` or ~~~ and inline code wrapped in backticks are left byte for byte: no spaces added, no punctuation changed, no indentation moved, no rewrapping. That is a hard constraint — otherwise my_var_name would be read as italics, the comma in a,b would become full-width, and the code would stop running. URLs inside links are protected the same way; only a link's visible text is processed.
No, and that is deliberate. Content copied from Word or a web page arrives with an HTML flavour in which the headings and lists are stated explicitly, so converting it to Markdown is a certainty. In a block of plain text, though, which line is a heading and which lines form a list can only be guessed from appearance — and undoing a wrong guess by hand costs more than typing the # yourself. So this page only converts automatically when it detects formatted content.
The usual cause is a list pressed right against the paragraph above it with no blank line in between. GitHub parses by CommonMark, which treats such a list as a continuation of that paragraph, so the - is printed literally. The other common cause is a missing space after a heading's # . Paste the content in and press “Format”: the “blank lines around headings, lists, code blocks and tables” and “headings all written with #” options are exactly the fixes for this.
No specification requires it; it is the usual typographic convention in Chinese technical writing, followed by most Chinese technical documentation and most teams' style guides. It does not affect how Markdown is parsed — it is purely about readability. If your project does not ask for it, or the document is in English anyway, untick the two “CJK typography” options and the rest of the cleanup still runs.
With “renumber ordered lists” ticked, yes: it becomes 1. 2. 3. Writing every item as 1. is a common style, renders identically to sequential numbering, and has the advantage that inserting an item in the middle does not mean renumbering everything after it. If that is the style you want to keep, turn this option off. One thing to watch: two ordered lists separated by a single blank line are still the same list under CommonMark, so the numbering continues instead of restarting at 1. To break them apart you need a paragraph or some other content in between.
No. Two spaces at the end of a line are Markdown's hard line break; the tool recognises that and keeps them. Three or more collapse to exactly two rather than being deleted as a slip. Only trailing whitespace in other situations is stripped. If you prefer a trailing backslash for line breaks, that style is unaffected to begin with.
It might. Alignment works by padding cells with spaces, and a CJK character occupies two columns in a monospaced font — the tool counts it that way, so tables line up in VS Code, Typora and anywhere else that shows source in a monospaced font. An editor that displays source in a proportional font will make it look crooked. This only affects how the source looks: the rendered table is always correct, because rendering looks at where the pipes are, not at how many spaces surround them.
That page is a pure reader: drop a file in and see the laid-out version, with no editing and no export — right for a README you just want to read through. This page rewrites your source and hands back Markdown. To read, use Open MD Files Online; to tidy up, use this page.
Press “Copy” on this page and paste into Markdown to Word / PDF to export, or press “Download .md” first and drag the file onto that page. They are two pages because they produce different things: this one gives you Markdown source, that one gives you a .docx or .pdf you can send to a colleague as is.
Tables are, and their columns get aligned. Task lists (- [ ]), strikethrough and footnotes are preserved as they are and never broken, they simply have no cleanup rules of their own. The preview uses a GitHub-flavoured parser, so tables and task lists render correctly on the right.
The cleanup itself is plain text processing and stays fast even at tens of thousands of lines. What can slow down is the live preview on the right, which has to build DOM for every element. If a document is very large and feels sluggish, cut out the part you care about and work on that. Re-rendering only happens about 0.2 seconds after you stop typing, so ordinary typing does not re-lay-out the page on every keystroke.