Zalgo text — the "corrupted," glitchy-looking style with marks stacking above, below, and through letters — is built from the same combining-character mechanism as strikethrough text, but pushed to its extreme. Instead of one combining mark per letter, a Zalgo generator stacks a randomized number of combining marks from several different Unicode ranges on every single character. What looks like unpredictable corruption is, in a correctly built generator, entirely reproducible: the same input word produces the identical Zalgo output every time. That determinism is not a nice-to-have. It is required for the text to work at all in a modern web application.

The Three Combining Mark Zones

Zalgo generators draw combining marks from three categories, each anchored at a different vertical position relative to the base letter:

  • Combining marks above: drawn from the Combining Diacritical Marks block (U+0300–U+036F), things like COMBINING ACUTE ACCENT and COMBINING TILDE stacked repeatedly, extending upward from the letter.
  • Combining marks below: marks like COMBINING GRAVE ACCENT BELOW, extending downward beneath the letter's baseline.
  • Combining marks through: overlay marks like COMBINING LONG STROKE OVERLAY (the same character used for strikethrough text) that cross directly through the letter.

A generator stacks a random count of marks from each zone — often 5 to 15 per letter for a moderate effect, more for "maximum corruption" settings — onto every character in the input. Unicode technically allows an unbounded number of combining marks on a single base character; there is no hard limit written into the standard, though rendering engines can become unstable or extremely slow well before any theoretical ceiling.

Combining Classes: Why Marks Stack Instead of Overlapping Randomly

Every Unicode combining character has a property called the Canonical Combining Class, a number that determines how the character interacts with other combining marks when a rendering engine normalizes and positions them. Marks with combining class 230 ("Above") stack outward from the base letter as more are added, each new one positioned further from the letter than the last. Marks with combining class 220 ("Below") do the same thing extending downward. This is why Zalgo text visually builds outward in layers rather than all the marks piling on the exact same pixel position — the combining class governs the stacking order, even though the specific mark chosen at each position is randomized.

This is also why some rendering engines normalize (reorder) combining marks that share the same combining class during Unicode normalization (specifically canonical ordering, part of Unicode Normalization Form). Two marks with the same combining class can be reordered relative to each other without changing the rendered appearance, because Unicode considers their relative order canonically equivalent. This can make copy-pasted Zalgo text compare as unequal to its original source string in strict byte-for-byte terms, even though it displays identically — relevant if a platform runs any kind of exact-match duplicate detection or filtering on submitted text.

Why the Randomness Must Be Seeded, Not Truly Random

A naive implementation would call Math.random() (or the equivalent in any language) each time it picks a combining mark, producing a different corrupted result every time the same input is processed. For a modern web application built with server-side rendering — where the initial HTML is generated on the server and then "hydrated" (made interactive) by client-side JavaScript in the browser — this is a real bug, not just an aesthetic inconsistency.

React and similar frameworks compare the server-rendered HTML against what the client would render on first paint, to confirm the two match before attaching event handlers. If Zalgo output uses true randomness, the server generates one random corrupted string and the client, re-running the same generation function during hydration, generates a different one. React detects the mismatch and either throws a hydration error to the console or, worse, silently discards the server-rendered content and re-renders from scratch on the client, causing a visible flash of different content and wasted rendering work.

The fix is a seeded pseudorandom number generator: instead of drawing from an unpredictable entropy source, the generator computes a numeric hash of the input string (a common choice is the djb2 algorithm, a simple and fast string hash), and uses that hash as the seed for a deterministic PRNG algorithm such as mulberry32 or xorshift32. Every combining-mark choice the generator makes is then a function of that seed, advanced in a fixed, repeatable sequence. The same input word hashes to the same seed, which produces the same sequence of pseudorandom numbers, which selects the same combining marks in the same order — so the server and client always agree, and copying the same text twice produces an identical result both times.

The Copy Button Depends on This Too

The seeding also matters for the copy button on a font generator page. If a user types a word, sees the corrupted preview, and clicks copy, the copied text needs to be exactly the string they saw on screen — not a freshly regenerated random variation. A seeded approach guarantees the preview render and the copy-to-clipboard value are computed from the same deterministic function, so what gets pasted matches what was previewed.

Rendering Cost and Platform Behavior

Heavily stacked combining marks are expensive to render because the text layout engine has to calculate the position of every mark relative to every other mark on the same base letter, for every letter in the string. A short Zalgo phrase with maximum intensity settings can meaningfully slow down text rendering in a browser tab or a chat application, and some platforms impose their own defensive limits: certain messaging apps and games automatically truncate or strip excessive combining marks from user-submitted text specifically because unbounded Zalgo strings have been used in the past to cause rendering slowdowns or crashes on other users' clients — a known abuse pattern sometimes called a "zalgo bomb."

Platforms that filter or cap combining marks are not being arbitrarily restrictive; they are protecting other users' rendering performance and, in extreme cases, application stability. A responsible Zalgo generator caps the number of marks per letter at a reasonable maximum rather than allowing truly unbounded stacking, both for the visitor's own rendering performance and so the output does not trip a target platform's abuse filters.

Where Zalgo Text Is Used, and Where It Gets Filtered

Zalgo text is most at home where a chaotic, horror, or glitch aesthetic fits the context: gaming usernames for horror-themed games, Discord display names in servers with a creepy or edgy theme, and creative writing or memes referencing the internet-folklore character Zalgo the text corrupts are named after. It reads poorly, or gets actively rejected, in professional contexts — LinkedIn, most Twitter bios, business names — both for tone reasons and because heavy Zalgo strings are exactly the kind of input some platforms' abuse filters are built to catch and strip.

Keeping the mark count moderate (a handful of marks per letter rather than the maximum) produces a recognizably "glitchy" look while staying under the threshold where automated filters intervene, and while keeping the string short enough not to blow through character limits — remember that just like strikethrough, every mark added is an additional code point counted against whatever limit the target field enforces.

The Zalgo Text Generator on this site uses exactly this seeded approach, so the corrupted result you preview is the exact result you copy.

The marks stack in a specific order, not randomly on top of each other. Each combining character carries a Canonical Combining Class, and marks with the same class (for example, class 230 for "above" marks) stack outward from the base letter as more are added, which is why Zalgo text visually builds in layers rather than piling every mark onto the same pixel position.