How to normalize bold and italic style in markdown
- Step 1Paste the file to check — Paste the Markdown file you're bringing into compliance, or drop a single
.md. - Step 2Normalize combined emphasis —
***x***becomes**_x_**,___x___becomes__*x*__,**__x__**collapses, and padded markers are trimmed in one pass. - Step 3Understand what's out of scope — Plain
**bold**vs__bold__style is NOT unified by this tool. If your guide mandates one, that requires a separate find/replace policy. - Step 4Review remaining markers — Literal asterisks left in output mean unmatched or one-sided markers — fix those manually; the tool will not balance them.
- Step 5Copy the compliant file — Copy the normalized Markdown back, or download the
.md. - Step 6Apply repo-wide — Run each file through the cleaner; because the rules are idempotent, the whole repo converges to the same combined-emphasis form.
Combined-emphasis normalization
How each combined or redundant form maps to the canonical output.
| Source form | Canonical output | Renders as |
|---|---|---|
***text*** | **_text_** | bold + italic |
___text___ | __*text*__ | bold + italic |
**__text__** | **text** | bold |
****text**** | ***_text_*** (see edge cases) | bold + italic |
** text ** | **text** | bold |
* text * | *text* | italic |
Out of scope for style normalization
Critical for style-guide work — these are NOT changed, so don't rely on the tool for them.
| Style rule | Handled? | Note |
|---|---|---|
**bold** to __bold__ (or reverse) | No | Single-style bold is not converted between markers |
*italic* to _italic_ (or reverse) | No | Single-style italic is not converted between markers |
| Balancing unmatched markers | No | Unclosed markers are preserved as-is |
One-sided padding ** text** | No | Trim requires symmetric whitespace |
| Heading or list style | No | Use the prettifier or linter for those |
Tier limits
Markdown-family limits; charLimit is independent of file 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 showing exactly which style variations converge and which are deliberately left alone.
Three combined-emphasis variants converge
Different files used different combined forms; all asterisk triples normalize to the same output.
Before: A: ***alpha*** B: ****beta**** C: *****gamma***** After: A: **_alpha_** B: ***_beta_*** C: **_gamma_**
Redundant double-strong removed
A merge introduced a non-compliant double-strong wrapper.
Before: **__Compliant?__** not yet. After: **Compliant?** not yet.
Underscore triple standardised
An underscore-style file used ___ for combined emphasis.
Before: This is ___critical___ guidance. After: This is __*critical*__ guidance.
Single-style bold is left as-is
Proof the tool does not convert asterisk vs underscore for plain bold.
Before: Asterisk **bold** and underscore __bold__. After: Asterisk **bold** and underscore __bold__.
Padded markers trimmed for compliance
Whitespace inside markers violates the guide and breaks rendering.
Before: The rule is ** mandatory ** and * enforced *. After: The rule is **mandatory** and *enforced*.
Edge cases and what actually happens
Asterisk vs underscore not unified
By designPlain **bold** and __bold__ both pass through unchanged. This tool standardises combined emphasis, not single-style marker choice.
`****text****` ordering
By designThe *** rule fires before the quad rule, so ****text**** becomes ***_text_***, not **text**. The result is still combined emphasis but with a triple wrapper.
Five-marker run `*****text*****`
NormalizedThe inner ***...*** match dominates, producing **_text_** — the canonical combined form.
Unmatched marker
PreservedNo balancing logic. An unclosed ** stays as written; a style guide needs a human to close it.
One-sided padding
Preserved** text** is not trimmed because trim requires whitespace on both sides.
Inline code style example
ModifiedInline backtick spans are not protected, so a ` *example* ` in your style doc would be rewritten. Use a fenced block.
Fenced code untouched
PreservedTriple-backtick blocks pass through unchanged, so code samples illustrating markers stay literal.
Empty `****`/`____`
RemovedEmpty quad runs are deleted, which no style guide permits; surrounding spaces may collapse.
Already-compliant file
UnchangedFiles already using **_text_** for combined emphasis are not modified — the rules are idempotent.
Repo-wide consistency
ExpectedRunning every file produces the same combined-emphasis notation, but it will not unify single-style asterisk/underscore choice across the repo.
Frequently asked questions
Does it convert all italics to underscores (or asterisks)?
No. Single-style *italic* and _italic_ both pass through unchanged. The tool standardises combined bold+italic, not single-marker choice.
What is the canonical combined form?
**_text_** for asterisk style and __*text*__ for underscore style. ***text*** and ___text___ are rewritten to these.
Why does `****text****` become `***_text_***`?
The ***...*** rule runs before the quad rule, so the inner triple is matched first. Inspect quad markers manually if you need plain bold.
Does it remove double-strong `**__text__**`?
Yes — it collapses to **text**, removing the redundant nesting that no style guide allows.
Will it balance an unclosed marker?
No. Unmatched markers are preserved as-is so a reviewer can decide how to close them.
Can I enforce asterisk-only bold across a repo?
Not with this tool. It does not convert __bold__ to **bold**. That requires a separate find/replace or linter rule.
Is it idempotent for CI use?
Yes. Clean, normalized text is never changed on a second pass, so it converges files predictably.
Are style examples in code blocks safe?
Yes inside triple-backtick fences. Inline backtick spans are not protected and will be rewritten.
Does it trim padded markers?
Yes, when whitespace is symmetric: ** text ** becomes **text**. One-sided padding is preserved.
Is the file uploaded?
No. Processing is in-browser, so it fits a local check on private repositories.
Can it process my whole docs set at once?
No — one file per run. Combine files with the merger first if you want a single pass.
What handles the rest of my style guide?
Use the prettifier and linter for spacing, headings, and list style, and the GFM to CommonMark tool for dialect normalization.
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.