How to reduce markdown storage size
- Step 1Open the Markdown Minifier — Load the tool. There are no settings to choose — compression is a single fixed transform.
- Step 2Provide the document to compress — Paste the Markdown or drop one
.md,.mdx, or.markdownfile. One file per run; for bulk archives, process files individually or on a higher tier. - Step 3Run compression — The minifier strips HTML comments, collapses 3+ blank lines to one, trims trailing spaces, and tightens heading spacing.
- Step 4Measure the character delta — Compare input and output length. For storage planning, the character count is the figure that matters against CMS and column limits.
- Step 5Confirm content-affecting passes are safe — If the document has trailing-space hard breaks or comments inside code fences, check the edge cases before you archive the compressed copy.
- Step 6Store the .min.md output — Save the result (downloads end in
.min.md) into your storage system, database column, or backup set.
Compression passes and storage impact
What each pass removes and how it affects stored size. All passes always run; there are no options.
| Pass | Removes | Storage effect |
|---|---|---|
| Strip HTML comments | Every <!-- ... --> block, multi-line included | Largest gains on comment-heavy archives |
| Collapse blank lines | Runs of 3+ blank lines down to one | Recovers vertical whitespace from edit history |
| Trim trailing spaces | End-of-line padding on every line | Steady per-line byte savings |
| Tighten headings | Blank lines around ATX headings | Small savings, denser source |
Markdown tier limits (bytes and characters)
Storage and input limits for the markdown tool family. The character limit is distinct from the file-size limit — both apply.
| Tier | Max file size | Max characters | Files per run |
|---|---|---|---|
| Free | 1 MB | 500,000 | 1 |
| Pro | 10 MB | 5,000,000 | 10 |
| Pro-media | 50 MB | 20,000,000 | 50 |
| Developer | 500 MB | Unlimited | Unlimited |
Cookbook
Storage savings come from removing source-only bytes. These samples show the four passes that drive the character-count reduction, run in fixed order on the body.
Archived article with stale review comments
Long-lived documents collect review notes in HTML comments. Compression removes all of them and the blank lines they occupied, trimming the stored character count.
Before: # Onboarding <!-- reviewed 2024 --> <!-- reviewed 2025: still valid --> Welcome aboard. After: # Onboarding Welcome aboard.
Edit history that left blank-line buildup
Merges and copy-paste leave 3, 4, or more blank lines between sections. Compression collapses each run to a single blank line.
Before: Section A. Section B. Section C. After: Section A. Section B. Section C.
Trailing-space padding across a long document
A wrapping editor can leave trailing spaces on hundreds of lines. Each one is a stored byte. Compression trims them all.
Before (· = trailing space): The quarterly report shows··· growth across all regions.·· After: The quarterly report shows growth across all regions.
Frontmatter survives compression
When archiving CMS posts, metadata must stay intact. The frontmatter block is split off and re-attached unchanged while the body compresses.
Before: +++ title = "Q2 Report" weight = 5 +++ Body text here. After: +++ title = "Q2 Report" weight = 5 +++ Body text here.
Character count against a CMS field limit
When a CMS field caps content at a character count, compression removes the source-only characters first so prose fits without cuts.
Input: 4,210 characters (with comments + blank runs) Output: 3,640 characters (compressed) Field limit: 4,000 characters Result: fits after compression; before, it was rejected.
Edge cases and what actually happens
Compression alone does not gzip
By designThis is plain-text source optimisation, not wire compression. For the smallest stored or transferred size, gzip or brotli the .min.md output as well — the two layers stack.
Two-trailing-space hard line breaks removed
Changes renderingThe trailing-space pass strips the two-space hard-break marker. If archived content relies on it, the rendered line breaks will merge. Convert to backslash line breaks before compressing.
Comments inside code fences are stripped
Changes contentThe comment pass is not fence-aware, so <!-- --> shown inside a code block is removed. If your archive documents HTML comments as code samples, store the unminified copy.
Trailing whitespace in code is trimmed
Changes contentWhitespace-significant code (test fixtures, whitespace-delimited data inside fences) loses its trailing spaces. Keep the original if those bytes are meaningful.
Character limit reached, not file-size limit
413 rejectedThe markdown tier enforces a character cap separate from the byte cap. A document under 1 MB can still exceed Free's 500,000-character limit. Upgrade to Pro (5,000,000) or higher for larger documents.
Frontmatter is not compressed
PreservedOnly the body is minified. A document whose bulk is metadata in frontmatter will see little reduction — that is expected, since the metadata is kept verbatim.
Already-compact document
PreservedA document with no comments, single blank lines, and no trailing spaces is returned nearly identical. A negligible delta is the correct outcome.
Bulk archive of many files
Single-file onlyThe minifier handles one file per run. To compress a whole archive, automate per-file runs or use a tier that allows a larger batch (Pro 10, Pro-media 50).
Frequently asked questions
Is this the same as gzip?
No. Markdown minification is plain-text source optimisation. For wire-level compression, gzip the minified output too — the smallest size comes from both layers together.
Will it preserve frontmatter?
Yes. YAML (---) and TOML (+++) frontmatter is preserved exactly. Only the body content is compressed.
Which limit matters for storage — bytes or characters?
Both are enforced. The markdown tier has a character limit (Free 500,000) separate from the byte limit (Free 1 MB). For CMS fields that count characters, the character figure is what to watch.
How much storage will I save?
It scales with how many comments, blank-line runs, and trailing spaces the document carries. Heavily annotated archives shrink most; lean documents barely change.
Does it change the rendered output?
Usually not — the removed bytes are source-only. Exceptions are two-space hard line breaks and comments inside code fences. Review the edge cases before archiving.
Can I compress many files at once?
Not in one run — the minifier is single-file. Process files individually, or move to a tier with a larger batch allowance for bulk archives.
Are there any settings?
No. Compression is a fixed, zero-configuration transform. The output is deterministic for a given input.
Is my content uploaded?
No. The minifier runs in your browser; documents never reach a server.
What about content inside code blocks?
Code text is rewritten by the same passes — trailing spaces are trimmed and any <!-- --> is removed. If code bytes are significant, keep the original.
Should I store the minified version as my source of truth?
Keep the readable source in version control and store the minified copy only where space is the constraint. Minified Markdown is harder to diff.
How do I split a document that is still too large after compression?
If compressed prose still exceeds a limit, use the Markdown Splitter to break it into smaller documents. To combine many small files into one archive first, use the Markdown Merger.
What if I want a readable archive instead of a compressed one?
For a tidy, human-readable stored copy rather than a compact one, run the Prettifier — it normalises spacing for reading instead of stripping it for size.
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.