How to reduce markdown size for cms imports
- Step 1Open the Markdown Minifier — Load the tool. There is nothing to configure — shrinking is one fixed transform.
- Step 2Drop the oversized post — Paste or drop the
.md,.mdx, or.markdownfile your CMS rejected. One post per run. - Step 3Run the shrink — Comments are removed, 3+ blank lines collapse to one, trailing spaces are trimmed, and heading gaps close.
- Step 4Check the new character count — Compare the output length to your CMS field limit. The character figure is what the field measures.
- Step 5Re-attempt the import — Import the
.min.mdoutput. If it now fits, you are done; if not, see the edge cases for splitting. - Step 6Keep the readable source — Archive the unminified original in version control; import only the shrunk copy into the CMS.
Shrink passes for CMS fit
The four passes that reduce a post's size. None of them rewrite prose; all of them always run.
| Pass | Removes | Helps with |
|---|---|---|
| Strip comments | Every <!-- ... --> block | Legacy migration notes left in the body |
| Collapse blank lines | Runs of 3+ blanks to one | Lossy-export vertical whitespace |
| Trim trailing spaces | End-of-line padding | Invisible bytes from old editors |
| Tighten headings | Blank lines around ATX headings | Marginal extra character savings |
Real CMS field limits to size against
Common platform limits as of 2026. Verify the current value in your CMS; vendors change these. Minification reduces the count you compare against.
| Platform | Practical limit | What to do if still too big |
|---|---|---|
| WordPress (post content) | MySQL TEXT ~65,535 bytes per column | Minified posts rarely hit this; if so, split with the Splitter |
| Ghost (post) | Large but editor/import limits apply | Shrink first; split very long posts |
| Webflow (rich-text field) | Field character cap | Shrink to fit, or split across multiple items |
| Generic char-capped field | Counts characters, not bytes | Shrink reduces the character figure directly |
Cookbook
Shrinking targets source-only bulk so the prose stays whole. These samples show the passes and how the character count moves against a typical CMS limit.
Legacy export full of migration comments
Exports from an old platform often embed migration markers in HTML comments. Stripping them and their blank lines reclaims characters before re-import.
Before: # Welcome <!-- migrated from Drupal node 4821 --> Thanks for joining. <!-- old taxonomy: news, updates --> After: # Welcome Thanks for joining.
Lossy export blank-line buildup
Some exporters double or triple every blank line. Collapsing the runs cuts characters without altering structure.
Before: Intro. Section. Conclusion. After: Intro. Section. Conclusion.
Character count crossing under a field cap
A Webflow rich-text field rejected a post over its character limit. Shrinking removed enough source-only characters to fit.
Field limit: 20,000 characters Before shrink: 20,640 characters -> rejected After shrink: 19,180 characters -> imports cleanly
Frontmatter the importer maps stays intact
Migration scripts read frontmatter for slug and date. The shrink keeps that block exactly so the mapping still works.
Before: --- title: "Old Post" slug: old-post date: 2023-04-01 --- <!-- legacy id 99 --> Body. After: --- title: "Old Post" slug: old-post date: 2023-04-01 --- Body.
When prose itself is the limit
If a post is over the cap because the prose is genuinely long, minification cannot help — the right move is to split it.
Field limit: 10,000 characters After shrink: 14,800 characters -> still too big Next step: split into 2 posts with md-splitter, or publish as a multi-part series.
Edge cases and what actually happens
Post is still too big after shrinking
Too longIf minified prose still exceeds the field limit, the content itself is the constraint. Use the Markdown Splitter to break it into multiple posts or a series.
WordPress TEXT column limit
Rarely hitWordPress stores post content in a MySQL TEXT column (~65,535 bytes). Minified Markdown almost never reaches this; if it does, splitting the post is the fix.
Two-trailing-space hard line breaks removed
Changes renderingThe trailing-space pass removes two-space hard breaks. If migrated content used them for poetry or addresses, the lines will merge in the CMS. Convert to backslash breaks first.
Comments inside fenced code samples stripped
Changes contentA tutorial post showing <!-- --> inside a code fence will have that comment removed, because the comment pass is not fence-aware. Keep the unshrunk copy for such posts.
CMS counts characters, not bytes
By designMost field caps are character-based. The markdown tier also counts characters, so shrinking directly lowers the figure your CMS measures — verify against the field's character count, not the file's byte size.
Input exceeds the tier character limit
413 rejectedFree input is capped at 500,000 characters / 1 MB. A very large migration file needs Pro (5,000,000 / 10 MB) or above before it can be shrunk.
Frontmatter is not shrunk
PreservedOnly the body is minified. A post whose size lives mostly in a large frontmatter block will not shrink much — the metadata is kept verbatim by design.
Already-tight post
PreservedA clean post with no comments and single blank lines returns almost unchanged. A small delta is expected, not a failure.
Frequently asked questions
What if it's still too big after shrinking?
Then the prose itself exceeds the limit. Use the Markdown Splitter to break the post into smaller pieces or a multi-part series.
Will WordPress accept the shrunk post?
Almost always. WordPress stores content in a MySQL TEXT column (~65,535 bytes); minified Markdown rarely approaches that. If it does, split the post.
Does it work for Ghost and Webflow?
Yes. Both have editor or field limits that shrinking helps you stay under. Webflow rich-text fields are character-capped, which the shrink targets directly.
Does the CMS limit count characters or bytes?
Usually characters. The markdown tier also counts characters, so the shrink reduces exactly the figure your field measures. Check against the character count, not file size.
Will my migration frontmatter survive?
Yes. YAML and TOML frontmatter is preserved byte-for-byte, so the slug, title, and date your importer maps remain intact.
Could shrinking change how the post renders?
Removed comments and whitespace are source-only. The exceptions are two-space hard line breaks and <!-- --> shown inside code fences — review the edge cases.
Can I shrink many posts at once?
Not in one run — it is single-file. Process posts individually or use a tier with a larger batch allowance for a bulk migration.
Are there options to tune the shrink?
No. It is a fixed, zero-configuration transform, so results are predictable across an entire migration.
Is my content uploaded during migration?
No. The tool runs in your browser, so client content stays local.
How much will a typical post shrink?
It depends on leftover comments and whitespace. Legacy exports with migration markers shrink most; clean posts barely change.
What if I need clean public output, not just smaller?
The shrink also removes comments and trailing whitespace, so it doubles as a pre-publish cleanup. For metadata fields, the Frontmatter Builder helps shape the block your CMS imports, and the Prettifier normalises spacing if your CMS expects readable source.
What is the downloaded file named?
The output uses a .min.md suffix (for example post.md becomes post.min.md), so the shrunk copy sits next to your source.
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.