{{ summaryTitle }}
{{ summaryValue }}

{{ summaryLine }}

{{ badge.label }} {{ badge.value }}
Choose the syntax used by the destination repository, editor, or publishing system.
Paste up to 100,000 characters, or load one local Markdown or text file up to 250 KB.
{{ sourceMeta }}
{{ fileStatus }}
Keep current soft breaks, wrap plain prose to a review width, or place each plain paragraph on one line.
Preserve existing markers or normalize recognized list items to one marker.
Preserve each delimiter or normalize recognized ordered-list items.
Keep the source convention, or normalize the complete formatted artifact to LF or CRLF.
{{ computation.values.formatted_markdown }}

The chart renderer is unavailable. Exact counts remain in the summary and review ledger.

StatusLineReview noteCopy
{{ row.status }} {{ row.line }} {{ row.message }}
Markdown Previewer Preview Markdown locally with GFM or CommonMark rules and sanitized HTML, plus structure checks and review notes before reusing the markup.
Markdown to HTML Converter Convert Markdown into a reusable HTML fragment or full document with flavor selection, raw-HTML controls and a sanitized local preview.
HTML to Markdown Converter Turn HTML into destination-ready Markdown with dialect and table controls plus warnings when complex structure may not survive conversion.
Markdown Table Generator Turn delimited text into clean Markdown tables with automatic header and alignment choices plus parsing warnings for ambiguous or uneven rows.

Markdown is plain text with punctuation that gains meaning when a renderer interprets it. A blank line can separate paragraphs, indentation can turn text into code, and the same pipe characters can be ordinary text under CommonMark or a table under GitHub Flavored Markdown (GFM). Formatting therefore needs a declared dialect and a careful boundary between prose that may be reflowed and syntax that must stay untouched.

Consistent source helps reviewers see content changes instead of debating bullet symbols, table padding, or line endings. It also makes repository diffs more predictable. The tradeoff is that visually similar Markdown can have different source semantics, so aggressive wrapping or marker changes should never be applied blindly to fenced code, raw HTML, hard line breaks, or ecosystem-specific front matter.

ConstructCommonMarkGFMFormatting concern
Pipe tableNot part of the core specificationRecognized extensionAlign only when the destination supports GFM tables.
Fenced codeRecognizedRecognizedKeep fence markers and code body unchanged.
Raw HTMLRecognized in defined formsBased on CommonMark with extensionsDo not render or rewrite it during source cleanup.
YAML-style front matterNot a core constructNot defined by the base GFM specificationPreserve it as an ecosystem extension.

Prose wrapping controls source lines, not the rendered paragraph width. Keeping soft breaks preserves the author's line choices. Wrapping to 80, 100, or 120 characters can improve review in text editors, while placing each plain paragraph on one line reduces diff churn from manual line wrapping. Hard breaks and inline HTML need special treatment because joining those lines could change meaning.

List-marker normalization changes recognized -, *, or + bullets and the punctuation after ordered-list numbers. It does not renumber the list or reinterpret its content. Likewise, line-ending normalization changes the file convention between LF and CRLF without changing visible Markdown characters.

A formatter is not a renderer or link checker. Clean source can still contain broken references, unsafe embedded HTML, unsupported extensions, or prose that renders differently on another platform. Review the result in the destination system when dialect compatibility matters.

How to Use This Tool:

Choose the destination dialect first, then normalize only the source conventions that the receiving repository or publishing system expects.

  1. Select CommonMark or GitHub Flavored Markdown. Choose GFM when pipe tables should be aligned; CommonMark keeps table-like extension syntax unchanged and flags it for review.
  2. Paste up to 100,000 characters into Markdown source, or load one local Markdown or text file up to 250 KB.
  3. Set Prose wrapping, list markers, and Line endings. Preserve the current values when the destination's rules are unknown.
  4. Check Format review before using the output. Close any unterminated fence, and inspect notes for preserved front matter, raw HTML, hard breaks, or dialect-sensitive table syntax.

Interpreting Results:

The changed-line count compares source and formatted lines at the same positions. Adding or removing one early line can make later positions appear changed, so the count describes formatting impact rather than a semantic diff. Read the formatted source and review notes when the number is unexpectedly high.

A review count of zero means no protected or dialect-sensitive construct produced a warning note. It does not prove that links resolve, extensions work in the destination, or embedded HTML is safe. Preview the final file with the same renderer used by the target repository or publishing system.

Technical Details:

Structure-sensitive formatting begins by marking lines that must not be reflowed. Complete fenced-code blocks are protected from the opening marker through the matching closing marker. Front matter bounded by --- and either --- or ... near the start is also preserved exactly. Remaining lines are handled as tables, raw HTML, special block syntax, blank separators, or plain prose.

Transformation Core

The selected options form a deterministic sequence. Earlier protection decisions prevent later wrapping and marker rules from touching sensitive content.

Input patternTransformationImportant boundary
Fenced codePreserve opening, body, and closing lines exactly.The closing marker must use the same character and at least the opening length.
Front matter at line 1Preserve the complete bounded region exactly.It is reported as an extension rather than interpreted as CommonMark.
GFM pipe tableSplit unescaped pipes outside code spans, pad columns, and retain alignment colons.A separator row with at least three dashes per cell is required.
CommonMark table-like textLeave the lines unchanged and add a review note.Pipe tables are not normalized in CommonMark mode.
Plain paragraphPreserve, wrap to 80/100/120 characters, or join onto one line.Wrapping is skipped when a hard break or inline HTML is present.
Recognized list itemPreserve or replace its bullet or ordered-list delimiter.Numbers and list content are not renumbered or rewritten.
Whole outputCollapse repeated blank separators and finish with one newline.Line endings resolve to the source convention, LF, or CRLF.

A table cell splitter ignores escaped pipes and pipes inside matched backtick runs. Cell text is trimmed, column widths are based on character count, and alignment colons in the separator row remain on the left, right, or both sides. This improves source alignment without parsing inline emphasis, links, or other cell content.

Plain prose is joined with single spaces before optional wrapping. A word longer than the selected width stays intact rather than being split. A line ending in two or more spaces or a backslash is treated as sensitive, and a paragraph containing inline HTML keeps its original line wrapping.

BoundaryRuleRecovery
Source length1 to 100,000 charactersShorten the source or format it in sections.
Output lengthAt most 400,000 charactersReduce the input or choose a less expansive layout.
Backtick fence infoA backtick fence cannot contain a backtick in its info string.Remove that character or use a tilde fence.
Open fenceEvery fenced block needs a valid closing marker.Close the block before formatting.
Null characterNot accepted in source textRemove the null character.

All source remains local and inert. Fenced code is not executed, raw HTML is not rendered, and remote resources are not fetched. The formatter preserves those regions for review rather than deciding whether their content is safe.

References: