Index / Developer
Unicode Text Mangler
Sponge case, small capitals, fullwidth, upside down, struck through and zalgo, all at once. None of it is styling: every one of these is a different set of code points, and the page prints them, along with what the result costs in bytes.
Input
Combining marks stacked on each character. Zero
leaves the text alone.
Output
--
Code points
0
UTF-8 bytes
0
UTF-16 units
0
Every transformation at once
What the chosen output is made of
What these actually are, and what they break
None of this is formatting. Bold text in a document is the same
letters with a style attached; ππ¨π₯π here is a different set of
characters, in the Mathematical Alphanumeric Symbols block, which is why
it survives being pasted into a plain-text box. That is the whole appeal
and also the whole problem.
It breaks search, sorting and screen readers. A screen reader reads π‘ππ₯π₯π¨ as “mathematical bold small h, mathematical bold small e” and so on, or skips it. Nothing here is appropriate in anything anybody has to read; it is for a joke in a chat window.
Some letters simply do not exist. Unicode has small capitals for most of the alphabet but not for X, because the small-capital letters were added for phonetic notation rather than for typography. Anything without a mapping is left exactly as it was, and the page counts how many characters that happened to.
Sponge case alternates on letters only. Spaces and punctuation do not advance the alternation, so “a b” comes out “a B” rather than “a b”. That is the rule the meme actually follows.
Zalgo here is deterministic. The marks come from a small generator seeded by the text itself, so the same words always mangle the same way and a link to this page shows what it showed you. The generator is 16-bit for a reason: the usual 32-bit constants overflow what a double counts exactly, and the sequence would quietly stop being reproducible.
Zalgo is combining marks — U+0300 to U+036F, the diacritics that stack above and below a letter. Each mark is its own code point and costs two bytes in UTF-8, so intensity 10 on a 20-character string is 420 bytes rather than 20. The character count and the byte count part company here, which is the honest reason a lot of systems reject it.
Upside down is a reversal and a substitution, not a rotation: the letters are turned-letter code points that happen to look inverted, and the string is reversed so it reads correctly when the whole line is turned over. Several characters have no turned form and are left alone.
The three counts are three different questions. Code points is how many characters Unicode says there are; UTF-16 units is what JavaScript's
Nothing is normalised. The text is transformed as typed. If your input is already decomposed — e as e plus a combining acute rather than as é — it stays that way, and the counts will show it.
It breaks search, sorting and screen readers. A screen reader reads π‘ππ₯π₯π¨ as “mathematical bold small h, mathematical bold small e” and so on, or skips it. Nothing here is appropriate in anything anybody has to read; it is for a joke in a chat window.
Some letters simply do not exist. Unicode has small capitals for most of the alphabet but not for X, because the small-capital letters were added for phonetic notation rather than for typography. Anything without a mapping is left exactly as it was, and the page counts how many characters that happened to.
Sponge case alternates on letters only. Spaces and punctuation do not advance the alternation, so “a b” comes out “a B” rather than “a b”. That is the rule the meme actually follows.
Zalgo here is deterministic. The marks come from a small generator seeded by the text itself, so the same words always mangle the same way and a link to this page shows what it showed you. The generator is 16-bit for a reason: the usual 32-bit constants overflow what a double counts exactly, and the sequence would quietly stop being reproducible.
Zalgo is combining marks — U+0300 to U+036F, the diacritics that stack above and below a letter. Each mark is its own code point and costs two bytes in UTF-8, so intensity 10 on a 20-character string is 420 bytes rather than 20. The character count and the byte count part company here, which is the honest reason a lot of systems reject it.
Upside down is a reversal and a substitution, not a rotation: the letters are turned-letter code points that happen to look inverted, and the string is reversed so it reads correctly when the whole line is turned over. Several characters have no turned form and are left alone.
The three counts are three different questions. Code points is how many characters Unicode says there are; UTF-16 units is what JavaScript's
.length returns, which is two for anything
outside the basic plane; UTF-8 bytes is what it costs to store or send.
A tweet, a database column and a JSON payload each count a different one
of those.
Nothing is normalised. The text is transformed as typed. If your input is already decomposed — e as e plus a combining acute rather than as é — it stays that way, and the counts will show it.