A linter for your Markdown, with explanations a human can read
Markdown looks simple until your README, your docs site or your blog post starts looking inconsistent: mixed list markers (bullet style), trailing whitespace, headings that skip a level (heading levels), fenced code blocks without a language tag. A renderer will still render the page, but the result is sloppy and the diff noise is enormous.
This tool runs the same engine as the CLI `markdownlint` (markdownlint) on your text. You get a numbered list of issues, each with the rule code (`MD009`, `MD040`, ...), a one-line description, and where it is auto-fixable a preview of the fix. Click a row, the textarea scrolls to that line.
Four presets cover the usual choices: Recommended (the default, sensible for any project), GitHub (GFM friendly), Strict (80-column lines plus no duplicate headings), Custom rules (everything turned on). Toggle Fix mode to see the cleaned text and copy it in one click.
How to use it
- Paste your Markdown into the big textarea on the left. A small sample with intentional issues is loaded by default so the tool has something to show right away.
- Pick a preset at the top: Recommended for almost every project, GitHub when your file is going on GitHub or GitLab, Strict for technical docs that want every rule on plus 80-column lines, Custom rules to turn on every available check.
- Click "Run lint". The right panel fills with a numbered list of issues. Each one shows the rule code (e.g. `MD040`), a short description, the relevant snippet, and an "auto-fix" badge if markdownlint can fix it for you.
- Click any issue row to jump to that line in the textarea. The line is selected so you can edit it directly. Useful for triaging dozens of issues without scrolling manually.
- Flip "Fix mode" to see the cleaned output instead of your raw input. All auto-fixable issues are applied. The structural ones (heading style, language tags, content errors) you fix by hand.
- Click "Copy" to grab either your raw input or the cleaned output (depending on Fix mode). That is the string you paste back into your README or doc.
- Read the FAQ below if you want to know what a specific rule means or which preset matches your team convention. Each rule code links to a short plain-language explanation.
When this is useful
Six concrete situations where a Markdown linter saves real time:
- Sanity-checking a README before pushing. You wrote 300 lines, you used `-` for bullets in the first half and `*` in the second, three of your code blocks are missing language tags so the syntax highlighter on GitHub renders them as monochrome. Lint, fix, push.
- Onboarding a docs site (Astro, Hugo, Docusaurus, MkDocs). The generator wraps every page in a layout. Bad Markdown shows up as mis-aligned tables, broken anchor links and inconsistent heading hierarchy in the sidebar. Linting before adding pages catches all of that.
- Code reviewing a colleague PR. They pasted Markdown from Notion, which loves to emit trailing whitespace and smart quotes. Lint, paste the list into the PR comment, "here are 12 things to fix".
- Cleaning up a tutorial before publishing on Medium or dev.to. Both platforms have their own Markdown quirks. Running the strict preset locally first eliminates the what-renders-where guessing game.
- Migrating from another platform. You exported posts from WordPress, Ghost or Substack as Markdown. They are full of inline HTML `<div>` wrappers, raw URLs that should be auto-linked, and headings that start at H2. The linter spots them all.
- Setting up a pre-commit hook in CI. Same rules used here go into a config file in your repo, you get a green check in your CI runs and a friendly comment on every PR that breaks them.