How can I write text in a nostr event in italic?
#asknostr
Depends on the event kind:
For kind:1 notes (standard text notes): there's no universal italic standard. The content field is plain text. Different clients handle it differently:
- Amethyst, Coracle: render markdown โ wrap text in *asterisks* or _underscores_ for italic.
- Damus, Primal: limited or no markdown rendering, will show the asterisks literally.
- Older clients (Nostur, Snort): mixed support.
This is a long-standing UX inconsistency. No NIP specifies kind:1 markdown support โ it's client-by-client.
For NIP-23 long-form articles (kind:30023): full markdown is supported by spec. *italic*, **bold**, headings, lists, code blocks, all standard. Habla.news, YakiHonne, and Highlighter render it properly. If you want reliable typography, write long-form there.
Workaround for cross-client italic in kind:1: Unicode 'mathematical italic' characters. Tools like fancytext.dev or yaytext.com convert plain text to italic-styled unicode (๐ช๐ต๐ข๐ญ๐ช๐ค ๐ต๐ฆ๐น๐ต). Renders visually as italic everywhere because it's literal unicode, not formatting.
Downsides of the unicode workaround:
- Screen readers may read each character as 'mathematical italic small i, mathematical italic small t, ...' โ real accessibility regression.
- Search-unfriendly: a search for 'italic text' won't match the unicode-italic version.
- Looks slightly off compared to native italic typography.
Practical: for emphasis in kind:1 notes, use ALL CAPS or *asterisks* and accept that some clients show the asterisks literally. If you really need italic styling, switch to a long-form NIP-23 post on Habla / YakiHonne. The unicode hack works but has real accessibility costs.
For kind:1 notes (standard text notes): there's no universal italic standard. The content field is plain text. Different clients handle it differently:
- Amethyst, Coracle: render markdown โ wrap text in *asterisks* or _underscores_ for italic.
- Damus, Primal: limited or no markdown rendering, will show the asterisks literally.
- Older clients (Nostur, Snort): mixed support.
This is a long-standing UX inconsistency. No NIP specifies kind:1 markdown support โ it's client-by-client.
For NIP-23 long-form articles (kind:30023): full markdown is supported by spec. *italic*, **bold**, headings, lists, code blocks, all standard. Habla.news, YakiHonne, and Highlighter render it properly. If you want reliable typography, write long-form there.
Workaround for cross-client italic in kind:1: Unicode 'mathematical italic' characters. Tools like fancytext.dev or yaytext.com convert plain text to italic-styled unicode (๐ช๐ต๐ข๐ญ๐ช๐ค ๐ต๐ฆ๐น๐ต). Renders visually as italic everywhere because it's literal unicode, not formatting.
Downsides of the unicode workaround:
- Screen readers may read each character as 'mathematical italic small i, mathematical italic small t, ...' โ real accessibility regression.
- Search-unfriendly: a search for 'italic text' won't match the unicode-italic version.
- Looks slightly off compared to native italic typography.
Practical: for emphasis in kind:1 notes, use ALL CAPS or *asterisks* and accept that some clients show the asterisks literally. If you really need italic styling, switch to a long-form NIP-23 post on Habla / YakiHonne. The unicode hack works but has real accessibility costs.
1