Boldify

Why Bold Text Breaks in Outlook (and What to Do)

By Fiaz Ahmad · Updated October 30, 2026

You copied bold text from a generator, pasted it into an Outlook email, and something went wrong: the bold words sit in a different font from the rest of the message, or they're a different size, or the recipient got a row of question marks. None of that is your mistake, and it isn't really Outlook's either. Generator "bold" isn't bold text — it's different characters, and Outlook handles unusual characters in ways that web apps don't. Here's exactly what happens, and the fix that makes the problem disappear.

What that "bold" text actually is

When a bold text generator bolds the letter A, it doesn't apply formatting. It replaces A (Unicode code point U+0041) with 𝐀 — U+1D400, Mathematical Bold Capital A, from a Unicode block called Mathematical Alphanumeric Symbols that was designed for typesetting equations. It's a separate character, the way é is separate from e. The "bolding" is baked into which character it is, not into any formatting layer. That's what lets it survive platforms that strip formatting — and it's also the root of every Outlook symptom below. (The full comparison lives in Unicode bold vs real bold.)

Symptom 1: the bold words render in a mismatched font

Outlook composes mail in Calibri by default — Aptos in current Microsoft 365 builds. Neither font contains glyphs for the Mathematical Alphanumeric Symbols block. These characters live in Unicode's Supplementary Multilingual Plane, far beyond what a standard body-text font covers.

When a font has no glyph for a character, Windows doesn't show nothing — it silently substitutes another installed font that does have it, usually Cambria Math or Segoe UI Symbol. So your "bolded" words render in a different typeface, at a different weight, often a visibly different size and baseline, sitting inside otherwise-normal Calibri text. That's the "format disturbed" look. It isn't a paste error, and retyping won't fix it — the characters themselves demand a font your email font can't supply.

Symptom 2: the recipient sees question marks

This one is specific to classic Outlook for Windows. Under File › Options › Advanced › International Options, Outlook has a setting called "Automatically select encoding for outgoing messages". When it's on, Outlook guesses an encoding for each outgoing message — and when it guesses a non-Unicode encoding, every character outside that encoding is replaced with ? at send time. Your email leaves your outbox already damaged; nothing the recipient does can recover it.

Microsoft documents this as a known issue affecting classic Outlook builds through 2603, with a fix shipped in the March 2026 updates. The sender-side workaround is to uncheck that auto-select option and set the preferred encoding to Unicode (UTF-8). That works — for you. It does nothing for the colleague, client or recipient who replies with your styled text quoted, or forwards it from their own un-patched Outlook. You can't ask everyone in a thread to change an encoding setting, which is why the real fix is to stop sending these characters in email at all.

The costs you don't see

Even when the styled text renders perfectly, three things are quietly broken:

  • Search can't find it. Outlook's search looks for the letters d-e-a-d-l-i-n-e. A bolded 𝐝𝐞𝐚𝐝𝐥𝐢𝐧𝐞 is a different sequence of characters, so searching the mailbox for the word later finds nothing — including for you, in your own Sent folder.
  • Spell check flags every styled word. To the proofing tools, they're not words at all, so your carefully emphasized phrases arrive with red squiggles under them in replies and forwards.
  • Screen readers spell them out. A blind recipient's screen reader announces "mathematical bold capital D, mathematical bold small e…" character by character, or skips the word. One styled word is an annoyance; a styled paragraph makes the email unreadable.

The fix: send real bold instead

Email is not a platform that forbids formatting — it's where formatting was practically invented. Outlook, Gmail and Apple Mail all send HTML mail, and HTML bold (<strong>) renders in the recipient's own font, survives every encoding, stays searchable, and reads normally to screen readers.

That's what our editor's Copy as Rich Text button is for. It puts two versions of your text on the clipboard at once: a text/html flavour with real <strong> tags, and a plain-text fallback. Paste into Outlook, Gmail, Word or Google Docs and you get genuine bold — native, in the message font, indistinguishable from bold applied by hand. Paste into something that only accepts plain text and the fallback appears instead. Write once, and the clipboard does the routing.

Try it

Draft your email, bold the key points (or let AI do it), and copy as rich text — ready to paste into Outlook or Gmail.

Open the Email Text Generator

The one place Unicode bold belongs in email

Subject lines. No mail client allows formatting there, so a Unicode 𝐛𝐨𝐥𝐝 word is the only way to make a subject stand out in a crowded inbox. Keep it to one or two words — heavily styled subjects are a spam-filter signal, and on devices without the right fonts they degrade to boxes. For the message body, rich text wins every time; this is the honest division of labour between a bold text generator's two copy buttons.

FAQ

Why does the bold text look fine in Gmail but break in Outlook?

Gmail renders in the browser, where font fallback across web fonts is smoother and encoding is always UTF-8. Outlook composes in a specific desktop font (Calibri or Aptos) with no glyphs for these characters, and classic Outlook's outgoing encoding can mangle them entirely. Same characters, stricter environment.

My recipient got question marks. Can the email be repaired?

No — the substitution happened at send time, so the original characters are gone from that message. Re-send using rich-text bold, or fix the encoding setting (File › Options › Advanced › International Options › set Unicode UTF-8) before sending again.

Does the March 2026 Outlook update fix everything?

It fixes the question-mark encoding bug in classic Outlook. It does not change font fallback — Calibri and Aptos still have no glyphs for mathematical alphanumerics, so the mismatched-font look remains. Rich text is still the right approach for email bodies.

Is this problem unique to Outlook?

Outlook is where it bites hardest, but the same mechanics apply anywhere with fixed fonts or legacy encodings — some webmail clients, older Android mail apps, and plain-text ticketing systems. Any destination that supports real formatting should get real formatting.