Read it backwards. Reversing splits on code points rather than UTF-16 units, so emoji and flags do not shatter into broken squares.
Ask three people to reverse a sentence and you will get three different answers. One reverses character order, so "Hello world" becomes "dlrow olleH": every character keeps its shape and only the sequence changes. Another reverses word order while leaving each word intact, giving "world Hello". A third flips every letter upside down, which is not reordering at all but substitution, since each letter is swapped for a code point that resembles the original rotated 180 degrees.
The generator on this page handles the first two, because both are pure reordering operations that never change which characters your string contains. Upside-down text lives with the styling tools, since it depends on which lookalike glyphs Unicode happens to have encoded, and coverage there is patchy in a way that pure reversal never is.
Deciding which one you want matters more than it sounds. Character reversal is what a palindrome check needs. Word reversal is what you want for word-order puzzles, for sanity-checking a tokenizer, or for reading a sentence back to front while each word stays legible. Flipping is a visual effect for a display name or a bio line. Choosing the wrong one gives you output that looks plausible at a glance and is quietly wrong for your purpose.
The classic bug in text reversal is reversing the wrong unit. JavaScript, Java and C# strings, and the Windows text APIs, all store text as UTF-16 code units. Characters up to U+FFFF, the Basic Multilingual Plane, occupy one unit each, so reversing units and reversing characters look identical for plain English. Everything above U+FFFF is stored as a surrogate pair instead: a high surrogate in the range U+D800 to U+DBFF followed by a low surrogate in U+DC00 to U+DFFF.
Reverse the units and that pair comes out backwards. A low surrogate followed by a high surrogate is not a valid sequence, so the string is no longer well-formed. What you see is a run of U+FFFD replacement characters, or empty boxes, depending on the renderer.
This hits exactly the characters people care about. Almost every emoji sits above U+FFFF. So does the Mathematical Alphanumeric Symbols block at U+1D400 to U+1D7FF, the source of the bold and italic styled text elsewhere on this site. Push a styled string through the split-reverse-join one-liner most tutorials teach and you get garbage rather than backwards text.
Iterating by code point instead, by spreading the string into an array or using a for-of loop, fixes surrogate pairs, because those iterators yield whole code points. It fixes only that; two further problems remain underneath.
Code points are still not characters. A letter carrying an accent can be stored two ways: precomposed, as the single code point U+00E9 for e-acute, or decomposed, as a plain letter e followed by a combining acute accent at U+0301. That second form draws on the Combining Diacritical Marks block, U+0300 to U+036F, and its defining rule is that the mark follows the base letter it modifies.
Reverse a decomposed string by code point and every mark lands on whatever character preceded it. An accent attaches to its neighbour, or to a space, or drifts to the start of the string where it renders on a dotted circle placeholder. The result is not merely backwards; it is wrong.
Which form you have is not something you can see. Some filesystems have historically stored decomposed text, many web forms submit precomposed text, and a couple of copy-paste operations can leave both inside one paragraph. Normalization Form C composes what it can before you touch the string, reducing the damage without eliminating it: plenty of combining sequences have no precomposed equivalent, and the stacked marks used in Vietnamese, in transliterated Sanskrit and in phonetic notation never collapse into one code point.
The same rule governs scripts far beyond Latin. Devanagari vowel signs, Thai tone marks and Hangul jamo all attach to a preceding base, and all break in exactly this way.
The unit that matches what a reader calls a character is the extended grapheme cluster, defined by the text segmentation rules in Unicode Standard Annex #29. A cluster is a base character plus everything that must travel with it: combining marks, variation selectors and joiners. Segment the string into clusters, reverse the list, then rejoin. That is the correct algorithm, and it is the one this page runs.
Emoji show why the rule has to be this broad. A family emoji is several person emoji joined by the zero-width joiner, U+200D, and the entire run counts as one cluster. A flag is a pair of regional indicator symbols from U+1F1E6 to U+1F1FF, so reversing them can turn one country's flag into another's whenever the swapped pair is also valid. A skin-toned emoji is a base emoji plus a modifier from U+1F3FB to U+1F3FF. The variation selector U+FE0F, which requests the colour rendering rather than the monochrome one, has to stay behind its base.
Browsers already ship this segmentation. The Intl.Segmenter API with its granularity set to grapheme returns exactly these clusters, so a correct implementation is no longer than a broken one. The honest limitation is that the rules get revised as new emoji sequences are added, so a string reversed correctly today may contain a sequence an older library still splits down the middle.
Right-to-left scripts are where intuition fails completely. Arabic and Hebrew are stored in logical order, meaning the first letter you read is the first one in memory, and they are turned around at display time by the Unicode Bidirectional Algorithm, specified in UAX #9. Your screen is already showing them running right to left. The stored sequence was never reversed.
So reversing an Arabic or Hebrew string undoes nothing. It produces a genuinely backwards sequence that the bidirectional algorithm then lays out right to left as usual, which a reader sees as scrambled letters. Arabic takes a second injury on top of that: its letters take initial, medial, final or isolated shapes depending on their neighbours, and the rendering engine decides that shaping from the stored order. Reverse the order and every joining decision changes with it.
Mixed strings are harder still. An English product name inside an Arabic sentence, or a phone number in a Hebrew paragraph, already involves several direction runs resolved by rules you cannot see in the finished output.
There is also a character that reverses display without touching storage: U+202E, right-to-left override. It is the mechanism behind filename spoofing and the Trojan Source source-code attacks disclosed in 2021. If text looks reversed on screen but copies back in the correct order, suspect an override character rather than reversed content.
Word reversal looks trivial: split on whitespace, reverse the list, join with spaces. It stays trivial right up until punctuation. Split "Hello, world!" on spaces and you get "Hello," and "world!", so the reversed result reads "world! Hello," with the comma trailing the wrong word and the sentence-ending exclamation mark stranded in the middle. No splitting rule fixes that alone, because whether a mark belongs to its word or to the sentence depends on which mark it is.
Whitespace itself carries information you can lose. Double spaces, tabs, the non-breaking space at U+00A0 and line breaks are all separators, and a naive split collapses them into single spaces, quietly reformatting text you only meant to reorder. Reversing line by line rather than across a whole block is usually what people actually want for a list or a poem.
Then there are the languages that do not put spaces between words at all. Chinese, Japanese and Thai need dictionary-based or model-based word segmentation, so a whitespace split hands back one enormous token and reversing it changes nothing.
The practical answer is to expect to repair punctuation by hand for anything longer than a phrase. The tool reorders your words faithfully; it does not know your sentence grammar, and no reversal tool anywhere does.
Upside-down text is a different mechanism wearing the same name. Nothing is rotated. Each letter is replaced by a separate code point that happens to resemble it turned through 180 degrees, and most are phonetic symbols from the IPA Extensions block at U+0250 to U+02AF: turned a is U+0250, turned e is U+01DD, turned m is U+026F. You then have to reverse the string as well, because a flipped line reads from what used to be its end.
The coverage gap is immediate and unfixable. Unicode never encoded a turned Latin alphabet as a set. Those characters exist for phonetics, and their resemblance to rotated letters is a coincidence. Capitals fare worse: flipping tools borrow from unrelated blocks, such as the mathematical for-all sign U+2200 standing in for A, and for several letters no candidate exists, so the tool leaves them upright and the illusion breaks mid-word.
Everything downstream of the substitution suffers for it. A screen reader announces the character's Unicode name, or skips it. Find-in-page will not match the word, because these characters genuinely are not the letters they resemble. Fonts missing the glyphs render boxes. Username fields that accept only ASCII reject the string outright. Treat flipped text as decoration for a display name, never as words somebody needs to read or search for.
Reversed text is not encryption, and it is worth being blunt about that. There is no key, the transformation is public, and reversal is its own inverse, so applying it twice returns the original exactly. Anyone who suspects reversal confirms it in a single step. It hides nothing from a reader, a search index, or any automated system that normalizes text before looking at it. Do not use it for anything you would be unhappy to see read aloud.
What it is genuinely good for is narrower and real. Palindrome checking is the obvious case, and the honest version needs more than reversal: case folding, punctuation stripping and normalization first, then a cluster-level comparison. Puzzle and quiz construction, mirror-writing prompts for handwriting practice, and spoiler text where the point is a mild speed bump rather than secrecy all work well.
The most underrated use is testing. A reversed string is a cheap probe for whether a pipeline handles Unicode correctly, because output returning replacement characters or displaced accents has just told you the code is reversing UTF-16 code units rather than clusters. The same trick exposes database columns with the wrong collation and display layers that quietly assume left-to-right.
All of it runs in your browser. Nothing you paste is uploaded, and there is nothing to sign up for.
Reversing at the grapheme-cluster level preserves length exactly: same characters, new order. Reversing code units can corrupt the string instead, since broken surrogate pairs are usually replaced by U+FFFD. Separately, styled characters above U+FFFF already count as two units in any field measuring UTF-16, so a reversed styled string fills a 150-character bio just as fast as the original did.
Two different causes. Replacement characters or black diamonds mean the reversal split a surrogate pair and produced invalid text, which you fix by reversing grapheme clusters instead. Plain empty rectangles usually mean the characters are valid but your font has no glyph for them, which is common with turned letters and phonetic symbols. The first is a bug; the second is a font gap on your device.
Yes, provided the reversal was done correctly: reversing twice returns the exact input, because the operation is its own inverse. That holds for character order and word order alike. It stops holding once a broken reversal has replaced something with U+FFFD, because that loss is permanent. Keep your original text rather than relying on a second pass to restore it.
Reversed plain text will, since it uses the characters you started with in a different order. Upside-down text usually will not: Instagram usernames, X handles and Facebook's name field accept a restricted ASCII range and reject phonetic or mathematical characters outright. Bios and posts on those same platforms do accept them, which is why one network allows a style in one field and refuses it in another.
Reversal alone gives false negatives. Case fold the string, strip punctuation and spaces using Unicode character properties rather than a hand-written ASCII list, normalize to a single form so a precomposed accent and a combining one compare equal, then split into grapheme clusters and compare the list against its reverse. Do it in that order, because normalizing after stripping can reintroduce differences.
Reversed prose is stored as ordinary characters, so a crawler indexes it exactly as written, which is to say as gibberish. Nobody searching the real phrase will match it, and a screen reader will read it out character by character or produce nonsense words. Use it for a puzzle or a decorative line, and keep meaningful sentences in normal forward text.
You can reverse a block as one long string, in which case newlines move like any other character and your line structure disappears, or reverse each line independently and keep the layout intact. For lists, poems and code samples the per-line version is almost always the one you want. Word reversal offers the same choice: within each line, or across the whole document.
Excel has no built-in worksheet function for reversing a string, so people reach for the VBA StrReverse function, which walks UTF-16 code units. On plain Latin text that is fine; on emoji or mathematical styled characters it splits surrogate pairs and returns broken output. A formula built from TEXTJOIN and MID has the same flaw, because those functions count the same units.