Threads does not give you an italic button in the main composer. The 500 character post box stores plain text and does not read markdown, so italic text on Threads means pasting Unicode characters that are already italic in shape. The exception is a text attachment, the long form block Threads added in September 2026, which does carry native bold, italic, underline and strikethrough.
That split is the whole story on Threads, and it changes the advice depending on which of the two you are writing in.
The two composers
The main post. Up to 500 characters, plain text, no markup. What you type is what is stored. Typing *emphasis* leaves the asterisks visible.
A text attachment. Up to 10,000 characters, attached to a post and shown as an expandable block behind a “Read more” control. Text attachments launched in September 2026 with real formatting: bold, italic, underline and strikethrough are applied to the text rather than typed as markers.
A pattern has already settled among people writing long posts: converted characters in the visible 500 character portion, native formatting inside the attachment where the body lives. That is a reasonable split, as long as the converted part stays short.
Where styling works on Threads
| Field | Native formatting | Unicode | Recommended |
|---|---|---|---|
| Post (main composer) | No | Yes | Unicode, one short phrase |
| Reply | No | Yes | Unicode, sparingly |
| Text attachment | Yes | Yes | Native formatting |
| Bio | No | Yes | Unicode, keep keywords plain |
| Display name | No | Yes | Works, costs findability |
| Username | No | No | Not possible |
| Hashtag or tag | No | Technically | Do not, keep plain |
| Link preview title | No | No | Comes from the linked page |
Usernames come from the linked Instagram account and follow the same character restrictions, so converted characters are rejected rather than merely unwise. The display name is a separate field and will accept them.
Converting a phrase for a Threads post
- Write the post normally in the composer or somewhere you can edit it.
- Choose the one phrase that carries tone rather than information.
- Convert that phrase in the Italic Text Generator and copy the result.
- Paste it back into the composer in place of the plain phrase.
- Post, then open the post in the app and in a browser to check both render.
Do the conversion last. Once a phrase is converted, autocorrect and spell check stop working on it, so any typo you have not caught is now permanent unless you retype the whole run.
Keep the converted portion to one clause. Threads posts are read fast in a dense feed, and a fully styled post reads as noise rather than emphasis at that size.
Using formatting inside a text attachment
Where a text attachment is available, native formatting is the better tool for every reason that matters.
The letters stay letters. That means the text remains searchable, a reader can copy and edit it normally, spell check still works while you write, and a screen reader announces words rather than character names. None of those are true of converted characters.
The practical workflow is to draft the attachment first, apply emphasis with the attachment’s controls, and only then decide whether the 500 character post above it needs a converted phrase to set the tone. Most of the time it does not.
Replies behave like posts, and that matters more than it sounds
A reply on Threads runs through the same plain text field as a post, so converted characters work there identically. What differs is context.
A reply sits under someone else’s post, usually alongside several others, and it is read in a narrower column at a smaller size. Decorative characters that look deliberate in your own post read as attention seeking in a reply thread, and cursive script in particular becomes hard to read at reply size.
There is also a practical problem. Replies are where conversations happen, which means replies get quoted, screenshotted and answered. A converted phrase cannot be quoted back accurately by anyone typing rather than copying, and it cannot be corrected if you got a name wrong.
The workable rule: keep replies plain unless the styling is the joke. If you are quoting a book title, italic is a genuine typographic convention and one converted phrase is fine. If you are emphasising your own opinion, plain words do it better.
Threads also threads replies into chains. A long chain written entirely in converted characters becomes an unreadable wall for anyone whose device has patchy font coverage, and that failure compounds down the chain rather than affecting one post.
Threads search matches literal characters
Threads has in app search across posts, profiles and tags, and it matches text as typed. A converted word is a different sequence of code points from its plain spelling, so it does not come back from a search for the ordinary form.
That leads to a short list of things to keep plain:
- Your role, city, niche or anything else people search profiles for.
- Every hashtag. A styled tag is its own tag, with a feed nobody is browsing.
- Every @ mention. The mention picker matches plain text and will not resolve a converted handle.
- Product names, event names and dates.
Threads posts are also indexed by general web search, so the same principle applies twice over. Our piece on whether Unicode text hurts your SEO covers what a crawler does with these characters: they are not penalised, they are simply not read as words.
Anyone who has already worked through this on the other Meta app will recognise the trade. The Instagram bio and captions guide covers the same decision in fields with different limits, and the X guide is the closest comparison for a plain text feed with no formatting at all.
Where Threads differs from Instagram
The accounts are linked, so people assume the text fields behave identically. They do not.
Instagram’s bio and Threads’ bio are separate fields with separate limits, edited in different places. A Threads post is not an Instagram caption and does not inherit anything from one. The username is the shared piece, and it is the one field neither app will let you style.
The other difference is rhythm. Instagram captions sit under an image and are often read slowly. Threads posts are read in a fast scrolling text feed where every post is competing on the same visual terms. Converted characters are more noticeable there, which cuts both ways: they draw the eye, and they also read as more intrusive when overused.
What a screen reader does with a styled Threads post
Converted characters are not a font applied to letters. They are separate Unicode characters, and depending on the reader and its verbosity settings they can be announced one at a time by their full character names, read as unrecognised symbols, or skipped.
A single converted phrase in an otherwise plain post is a small cost. A styled bio is a larger one, because a bio is announced every time someone lands on the profile. A fully styled post is unreadable for that listener.
Native formatting inside a text attachment does not have this problem, which is another reason to keep the long form body there rather than styling it by conversion. What screen readers really announce goes through the readers individually.
Try it on Threads
- Write a post where the last line is a mood line rather than information.
- Convert only that last line, using Italic rather than a heavier decorative style.
- Post it, then view it in the app and in a desktop browser.
- Search Threads for a word from the styled line and confirm it does not return your post.
- Ask someone on an older Android phone whether the line renders or shows boxes.
Step four is the one that decides how you use this. Step five tells you how wide your font coverage risk actually is with your own audience.
Troubleshooting
Asterisks show up literally. The main composer has no markdown. Convert the characters rather than marking them up.
Digits refuse to go italic. Unicode’s italic range covers 52 letters and no digits, so a year or a price cannot be italic. Bold or monospace do include digits if the number has to look different.
One letter stayed upright inside an italic word. Almost always the letter h. Unicode has no dedicated italic h in the mathematical block, and a converter that does not substitute the correct alternative character leaves a plain h behind.
The phrase renders in the app and shows boxes in a browser. Font coverage differs between the two. It is the reading environment, not the post.
A styled hashtag got no engagement. It is a different tag from the plain one. Retype it plain.
Editing the post is painful. Expected, and the main practical argument for keeping the converted portion to a single short clause.
Questions people ask about Threads formatting
Does Threads have a native italic button? Not in the main composer. The 500 character box is plain text with no markdown parsing. Text attachments, added in September 2026, do have native bold, italic, underline and strikethrough.
How do you italicize on Threads? Convert the phrase to Unicode italic characters and paste it into the composer. Inside a text attachment, use the attachment’s own controls instead.
Does italic text work in a Threads bio? Converted characters render there on current builds. Keep your role, city and anything else people search for in ordinary letters.
Can you use styled hashtags? You can type one, but it becomes a separate tag with almost no traffic. Keep tags plain.
Is Threads formatting the same as Instagram? No. The accounts are linked and the username is shared, but the bio, the composer and the character limits are separate. Test each field rather than assuming.
The short answer for Threads
Two composers, two rules. In the 500 character post, converted characters are the only route to italic, so use one short phrase and keep every searchable word plain. In a text attachment, use the native formatting, because it keeps the words readable, searchable and editable. The username is off limits either way.
Behaviour described here reflects Threads as of September 2026, including the text attachment feature that shipped that month. Threads has added composer features quickly since launch, so check the current app before relying on any single field behaving as described.
