How do you write a comment in Markdown?

Use HTML comment syntax: . Most Markdown renderers strip these from the rendered output.

Where are comments useful?

Hiding TODOs, leaving section markers for editors, embedding metadata for static-site generators, and hiding draft notes from readers.

Will the comment ever show in the output?

On GitHub and most renderers, no. But some converters (older Pandoc setups, certain CMSs) may include them — verify in your target environment.

No. The comment is built in your browser locally.

wraps each line in  for hidden notes

Generate hidden Markdown comments

Wrap notes, TODOs, and review hints in HTML comments — invisible in rendered Markdown, but searchable in source.

Markdown Comments

Input

150 B

5 lines

Output

195 B

5 lines

Status

ready

live

Ratio

1.30×

out/in

input · notes

output · comments

<!-- TODO: rewrite this section -->
<!-- NOTE: image needs alt text -->
<!-- FIXME: link is dead -->
<!-- REVIEW: confirm copy with marketing -->
<!-- HACK: temporary workaround for issue #42 -->

Quick Start

How to add Markdown comments

HTML comments render as nothing in Markdown but stay in source — perfect for TODOs, draft notes, or review hints that shouldn't ship to readers.

01
List your notes
One note per line — TODO, NOTE, FIXME, anything.
Parsing runs through marked with GFM extensions enabled — tables, task lists, strikethrough, and fenced code blocks all match GitHub’s rendering.
inputGFMmarkedCommonMarklive
input · markdownnotes · GFM
```
TODO: ...
```
loaded · GFMGFM · ready
02
Wrap in comments
Each non-empty line becomes .
Soft-break behaviour is configurable: by default a single newline becomes a space (CommonMark), toggle on for chat-style <br> insertion.
wrapsoft-breaksoptionsconfiglive
out · optionshtml · live
```

```
options applied · livelive
03
Paste into Markdown
The comments are invisible in render but visible in source.
The preview is scoped under a .mde class so its CSS doesn’t bleed into the rest of the page. Output HTML is whitespace-controlled for clean diffs.
pastepreviewscoped CSSrenderstable
check · renderedok · ready
```
(rendered: blank)
```
rendered · liverendered
04
Search later
grep your repo for TODO/FIXME to find work items.
Export covers both raw Markdown and rendered HTML; downloads stream as text/markdown or text/html via Blob + object URL.
searchclipboard.md.htmlblob
✓ · exportedgrep · done
```
✓ found
```
tracked · ready to shipsuccess

Pro tips

Author Markdown that renders everywhere

GFM is the safe default

GitHub-Flavored Markdown is the de-facto baseline (tables, task lists, strikethrough). CommonMark is stricter but ubiquitous as a fallback.

Soft-break behaviour varies

A single newline is a space in CommonMark, a <br> in GFM. Toggle soft breaks when source matters.

Escape inside code fences

Backticks inside fenced blocks need a longer fence — three becomes four. Use ~~~ if your content has many backticks.

Anchors are slugified

GitHub lowercases, strips punctuation, and joins with hyphens. Duplicate headings get -1, -2 suffixes.

Tables need a header row

The dash row sets alignment (:---, :-:, ---:). Use Table Aligner for diff-friendly columns.

Front matter is YAML

Triple-dash blocks at the top of files are parsed by static-site generators. Use the Front-Matter Validator to catch syntax errors.

Use Cases

When to use Markdown comments

Hidden notes that survive in source but never render.

Inline TODOs

Leave TODOs in docs without exposing them to readers. Render path uses marked with GFM extensions enabled (tables, task lists, strikethrough, autolinks), so what you preview matches what GitHub publishes bit-for-bit. Soft-break behaviour is configurable for chat-style vs prose Markdown.

GFM-compliant

Review notes

Stage editor comments before publish without re-rendering. Pairs cleanly with the Markdown Cheatsheet for syntax you can't quite remember — callout blocks, footnotes, definition lists. Output stays diff-friendly so style-only changes don't drown out real edits in PRs.

GitHub-perfect

Frontmatter hints

Note origin or template name above the front matter block. Cross-platform safe: anchors, code fences, and tables behave identically on GitHub, GitLab, Bitbucket, and Gitea. Heading-anchor slugs follow GitHub's lowercase-and-hyphenate rules so deep links survive a docs migration.

diff-friendly

Section markers

Section markers for tooling that greps for tags. No server roundtrip — perfect for proprietary content you can't paste into a public tool. The full marked + GFM bundle ships with the page, so it works offline once loaded.

render-stable

Draft mode

Stash a paragraph in a comment instead of deleting it. Front matter (YAML / TOML / JSON) passes through unchanged so static-site pipelines (Jekyll, Hugo, Astro, Eleventy) read it correctly. Pair with the Front-Matter Validator to catch syntax errors before deploy.

cross-platform

License notes

Drop quick license / origin notes alongside the prose. Output is reproducible: identical input always produces identical Markdown, so doc-generation scripts can rely on it for snapshot tests and embedded into release workflows.

SEO-friendly

FAQ

Frequently asked questions

Will the comments show in GitHub render?

No. GitHub strips HTML comments before rendering — same as every CommonMark parser.

Are they searchable in the repo?

Yes. The text stays in the source file and is grep/ripgrep-friendly.

Will Markdown parsers strip them?

Most do — the HTML output omits comments. They survive on disk as long as the .md file is preserved.

Can I nest comments?

No, the HTML spec disallows it. Use one comment per line for safety.

Where does this run?

Locally in your browser — nothing is sent to a server.

Suggest a tool

Something missing?

Tell us what you need. We ship the top requests every two weeks.

47 in queue·8 shipped this month

Request queued. Thanks!