Слово легко прочитать двумя способами. Первый — отрисовать .md в свёрстанный вид и посмотреть: это чтение, и им занимается Открыть MD-файлы онлайн. Второй — написать сам исходник как положено: пустая строка там, где она нужна, выровненные колонки таблицы. Эта страница делает второе: на входе Markdown, на выходе тоже Markdown, только прибранный. Если же цель — передать документ другому человеку, вам, скорее всего, нужен Markdown в Word / PDF.
В Markdown есть несколько мест, чувствительных к пробелам: ошибка там ничего не сообщает, страница просто молча отрисовывается по-другому. Самое частое — список, прижатый к абзацу сверху без пустой строки: многие обработчики считают весь список продолжением обычного абзаца и печатают маркеры буквально. Пропущенный пробел после # в заголовке — та же беда: на GitHub не работает, а в некоторых редакторах выглядит нормально. Такие дефекты в исходнике кажутся безобидными и обнаруживаются только как поехавшая вёрстка при открытии в другом месте. Пункт с пустыми строками чинит именно это, то есть исправляет ошибку, а не наводит красоту.
Ставить пробел там, где иероглифы соседствуют с латинскими буквами или цифрами, — общепринятая типографская привычка китайской технической литературы: ханьские знаки квадратные, а латиница нет, и без зазора они слипаются. Инструмент работает по этому правилу и заодно заменяет ошибочно поставленные после иероглифа полуширинные запятую, точку и вопросительный знак на полноширинные. Два места намеренно не трогаются: содержимое блоков кода и строчного кода не меняется ни на байт — иначе идентификатор вроде my_var_name был бы испорчен. А точка, за которой идут буквы — как в 中文.md — не считается концом предложения: преобразуется только точка, действительно стоящая в конце. Для документа на английском достаточно отключить два пункта «набор для иероглифики».
Когда вы копируете оттуда, буфер обмена несёт рядом с простым текстом ещё и HTML, в котором заголовки, списки, таблицы и жирные фрагменты записаны явно. Поэтому преобразование в Markdown при вставке — детерминированная операция, а не догадка по внешнему виду текста. Обратное не делается: вставленному простому тексту никогда не дописываются # и -. Такие догадки ошибаются достаточно часто, а цена ошибки — ручная правка обратно. Если нужен только простой текст, нажмите Ctrl+Shift+V или снимите галочку с пункта «вставка».
Уборка исходника — чистая обработка текста, а предпросмотр тоже полностью рисуется в браузере, так что ни один шаг не обязан уходить на сервер. Это не только польза для приватности: без загрузки нет ни ограничения на размер файла, ни очереди, ни лимита на число операций, и после загрузки страницы всё работает даже без сети. Неопубликованные черновики, внутренние документы и наполовину написанные технические заметки не обязаны попадать на сервер, о котором вы ничего не знаете.
Нет. Уборка исходника, отрисовка предпросмотра, преобразование форматированного текста и скачивание выполняются локально в браузере на JavaScript. У страницы нет серверного API, и вставленное вами содержимое никуда не отправляется, поэтому её можно использовать для неопубликованных черновиков и внутренних документов. Самый прямой способ убедиться — загрузить страницу и отключиться от сети: инструмент продолжит работать.
Нет. Блоки кода, огороженные ``` или ~~~ и строчный код в обратных кавычках сохраняются байт в байт: пробелы не добавляются, пунктуация не меняется, отступы не сдвигаются, перенос строк не переделывается. Это жёсткое ограничение — иначе my_var_name был бы прочитан как курсив, запятая в a,b стала бы полноширинной, и код перестал бы работать. Адреса внутри ссылок защищены так же: обрабатывается только видимый текст ссылки.
Нет, и это сделано намеренно. Содержимое, скопированное из Word или с веб-страницы, приходит с HTML, в котором заголовки и списки записаны явно, поэтому преобразование в Markdown однозначно. А в куске простого текста понять, какая строка — заголовок, а какие образуют список, можно только по внешнему виду; отменять неверную догадку руками дороже, чем самому поставить # . Поэтому страница преобразует автоматически только тогда, когда обнаружила форматированное содержимое.
Обычная причина — список прижат вплотную к абзацу сверху, без пустой строки между ними. GitHub разбирает по CommonMark, и такой список считается продолжением абзаца, поэтому - выводится буквально. Другая частая причина — пропущенный пробел после # в заголовке. Вставьте содержимое и нажмите «Форматировать»: пункты «пустые строки вокруг заголовков, списков, блоков кода и таблиц» и «все заголовки в виде #» чинят именно это.
Никакая спецификация этого не требует: это общепринятая типографская привычка китайской технической литературы, которой следует большинство технических документов и командных руководств по стилю. На разбор Markdown она не влияет — дело только в удобстве чтения. Если ваш проект этого не требует или документ и так на английском, снимите галочки с двух пунктов «набор для иероглифики», а остальная уборка выполнится как обычно.
С включённым пунктом «перенумеровать нумерованные списки» — да, получится 1. 2. 3. Писать везде 1. — распространённый стиль, отрисовывается он ровно так же, как последовательная нумерация, и у него есть плюс: при вставке пункта в середину не нужно переписывать все номера дальше. Если вы хотите сохранить именно такой стиль, отключите этот пункт. Есть нюанс: два нумерованных списка, разделённые одной пустой строкой, по CommonMark остаются одним списком, поэтому нумерация продолжится, а не начнётся с 1. Чтобы разорвать их по-настоящему, между ними нужен абзац или другое содержимое.
Нет. Два пробела в конце строки — это жёсткий перенос Markdown; инструмент распознаёт такую запись и сохраняет её. Три и более схлопываются ровно до двух, а не удаляются как случайная оплошность. Вычищаются только концевые пробелы в остальных случаях. Если вам привычнее перенос через обратную косую черту, этот стиль и так не затрагивается.
Может. Выравнивание делается добавлением пробелов в ячейки, а иероглиф в моноширинном шрифте занимает две колонки — инструмент считает именно так, поэтому в VS Code, Typora и любом другом моноширинном отображении всё сходится. Редактор, показывающий исходник пропорциональным шрифтом, покажет таблицу кривой. Это влияет только на вид исходника: отрисованная таблица всегда правильная, потому что при отрисовке важно положение вертикальных черт, а не количество пробелов вокруг них.
Та страница — чистая читалка: перетащили файл и сразу видите свёрстанный вид, без правки и без экспорта. Подходит, когда прислали README и его надо просто прочитать. Эта страница переписывает ваш исходник, а на выходе снова Markdown. Читать — Открыть MD-файлы онлайн; приводить в порядок — здесь.
Нажмите на этой странице «Копировать» и вставьте в Markdown в Word / PDF, чтобы выгрузить. Или сначала нажмите «Скачать .md», а потом перетащите файл на ту страницу. Их две, потому что результаты разные: здесь вы получаете исходник Markdown, там — файл .docx или .pdf, который можно сразу отправить коллеге.
Таблицы — да, их колонки выравниваются. Списки задач (- [ ]), зачёркивание и сноски сохраняются как есть и не портятся, просто отдельных правил уборки для них нет. Предпросмотр использует парсер в стиле GitHub, поэтому таблицы и списки задач справа отображаются корректно.
Сама уборка — обработка простого текста, она остаётся быстрой и на десятках тысяч строк. Тормозить может живой предпросмотр справа: ему нужно построить DOM для каждого элемента. Если документ очень большой и ощущается вязко, вырежьте интересующую часть и работайте с ней. Перерисовка запускается примерно через 0,2 секунды после остановки ввода, так что обычный набор текста не перестраивает страницу на каждом нажатии.