Styling Names Across Languages Without Losing Accents

Every style transform on this site is built the same way: it only converts a character it explicitly supports, and preserves everything else — accents, non-Latin letters, mixed scripts — exactly as typed. Styling a name should never mean losing part of it.

Worked examples

Why the "decomposed accent" case matters

Some accented letters can be typed or stored two different ways: as one precomposed character (é, a single code point) or as two: a plain "e" immediately followed by a separate combining accent mark. Both look identical on screen and count as one grapheme (see our grapheme-counting guide) — and this tool treats them identically too: as one non-ASCII-letter unit that an ASCII-only style leaves untouched, never as a detachable "e" that gets bolded while its accent is silently dropped.

What "partial support" looks like in the UI

When some characters in your input aren't supported by a style, the result row tells you exactly how many were preserved as original text — not a vague warning, an exact count, computed fresh from what you typed. See our character coverage feature for the full breakdown per style.

What we don't do

We never strip an accent, transliterate a letter to its closest ASCII equivalent, or apply a Latin-only combining decoration (strikethrough, underline) to a non-Latin script, specifically because doing so could misrepresent someone's actual name or language. Partial coverage is treated as an honest limit of the character set, not something to paper over.

Why transliteration is worse than partial coverage

A tempting shortcut for a tool trying to look "complete" would be to transliterate anything it can't style — turning é into e, ü into u, or an entire non-Latin name into a rough Latin approximation — so every style appears to reach 100% coverage. We deliberately don't do this, because it silently changes the actual content of someone's name rather than just declining to style part of it. "José" transliterated to "Jose" is a different string, arguably a different spelling of the name, not a styling limitation — and once that substitution happens invisibly inside a "fancy text" tool, most people would never notice their name had actually been altered, not just partially styled. Preserving the accent unstyled is strictly more honest than replacing it with a stripped-down approximation dressed up as a complete result.

Bidirectional text: a related but distinct concern

Mixed left-to-right and right-to-left text (Latin alongside Arabic or Hebrew, for example) has its own rendering considerations independent of styling — the browser and font need to decide the visual order of mixed-direction runs, using Unicode's bidirectional algorithm. This site's result rows use dir="auto" so mixed-direction results render with correct paragraph direction rather than defaulting to a single fixed direction that could scramble the visual order of a name like "Hello مرحبا." This is a rendering concern, separate from the character-preservation guarantee described above — both matter for mixed-script names to display correctly and completely.

A worked example with emoji in the mix

Take a bio line like "Sana 🌸 محمد" — a Latin name, a flower emoji, and an Arabic name in one string. Bold styling converts "Sana" letter by letter, leaves the emoji completely untouched (emoji are never candidates for any Latin-only style), and leaves "محمد" exactly as typed, because Arabic letters have no mapping in any of this site's ASCII-only styles. The result mixes bold Latin, an unstyled emoji, and unstyled Arabic in their original reading directions — nothing merged, dropped, or reordered.

What this means if you manage names for other people

If you're building a directory, a form, or a list that includes other people's names, the same preserve-don't-transliterate principle applies more broadly than just this tool's styling feature: treating a non-Latin or accented name as an error to be "fixed" into plain ASCII is a common but avoidable source of real harm to real people's names. This site's approach — support what you can, leave everything else exactly as given — is a reasonable default for any system handling names across languages, not just for decorative text styling specifically.

A quick way to verify this for your own name

Type your name into any style page's generator and expand the "Details" panel under the result — it reports the exact supported/preserved breakdown computed fresh from what you typed, so you can confirm directly, rather than relying on the general examples above, exactly which of your own characters would be preserved unchanged.

Questions people actually ask

Will any style here ever fully style a non-Latin script? Only if Unicode has assigned a parallel decorative character set for that script the same way it has for Latin (which, for most scripts and most of the styles on this site, it hasn't) — so for now, non-Latin scripts are consistently preserved rather than styled, across every available style.

Does preserving my name unstyled mean the tool "failed"? No — it means that specific style has no defined glyph for that letter, which the coverage counter reports honestly rather than hiding. Other styles, or styling just the Latin portion of a mixed name, may cover more of your text; the homepage's full character coverage filter can help you find the best-matching style for a specific piece of text.

Can I style a name that uses combining diacritics not covered here, like Vietnamese tone marks? Those are preserved the same way any other non-ASCII combining mark is: left completely untouched, since they carry real linguistic meaning that this tool's Latin-only combining styles are not designed to interact with.