{{ summaryTitle }}
{{ summaryValue }}

{{ summaryLine }}

{{ badge.label }} {{ badge.value }}
Paste one document or load a local .md, .markdown, or text file up to 200 KB.
{{ sourceMeta }}
{{ fileStatus || 'Drop one Markdown or text file onto the editor.' }}
Choose the dialect used by the document's publishing workflow.
Recommended checks structure, whitespace, code, links, and accessibility without imposing a line limit.
Choose the policy used by the repository or publisher that owns this document.
Optional JSON. Leave empty to use the selected profile unchanged; unknown rules are rejected.
LocationRuleSeverityFindingFixCopy
L{{ finding.line }}:C{{ finding.column }} {{ finding.rule }}{{ finding.alias }} {{ finding.severity }} {{ finding.description }}{{ finding.detail }} {{ finding.fixable ? 'Automatic fix exists' : 'Review manually' }}
No findings in the selected rule scope.

The chart renderer is unavailable. Exact counts remain available in Findings and Review brief.

Review brief
Priority

{{ reviewPriority }}

Selected scope

{{ selectedScopeLine }}

Interpretation boundary

This local report checks the supported rule set only. It does not prove identical output across every Markdown renderer, validate remote links, or rewrite the source.

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 can render successfully and still be difficult to maintain. A skipped heading level weakens the outline, an unlabeled code fence hides syntax from highlighters, inconsistent table pipes make reviews noisy, and vague link text gives screen-reader users little context.

Linting turns those editorial conventions into repeatable findings. It does not decide whether the writing is correct or whether a publisher will render every construct the same way. The useful question is narrower: does the source follow the structural, whitespace, code, table, link, and accessibility rules selected for this document?

ChoiceWhat changesTypical use
CommonMarkChecks the portable base syntax without GitHub table extensions.Documents moving among several CommonMark-compatible systems
GitHub Flavored MarkdownAdds table structure and table-spacing checks to the CommonMark-oriented rules.READMEs, issues, and repository documentation rendered by GitHub-like systems
Recommended profileEnables the practical structure, whitespace, code, link, and accessibility set.General documentation without a fixed line-length policy
Strict docs profileAlso requires a top-level first heading and a 100-character line limit.Repositories that enforce a consistent house style

Front matter needs an explicit policy because metadata at the top of a document can resemble Markdown. Ignoring recognized YAML, TOML, or JSON front matter keeps repository metadata out of the findings; linting every line is appropriate only when that metadata is meant to follow the same rules.

A zero-finding report means the selected rules found nothing. It does not validate links, spelling, prose quality, embedded HTML safety, or the final rendered page. Keep the rule profile with the document workflow so future checks use the same standard.

How to Use This Tool:

Match the document's publishing dialect and repository policy before judging any finding.

  1. Paste the document into Markdown source or load one local Markdown or text file. Keep the source within 200,000 Unicode characters and 5,000 lines.
  2. Choose CommonMark 0.31.2 or GitHub Flavored Markdown 0.29-gfm according to the destination, then select Recommended or Strict docs.
  3. Set Front matter to ignore a recognized opening metadata block or to lint every line. Use the same choice as the repository's normal linter.
  4. Add Rule overrides only when the project has reviewed exceptions. Enter a JSON object using rule IDs or aliases; unknown rules and unsupported settings are rejected.
  5. Read the first line-level finding, correct the source outside the report, and run the check again. Use the rule summary to spot repeated patterns after the earliest structural problem is fixed.

Interpreting Results:

Each finding names a line, Unicode-aware column, rule ID, severity, problem, and suggested correction. Errors and warnings use the same detection logic; severity records how the current policy wants the finding handled.

The report stops after 250 findings. When truncation is reported, fix early structural and whitespace issues before treating the rule-frequency totals as complete. A document can also suppress selected checks with recognized markdownlint comments, so a quiet line may reflect an intentional directive rather than a globally disabled rule.

The source is reported, not rewritten. Apply corrections in the owning document and check the final rendering separately, especially for tables, links, images, and code fences.

Technical Details:

Markdown linting is an ordered rule evaluation over normalized text. Carriage-return line endings become line feeds, a leading byte-order mark is removed, optional front matter is marked as skipped, fenced-code regions are identified, and suppression directives are resolved before individual rules add findings.

Rule Core:

RuleCheckProfile or dialect
MD001Heading levels increase by no more than one.Recommended and Strict
MD009Trailing spaces are reported.Recommended and Strict
MD010Hard tab characters are reported.Recommended and Strict
MD012More than one consecutive blank line is reported.Recommended and Strict
MD013Lines exceed the configured length, 100 characters by default.Strict by default; optional override range 20 to 500
MD022Headings need blank lines before and after.Recommended and Strict
MD031Fenced code needs matching fences and surrounding blank lines.Recommended and Strict
MD032List groups need surrounding blank lines.Recommended and Strict
MD040Opening code fences need a language identifier.Recommended and Strict
MD041The first material line must be a level-one heading.Strict by default
MD045Images with empty alternate text are reported.Recommended and Strict
MD047The file must end with exactly one newline.Recommended and Strict
MD055Leading and trailing table-pipe style stays consistent.GFM only
MD056Every table row has the header's column count.GFM only
MD058Tables need surrounding blank lines.GFM only
MD059Link labels such as “click here,” “here,” or “read more” are reported.Recommended and Strict

Rule overrides accept true, false, "warning", "error", or a settings object. A default entry applies a shared enabled state or severity before later rule entries. Only MD013 accepts the extra line_length setting.

Mechanism Core:

StageDecisionWhy order matters
Input boundsReject empty text, null characters, excess characters, excess lines, or oversized overrides.No partial report is produced for invalid input.
PolicyBuild profile defaults, then apply the JSON overrides.Later explicit settings determine enabled state and severity.
ExclusionsSkip recognized front matter when selected and map file, persistent, line, and next-line directives.Suppressed rules do not add findings at those lines.
StructureMark fenced-code regions and GFM tables before ordinary line checks.Code contents are not mistaken for headings, lists, images, or links.
ReportSort findings by line, column, and rule after evaluation.The first correction follows document order.

Recognized front matter begins on the first line with ---, +++, or { and must close within the next 999 lines. Markdownlint-style disable and enable comments may target all supported rules or named rule IDs and aliases.

Scope and Privacy Notes:

The Markdown and optional local file stay in the browser tab and are not sent to a linting service. The checker reads text and reports findings without rendering, rewriting, or executing the document.

  • The rules are a reviewed subset with familiar markdownlint IDs; they are not a complete replacement for every markdownlint rule or project plugin.
  • Link destinations are not fetched, and embedded HTML is not analyzed for security.
  • Final parser behavior, CSS, anchors, and publishing restrictions still need a destination-specific preview or build.

References: