Glitch Text Generator

Corrupt text by stacking combining marks on it. The readout tells you what the corruption costs you in characters, and the fit button spends only what you have.

This works nothing like the other text stylers

Most decorative text tools swap your letters for lookalikes from somewhere else in Unicode: an ordinary a is thrown away and a different character that happens to resemble a fancy a takes its place. Glitch text does the opposite. Your letters stay exactly where they are, as themselves, and the tool appends combining marks after each one — accents, strokes, arrows and hooks from the Combining Diacritical Marks block at U+0300 to U+036F.

A combining mark has no width of its own. The text renderer is required to draw it on top of the character before it, so a run of them piles up vertically over and under a single letter. That is not a hack in the sense of exploiting a bug; it is the machinery that lets one codepoint plus one mark spell an accented letter in languages that need it. Stack nineteen of them instead of one and you get the dripping, corrupted look people call Zalgo, after an internet horror meme from the mid-2000s that spread the trick.

One consequence is genuinely useful: because the base letters were never removed, the original word is still sitting inside the string. Strip the marks — with Unicode decomposition and a filter, or with any of the several tools that do it in one click — and signal lost comes back exactly as typed. Text built by substitution cannot be undone that cleanly, because the letters themselves were thrown away.

It also means glitch text is only cosmetic camouflage. Any filter that strips combining marks before matching will read straight through it. Note that normalisation alone will not do that — NFC and NFD reorder and recompose marks but do not remove them, so a filter has to discard the mark category explicitly. That is a small step, and moderation systems that care have taken it.

Why the budget matters more than the intensity

The trap with this style is that the output looks the same length as the input while being many times larger. Every mark is a separate codepoint. Set all three sliders high and each visible letter carries nineteen extra characters, so an eleven-letter phrase becomes about two hundred and twenty characters and a bio field that seemed generous rejects it without explaining why. The counter under the output box breaks this out — base codepoints, marks added, total, and UTF-16 code units, since some fields count those instead. Fit to limit reduces the three densities in turn, always trimming whichever is currently highest, until the total fits the limit you selected, and tells you what it had to give up.

The upper bound here is eight above, eight below and three through, nineteen marks per character. That cap is deliberate. Past roughly that point the extra marks stop adding visible chaos — they are drawn further and further from the line, straight through whatever is above and below — while the character count keeps climbing and text layout in some apps slows measurably. Unicode does not forbid long mark runs outright, but it does offer guidance: the Stream-Safe Text Format in UAX #15 caps a sequence at thirty combining marks so that conforming software can assume a bounded buffer. Almost nothing on the web enforces it, which is precisely why choosing a ceiling yourself is worth doing — nineteen sits comfortably inside that guidance.

Frequently asked questions

Why does my glitch text get clipped at the top or bottom?

Because marks are drawn outside the line box and do not increase the height reserved for it. A container with a fixed height, a single-line field, or anything with hidden overflow will cut the stack off, and a container without those will have the marks overlap the line above and the line below instead. Both are correct rendering. If you need the whole stack visible, drop the above density until the tallest column survives a test paste in the real place.

Why does the text change slightly after I paste it somewhere?

Many platforms normalise text on save. Normalisation reorders combining marks into a canonical sequence by their combining class, which can visibly rearrange your stack, and composing forms will merge a base letter and its first mark into a single precomposed character where one exists — an e followed by a combining acute becomes é. Nothing is lost, but the result is not byte-identical to what you copied, and the character count may drop by one per merged pair.

Will this get my post removed or my account reported?

It can, and that is worth saying plainly rather than burying. Heavy stacking spills over neighbouring lines and degrades other people's ability to read a shared space, which a number of communities treat as disruptive under existing spam or harassment rules. Moderators strip it, automated filters catch it, and other users report it. A light setting in your own bio is unremarkable. A wall of maximum-density text in a channel someone else has to read is the case people complain about.

Accessibility, and the honest limits

Screen readers deal with this badly, and there is no setting here that fixes it. Depending on the reader, a heavily marked word may be spelled out letter by letter, read with every diacritic announced by name, or skipped in silence. Braille displays render it as noise. If the text carries meaning someone needs — a name, an instruction, a link label — glitching it takes that meaning away from part of your audience, and the polite pattern is to keep a plain version adjacent.

Everything is generated inside this page: no request is made when you drag a slider, nothing you type is uploaded, and the tool keeps working offline once loaded. What it cannot promise is how any given app will draw the result, since that depends on the text engine and fonts on the reader's device. Two phones will stack the same string differently, and some minimal renderers ignore combining marks entirely and show your plain text with no glitch at all.