Markdown Minifier
Markdown Minifier trims the whitespace that builds up in Markdown files without breaking their structure. It removes trailing spaces and tabs, collapses runs of blank lines to one, converts line endings to LF and trims the start and end of the document, while leaving fenced code blocks exactly as they are. Processing happens on the server, up to 200,000 characters.
Use Markdown Minifier
Read Content
A safe, conservative Markdown minifier
Markdown Minifier shrinks a Markdown file by removing whitespace that does not change how the document renders in most cases, while keeping the file valid and still readable by a person. It is not an aggressive compressor that joins everything onto one line. Markdown depends on line breaks and blank lines for its structure, so squeezing those out would break headings, lists and paragraphs. Instead, the minifier targets the waste that builds up in real documents: trailing spaces, stacks of empty lines, and blank space at the start and end of the file.
Exactly what gets removed
The rules below come straight from the minify routine the tool calls, so you can predict the output before you run it.
| Rule | Outside code fences | Inside code fences |
|---|---|---|
| Windows (CRLF) and old Mac (CR) line endings | Converted to LF | Converted to LF |
| Spaces and tabs at the end of a line | Removed | Kept exactly |
| Two or more blank lines in a row | Collapsed to one blank line | Kept exactly |
| Indentation at the start of a line | Kept | Kept |
| Blank lines and spaces at the very start and end of the document | Removed | |
A line counts as blank if it contains only spaces or tabs. The fence lines themselves (the ``` or ~~~ lines) have their trailing spaces trimmed, but the code between them is passed through byte for byte. That matters for languages such as Python or YAML, and for diff output, where whitespace can be meaningful.
Leading indentation is never touched, so nested list items, indented code blocks and block quotes keep their structure.
Where the work happens
When you click Minify, the page sends your Markdown to the site's Markdown API, the server applies the rules above and returns the result, which is placed in the Minified Output editor. The endpoint returns the minified text and does not store it. The request is validated on the server and accepts up to 200,000 characters; longer input is refused with an error message rather than being cut silently.
Using the minifier
- Paste your document into Input Markdown or click Paste in the header to read it from the clipboard.
- Click Minify. The button shows "Working" while the request runs.
- Compare the footers. Each editor shows its character count and word count, so you can see how many characters were saved. The word count should stay the same, because only whitespace is removed.
- Use the copy icon on the output card to copy the result, or the download icon to save
minified-markdown.md. - The trash icon on the input card clears both editors.
Before and after
Consider a note copied from a word processor. It has two trailing spaces after the heading, four empty lines between sections, a tab at the end of a list item, and three empty lines at the bottom of the file. After minifying:
- the heading line ends right after its last word,
- the four empty lines become one, which is all Markdown needs to separate blocks,
- the tab after the list item is gone,
- the file ends on its last line of real content.
The rendered page looks the same in a typical renderer, but the source is shorter and produces cleaner diffs in version control.
Why minify Markdown at all?
- Storage in compact fields. The tool's own tip suggests it for Markdown stored in databases, APIs or compact text fields, where every character can count against a limit.
- Cleaner commits. Trailing whitespace shows up as noise in code review. Removing it once stops it reappearing in unrelated diffs.
- Prompt and token budgets. When Markdown is sent to a language model or a search index, redundant blank lines waste space without adding meaning.
- Consistency across contributors. Files edited on different operating systems end up with mixed line endings. The minifier normalises them all to LF.
Important caution: hard line breaks
In Markdown, ending a line with two or more spaces creates a hard line break, a <br> inside the same paragraph. Poems, addresses and signature blocks often rely on this. Because the minifier removes all trailing spaces outside code fences, those hard breaks disappear and the lines will join into one paragraph when rendered. If your document uses this feature, switch those breaks to a backslash at the end of the line (\) or to an HTML <br> before minifying, or do not minify that file.
What not to use it for
- Do not expect large size reductions on already tidy files. If there is little trailing whitespace and few blank lines, there is little to remove.
- Do not use it to strip formatting. Headings, emphasis, links and HTML are kept. For removing tags use Markdown Remove HTML.
- Do not use it when you need zero blank lines. The minifier always keeps one blank line between blocks because Markdown needs it. If you really want every blank line gone, Markdown Remove Empty Lines does that, with the side effects it explains.
- Do not rely on it to fix broken code fences. An unclosed fence means everything after it is treated as code and left untouched.
Limitations
- Maximum input is 200,000 characters per request.
- Requires a network connection, since minification is done by the API.
- Only the whitespace rules listed above are applied. The tool does not shorten link syntax, reflow paragraphs or remove comments.
- Whitespace inside fenced code blocks is left alone, which is a feature, but it means trailing spaces inside code remain.
- Indented code blocks (four spaces, no fence) are treated as ordinary text, so trailing spaces on those lines are trimmed and extra blank lines between them are collapsed.
Checking the result before you replace the original
A minified file should be a drop-in replacement for the original, but a short check is sensible on anything important. First, confirm the word counts in the two footers match; a difference means something other than whitespace changed, most often because an unclosed fence made the tool treat part of the document differently than you expected. Second, search the original for lines ending in two spaces, the hard-break pattern described above, and decide whether you need them. Third, if the file lives in Git, replace it and look at the diff: you should see only removed trailing whitespace, removed blank lines and, if the file had them, line ending changes. Any edit to visible words means you should go back to the original. Once you are happy, consider adding an editor setting such as "trim trailing whitespace on save" so the file stays clean without running the tool again.
Frequently Asked Questions
FAQ
Comments (0)
Describe the issue you encountered so we can investigate and improve the tool.