Editorial Policy — Why Our Style List Is Filtered
A generator that rewrites your line into dozens of styles at once has an obvious temptation built into it: add more styles. This page explains why we resist that, and what a style has to survive before it earns a place in the list.
Last updated: 30 August 2026 · Published by the TextStylish editorial team
Why the list is shorter than it could be
We could triple the number of styles tomorrow. Unicode contains enough look-alike ranges to fill a very long page, and a longer list looks more generous in a screenshot.
It would also be worse. Most of those extra ranges render on almost nothing: you would scroll further, find a style you liked, paste it, and discover it arrived as a row of empty boxes for everyone reading it. The list would have grown and the site would have got less useful.
So the list is a filtered one. A style is here because it survives real use, not because the characters exist.
The support tiers we actually apply
Not every style is equally safe, and pretending otherwise would flatter the menu at your expense. Internally we sort styles into three tiers, and the tier decides how we present it.
| Tier | Typical styles | How it behaves | How we present it |
|---|---|---|---|
| Reliable | Bold, italic, script, double-struck, small caps | Long-standing code points, broad font coverage | Near the top, no caveat needed |
| Patchy | Decorative and enclosed ranges, bubble, square | Fine on most phones, gaps on older devices | Included, with the gap named on the page |
| Fragile | Heavy combining marks, glitch and Zalgo effects | May render, be stripped, or break line spacing | Included only with an explicit warning |
The fragile tier is the one that separates an honest site from a padded one. Those styles are genuinely fun and genuinely unreliable, and both halves have to be said. Publishing them silently would be the easy option and would leave you to find out after you had already set your bio.
What “styling” means here
The generator does not apply formatting. It replaces each character you type with a different Unicode character that resembles a styled version of it, which is precisely why the result survives being pasted into places that allow no formatting at all.
Two consequences follow, and both are the reader’s problem rather than yours — which is exactly why they belong in an editorial policy:
- The reader’s device draws the character. Not your device, and definitely not ours. A style that is perfect on your screen depends entirely on the font set of whoever is reading it.
- Screen readers announce the underlying character. A styled line may be read letter by letter or as a string of mathematical symbol names. If anyone might reach your text through a screen reader — and for a public bio someone will — keep the essential information in plain text and use styling for decoration.
We put the accessibility point in the policy rather than burying it, because it is the cost of these tools that nobody else mentions.
How a style is checked before it ships
Against the standard, not against another site
Code points and character names come from the Unicode Standard. We do not derive mappings from other styling sites: that is how one site’s error becomes everybody’s error, repeated confidently for years because checking it is the step everyone skipped.
On a real phone, not in our editor
A preview in our own editor proves nothing, since the characters are drawn by the reading device. Styles are pasted into real devices, and when Android and iOS disagree the page says so instead of reporting the better-looking result as the outcome.
Into a real destination field
Rendering and acceptance are different tests. A style can display perfectly and still be stripped from a bio or rejected by a name field, because platforms filter by character range and change those filters without notice. What arrives in the destination is the only result that counts.
Output is served byte for byte
We never normalise, strip variation selectors, remove combining marks or substitute a more familiar character for one that looked odd in a preview. Text that appears broken in an editor very often pastes perfectly into an app.
Zalgo makes the reason concrete: it exists because of stacked combining marks that any tidy-up routine would delete. A generator that quietly normalised its own output would return plain text and label it a glitch style.
Corrections and dates
Errors are fixed on the page where they appeared, with the updated date moving alongside the fix. We do not edit silently and we do not backdate — a date that shifts on every automated touch looks informative while telling you nothing.
Platform rules change without announcement, so reader reports carry real weight here. If a style stopped working somewhere it used to work, that is information we could not have obtained any other way. The contact page lists what to include.
Independence and authorship
No sponsored styles, no paid placement, no affiliate links. Nothing is in the list because someone paid to put it there, and no one has ever paid for a style to be described favourably.
Pages are published by the TextStylish editorial team and attributed that way. We do not invent a named expert, a photograph or a credential to look more authoritative — a fake byline is a lie about the most easily verified thing on a page. Who we are is on the about page; how we work is here.