Because they are two different systems. Your bold "font" is Unicode look-alike characters. They paste and survive anywhere as plain text: captions, bios, display names. If it fails in a comment box, that field is either stripping non-standard characters or expecting the app's own markdown instead.
The confusing part is that both boxes look like they should behave the same. They don't. A caption and a comment can run on different input rules even inside the same app, and that one difference is why your styled text lands in one and breaks in the other.
What is actually in your "bold" text?
When you use a generator like BoldlyType, you aren't installing a font. You're copying real Unicode characters. The bold 𝗕 is code point U+1D5D5, a distinct character from the normal B (U+0042). These live in the Unicode "Mathematical Alphanumeric Symbols" block and cover only Latin letters and digits.
Because they're ordinary text characters rather than styling instructions, they travel with a copy-paste the same way an emoji does. That's why the same string works across Instagram, X, LinkedIn, TikTok and most bios. Nothing is being rendered. The characters simply are what they are. So when a field refuses them, the field is doing something to the characters, not to a font.
There are three common reasons a comment box (or reply, or search bar) rejects text a caption accepted:
| Reason | What's happening | Typical symptom |
|---|
| The field strips non-standard characters | Comment/username fields often allow-list a narrow character set for spam and safety reasons | Your text posts as blank, plain, or with characters dropped |
| The field is a plain-text-only input | Some inputs deliberately normalize everything to basic ASCII | Bold pastes but shows as normal letters |
| You're in a native-markdown field | The box wants the app's own bold syntax, not Unicode | Nothing styles, or your asterisks show literally |
| A length/validation limit trips | Unicode characters can count as multiple characters | Text is cut off or the field rejects it |
Captions are usually the most permissive field an app has, since they're built for expressive, long-form text. Comments, replies, display names and search boxes are more locked down, so they're where Unicode styling most often gets stripped. This is the same mechanism behind text showing up as empty boxes: the character exists, but that specific surface won't render or keep it.
Which fields most often strip or block styled text?
- Instagram comments are noticeably stricter than captions, and styling frequently drops.
- Usernames and display-name fields are heavily restricted on most platforms.
- Search bars normalize input so a search still matches plain text.
- In-app chat markdown fields, where bold is native markdown, expect the app's own syntax rather than pasted Unicode. This splits by app:
- WhatsApp bold is a single asterisk on each side:
*bold*.
- Discord bold is double asterisks:
**bold**.
- Telegram typed
**bold** (double asterisks) auto-converts reliably only on Telegram Desktop and Web. On mobile that typed-markdown conversion is inconsistent, so the dependable native path on every client is the selection/highlight menu (highlight the text, pick bold from the pop-up). See the full breakdown in our Telegram formatting guide and WhatsApp/Discord/Slack guide.
In those native-markdown boxes, pasted Unicode bold is unnecessary, and sometimes counter-productive, because it can trip accessibility and search. For a full walkthrough of building styled text that survives, see how to make stylish text.
Does using Unicode text where it doesn't belong cause problems?
It can, and this is the honest tradeoff. Unicode "font" characters are not read the same way as normal letters. Screen readers may announce them oddly, letter by letter, or skip them entirely, a real accessibility cost covered in are Unicode fonts accessible and screen readers and fancy text. Search and platform indexing can also treat "𝗯𝗼𝗹𝗱" as different from "bold," so styled keywords may not match queries.
On reach, there is no public evidence that Unicode styling itself triggers a shadowban, and no substantiated data for a secret penalty. What is real is the indirect effect. If a caption is unreadable to a screen reader or unsearchable, that can quietly cost you. Use styling for accents (a name, a heading, one line), not for whole blocks of body copy or every keyword.
How do I get the style to stick where it keeps breaking?
- Confirm the field, not the text, is the problem. Paste the same string into a caption or a note. If it works there, the comment box is stripping it.
- In native-markdown chat apps, use the app's own syntax. Single asterisk on WhatsApp, double on Discord, the highlight menu on Telegram mobile, instead of pasting Unicode.
- For strict fields, simplify. Try a lighter style (bold only), or fall back to plain text plus an emoji accent.
- Keep body copy plain. Style the hook or a name, and leave the rest readable and searchable.
You can test any of this in seconds with the bold text generator or the Instagram text formatter. Copy, paste into the target field, and see whether it survives before you post.
