How to compress markdown for smaller file sizes
- Step 1Open the Markdown Minifier — Go to the tool page. There is nothing to configure — the minifier exposes no options, so you skip straight to providing input.
- Step 2Paste text or drop a single .md file — Paste your Markdown into the input box or drop one
.md,.mdx, or.markdownfile. The minifier processes one file at a time (acceptsMultipleis false); for many files at once, queue them with a Pro tier. - Step 3Run the minify pass — The tool removes HTML comments, collapses 3+ blank lines to one, trims trailing spaces, and tightens heading spacing — in that fixed order.
- Step 4Check the size delta — Compare the output length to the input. Comment-heavy or whitespace-padded files shrink most; tight prose changes little because there is less to remove.
- Step 5Verify hard line breaks and fenced comments — If your document relies on two-trailing-space hard line breaks or contains
<!-- -->inside a code fence, review the edge cases — both are affected by the trailing-space and comment passes. - Step 6Download the .min.md output — Save the result. Downloads are named with a
.min.mdsuffix (for exampleguide.mdbecomesguide.min.md) so the minified copy sits alongside the readable source.
What each minify pass does
The four transforms applied to the body, in execution order. There are no options to toggle any of them on or off — every pass always runs.
| Pass | Rule | What it removes | What it keeps |
|---|---|---|---|
| 1. Strip comments | Delete every <!-- ... --> block, including multi-line | All HTML comments anywhere in the body — even inside code fences | Visible prose, code, and any text outside comment syntax |
| 2. Collapse blank lines | Replace runs of 3+ newlines with 2 (one blank line) | Extra vertical whitespace from copy-paste and merges | Single blank lines between paragraphs (paragraph separation is required by CommonMark) |
| 3. Trim trailing spaces | Remove trailing spaces on every line | Invisible end-of-line padding left by editors | Leading indentation (list nesting, code indentation) is untouched |
| 4. Tighten headings | Remove blank lines immediately before and after ATX headings | Gaps around #–###### headings | The heading text and level; setext (===/---) headings are not specially handled |
What is preserved vs. what is rewritten
The minifier touches only the body. Knowing the boundary prevents surprises in build pipelines.
| Element | Behaviour | Why |
|---|---|---|
YAML frontmatter (---) | Preserved exactly | Split off before minifying and re-attached byte-for-byte |
TOML frontmatter (+++) | Preserved exactly | Same split logic recognises +++ fences |
| Fenced code content | Body text inside fences is rewritten by the same passes | The passes are not fence-aware — see edge cases |
| Trailing two-space line breaks | Trimmed away (changes rendering) | Pass 3 removes all trailing spaces, including hard-break markers |
| Single blank line between blocks | Kept | Pass 2 collapses to one blank line, not zero |
Cookbook
Each pass below runs in a fixed order on the document body only. Frontmatter is split off first and re-attached unchanged. These before/after samples show exactly what each pass removes.
Comment-heavy draft shrinks the most
Drafts full of editor notes lose every comment plus the blank lines those comments sat on. This is where the largest reductions come from.
Before: # Release Notes <!-- TODO: confirm version with QA --> We shipped v2. <!-- internal: link to Jira ticket --> Bug fixes included. After: # Release Notes We shipped v2. Bug fixes included.
Excess blank lines collapse to one
Runs of 3 or more blank lines become a single blank line. A single blank line stays — it separates CommonMark blocks.
Before: Paragraph one. Paragraph two. After: Paragraph one. Paragraph two.
Trailing spaces vanish
Every line loses its trailing spaces. Caution: two trailing spaces are Markdown's hard-line-break marker, so this pass removes them too.
Before (· = trailing space): Line with padding···· List item·· After: Line with padding List item
Heading gaps tighten
Blank lines directly before and after an ATX heading are removed. The heading itself is unchanged.
Before: Intro text. ## Setup Run the installer. After: Intro text. ## Setup Run the installer.
Frontmatter is left alone
The YAML block is detached before minifying and re-attached exactly, so dates, tags, and quoting survive verbatim while the body is compressed.
Before: --- title: My Post date: 2026-06-10 --- <!-- draft note --> Hello world. After: --- title: My Post date: 2026-06-10 --- Hello world.
Edge cases and what actually happens
Two-trailing-space hard line breaks are removed
Changes renderingMarkdown turns two spaces at the end of a line into a <br>. The trailing-space pass strips all trailing spaces, so those breaks disappear and the two lines render as one paragraph. If you rely on hard breaks, use a literal \ line break or a blank line instead before minifying.
HTML comments inside a code fence are deleted
Changes renderingThe comment pass is not fence-aware. A ``` html block containing <!-- example comment -->` will have that comment removed, even though it is sample code meant to be displayed. Move such examples out of the fence or skip the minifier for files that document HTML comments.
Trailing spaces inside code blocks are trimmed
Changes contentBecause the trailing-space pass runs over the whole body, significant trailing whitespace inside fenced or indented code (for example whitespace-sensitive test fixtures) is removed. Keep an unminified copy if your code samples depend on trailing spaces.
Setext headings are not tightened
By designThe heading passes match only ATX headings (#–######). A setext heading (text underlined with === or ---) is treated as ordinary text, so blank lines around it are not removed by the heading rules — though the general blank-line collapse still applies.
A single blank line is never removed
ExpectedThe blank-line pass collapses 3+ blank lines to one; it never removes the last blank line between two blocks. This is intentional — CommonMark needs a blank line to separate paragraphs, so removing it would change rendering.
File exceeds the Free 1 MB / 500,000-character limit
413 rejectedThe Free markdown tier caps input at 1 MB and 500,000 characters. A larger doc is rejected. Upgrade to Pro (10 MB / 5,000,000 chars), Pro-media (50 MB / 20,000,000 chars), or Developer (500 MB / unlimited) for big files.
Multiple files dropped at once
Single-file onlyThe minifier sets acceptsMultiple to false, so it processes one file per run. To minify a batch, run them one at a time or use a tier with a larger batch allowance (Pro 10, Pro-media 50).
Document has no comments or extra whitespace
PreservedAlready-tight prose with single blank lines and no comments comes out nearly identical — the only guaranteed change is a trimmed trailing newline normalisation. A near-zero size delta is the expected result, not an error.
Output is for shipping, not for committing
By designMinified Markdown is terser to read. Keep the readable source in version control and emit the .min.md at build time; do not replace your tracked file with the minified copy.
Frequently asked questions
Will minifying change how the page renders?
In most cases no — comments, extra blank lines, and trailing whitespace are source-only. The two exceptions are two-trailing-space hard line breaks and <!-- --> comments inside code fences, both of which the minifier removes. See the edge cases above.
Does it remove all blank lines?
No. It collapses runs of 3 or more blank lines to a single blank line and removes blank lines directly around ATX headings. A single blank line between paragraphs is always kept because CommonMark needs it.
What happens to my frontmatter?
YAML (---) and TOML (+++) frontmatter is split off before minifying and re-attached byte-for-byte. Dates, tags, and quoting are untouched.
Are there any options to configure?
No. The minifier is a fixed, zero-configuration transform — no toggles, sliders, or presets. The same input always produces the same output.
How much smaller will my file get?
It depends entirely on how much comment text and whitespace the file carries. Comment-heavy or loosely formatted drafts shrink noticeably; tight prose barely changes.
Does it gzip the file?
No. This is plain-text source minification, not wire compression. For the smallest transfer size, gzip the minified output at your CDN or server in addition.
Can it remove comments inside code samples?
Yes, and that can be a problem. The comment pass is not fence-aware, so an <!-- --> shown inside a code block gets deleted. Move such examples outside the fence if you need them displayed.
What file types can I drop?
A single .md, .mdx, or .markdown file, or pasted text. Output downloads with a .min.md suffix.
Is my document uploaded anywhere?
No. The minifier runs entirely in your browser; the file never leaves your machine.
How is this different from the Prettifier?
The Prettifier normalises spacing for readability (it adds blank lines around headings); the Minifier strips for size (it removes them). They are opposites — pick based on whether you want a readable or a compact source.
Should I commit the minified version?
Generally no. Keep readable Markdown in source control and generate the .min.md at build or deploy time so diffs stay reviewable.
What if the minified file is still too large?
If a single document is too big even after minifying, split it with the Markdown Splitter. To strip embedded secrets rather than comments, use the Secret Redactor.
Privacy first
All Markdown processing runs locally in your browser using JavaScript. No file is ever uploaded to JAD Apps servers — only metadata counters are saved for signed-in dashboard stats.