How to clean bold and italic before publishing markdown
- Step 1Paste the publish-ready draft — Paste the final Markdown headed for your CMS or static site, or drop the
.md. - Step 2Run the final emphasis pass — Padded markers are trimmed, empty
****/____removed,**__x__**collapsed, and***x***standardised in one pass. - Step 3QA the leftovers — Treat any remaining literal asterisks as a publish blocker — they signal an unmatched or one-sided marker the tool intentionally did not auto-fix.
- Step 4Verify code samples are intact — Confirm triple-backtick fenced blocks are byte-for-byte identical. Inline backtick spans are not protected, so review those.
- Step 5Publish the clean output — Copy the cleaned Markdown into your publishing pipeline, or download the final
.md. - Step 6Make it a checklist step — Add this pass to your pre-publish checklist. It is idempotent, so it never re-breaks already-clean copy.
Pre-publish emphasis checklist
What the final pass fixes automatically versus what you must verify by eye.
| Artifact | Auto-fixed? | Outcome |
|---|---|---|
** text ** padded | Yes | Trimmed to **text** |
**__text__** double-wrap | Yes | Collapsed to **text** |
***text*** triple | Yes | Standardised to **_text_** |
Empty **** / ____ | Yes | Deleted |
**unclosed marker | No | Preserved — manual fix required |
** one-sided** space | No | Preserved — manual fix required |
What stays untouched at the gate
Knowing these prevents a false sense of safety in your final QA.
| Case | Behaviour | QA action |
|---|---|---|
Unclosed ** | Preserved | Treat as a publish blocker; close it |
| One-sided padding | Preserved | Fix the asymmetric marker by hand |
Inline ` x | Modified | Review — inline code is not protected |
| 4-space indented code | Modified | Convert to a fenced block to protect it |
Fenced ``` ... ` | Preserved | Safe — passed through unchanged |
Tier limits
Markdown-family limits; charLimit is separate from byte size.
| 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
Before/after pairs from real pre-publish QA passes. The cleaned, publish-ready output is shown beneath each draft.
Headline that wouldn't render
A padded marker in the headline would have shipped as literal asterisks.
Before: ** Breaking: Q3 results beat forecast ** After: **Breaking: Q3 results beat forecast**
Double-wrapped intro collapsed
An earlier merge double-wrapped the standfirst.
Before: **__In short:__** the migration is complete. After: **In short:** the migration is complete.
Pull quote standardised
A triple-marker pull quote normalised for consistent rendering.
Before: > ***This changes everything.*** After: > **_This changes everything._**
Orphan markers removed
A deleted figure left empty bold markers in the body.
Before: The chart **** is shown above. After: The chart is shown above.
Code sample protected at publish
A fenced snippet is untouched while the surrounding caption is cleaned.
Before: Final step — ***deploy***: ```bash git push origin **main** ``` After: Final step — **_deploy_**: ```bash git push origin **main** ```
Edge cases and what actually happens
Unclosed marker reaches the gate
BlockerAn unclosed ** is preserved, not balanced. Treat any literal asterisk in the output as a publish blocker and close the marker before shipping.
One-sided padding `** text**`
PreservedTrim requires whitespace on both sides, so a one-sided space survives. Fix it by hand during QA.
`****text****` quad
NormalizedThe *** rule fires first, so ****text**** becomes ***_text_*** rather than **text**. Verify heavily wrapped spans manually before publishing.
Empty-marker space collapse
ExpectedRemoving **** joins surrounding words: chart **** is becomes chart is (the markers go, leaving the spaces). Re-check spacing after a deletion.
Inline code in the post
ModifiedInline backtick spans are not protected. A ` flag ` in body copy will be rewritten — review inline code before publish.
Indented code block
ModifiedOnly triple-backtick fences are detected. A 4-space-indented code block is treated as prose and its markers can change.
Fenced code in the post
PreservedTriple-backtick blocks pass through unchanged, so **main**-style examples in command samples stay literal.
Blockquote emphasis
NormalizedEmphasis inside a > blockquote is treated as prose, so a triple-marker pull quote is standardised to **_text_**.
Already-clean publish draft
UnchangedIf your draft is already clean, the final pass changes nothing — the rules are idempotent.
Draft exceeds char limit
RejectedFree tier caps at 500,000 characters and 1 MB. A long-form piece may hit charLimit before the byte size — split it or upgrade.
Frequently asked questions
Why run an emphasis pass right before publishing?
Padded or empty markers render as literal asterisks in a live post. A final pass trims and removes those so nothing ships broken.
Will it fix every emphasis problem automatically?
No. It trims symmetric padding, collapses double-strong, standardises triples, and removes empty runs — but it does not balance unmatched markers or fix one-sided spacing.
What should I treat as a publish blocker?
Any literal asterisk left in the output. That means an unmatched or one-sided marker the tool intentionally preserved for you to fix.
Are code samples safe at publish?
Yes inside triple-backtick fences. Inline backtick spans are not protected and should be reviewed before going live.
Does it standardise pull quotes?
Yes. Emphasis inside blockquotes is treated as prose, so ***quote*** becomes **_quote_**.
Why did `****text****` not become `**text**`?
The *** rule runs first, producing ***_text_***. Inspect quad-marker spans manually during QA if you need plain bold.
Is it safe as a repeatable checklist step?
Yes. The rules are idempotent, so a clean draft is never re-broken by running the pass again.
Does my scheduled post get uploaded?
No. Everything runs in the browser, so embargoed or scheduled content stays private until you publish.
Can I run my whole issue or newsletter at once?
Only as a single file. Combine sections first with the merger, clean here, then split if needed with the splitter.
What about final HTML output?
After cleaning, convert with md to HTML or md to GitHub HTML depending on your target rendering.
Should I lint or prettify too?
Yes — run the prettifier or linter for spacing, headings, and list consistency as part of the same checklist.
It removed a word's spacing after deleting `****` — expected?
Yes. Deleting an empty run pulls neighbouring text together. Re-check spacing wherever a figure or term was removed late in editing.
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.