CLIENT ENGINE // AIR-GAPPED

Mojibake Decoder & CJK Width Converter

Repair corrupted double-encoded UTF-8, Windows-1252, Cyrillic CP1251, and Greek ISO-8859-7 text strings, and convert East Asian CJK Full-Width and Half-Width characters.

APPARATUS // MOJIBAKE-FIXER VERIFIED OK // 0.0ms

Quick Reference Benchmarks

Western Recovery CafÃ© → Café / â€” → — (Win-1252)

Cyrillic Recovery РџСЂРёРІРµС‚ → Привет (CP1251)

Greek Recovery ISO-8859-7 / Win-1253 → Unicode

CJK Grid Width Zenkaku (U+FF01) ↔ Hankaku ASCII

Execution Privacy 100% In-Browser Memory

Overview & Background

**Mojibake** (文字化け, literally 'character transformation' in Japanese) occurs when a text stream encoded in one character standard—almost always multi-byte **UTF-8**—is mistakenly decoded using a legacy 8-bit single-byte code page such as **Windows-1252 (Western European)**, **Windows-1251 (Cyrillic)**, or **ISO-8859-7 (Greek)**. Whenever a designer, data analyst, or localization engineer opens a UTF-8 CSV export in Microsoft Excel without a Byte Order Mark (BOM), imports a legacy MySQL `latin1` database dump, or loads `.srt` video subtitles into an NLE timeline, multi-byte UTF-8 sequences are split apart into bizarre chains of accented symbols.

For example, in UTF-8 the accented letter `é` (`U+00E9`) is stored as the two-byte sequence `0xC3 0xA9`. When read as Windows-1252, `0xC3` becomes `Ã` and `0xA9` becomes `©`, turning `Café` into `CafÃ©` and `München` into `MÃ¼nchen`. Smart typography punctuation suffers even worse corruption because 3-byte UTF-8 sequences (`0xE2 0x80 0x94` for an em-dash `—`) map onto Windows-1252 bytes `0x80–0x9F`, producing the infamous `â€”`, `â€™`, and `â€œ` artifacts across web pages and design layouts. Similarly, when UTF-8 Cyrillic text (`Привет`) is opened under a Russian Windows-1251 locale, its two-byte `0xD0 / 0xD1` prefixes render as alternating `Р` and `С` letters (`РџСЂРёРІРµС‚`).

In East Asian (Japanese, Chinese, and Korean) typography and UI design, a closely related character-set challenge is converting between **Zenkaku (全角, Full-Width `U+FF01–U+FF5E`)** Latin letters and digits (`ＡＢＣ１２３`), which occupy a square `1em × 1em` CJK grid cell, and **Hankaku (半角, Half-Width `U+0021–U+007E`)** standard ASCII characters (`ABC123`).

Kitiverse's **Mojibake Decoder & CJK Width Converter** reverses Windows-1252, CP1251, and ISO-8859-7 byte misinterpretations back into pristine UTF-8 and converts CJK character widths instantaneously—100% registration-free, zero account walls, private client-side compute, and local device storage.

How to fix garbled Mojibake text and convert CJK character widths

Restore unreadable CSV exports, subtitle files, and database strings or normalize Japanese/CJK full-width typography in real time.

Select the repair or width conversion mode that matches your corrupted text: 'Fix UTF-8 read as Windows-1252' for Ã© / â€” artifacts, 'Fix UTF-8 read as CP1251' for Russian Р / С artifacts, 'Fix Greek ISO-8859-7', or 'CJK Full-Width ↔ Half-Width'.

Paste the garbled string, CSV rows, or CJK copy into the Corrupted Mojibake / Source Text box on the left.

Inspect the reconstructed UTF-8 or width-normalized string in the output box on the right.

Click 'Copy Repaired Text' to copy the clean Unicode result directly to your clipboard.

Frequently Asked Questions

Why does my text have 'Ã©', 'Ã¼', 'â€”', and 'â€™' scattered through it?

Those specific character combinations are the unmistakable fingerprint of **UTF-8 text decoded as Windows-1252 (ISO-8859-1)**. Two-byte Latin-1 diacritics in UTF-8 always begin with byte `0xC3` (`Ã` in Windows-1252), while three-byte typographic punctuation marks (curly apostrophe `’`, smart quotes `“”`, em-dash `—`, and bullet `•`) begin with byte `0xE2` (`â`) followed by `0x80` (`€`). Selecting 'Fix UTF-8 read as Windows-1252' maps every Windows-1252 character back to its raw byte (`0x00–0xFF`) and re-assembles the original multi-byte UTF-8 code points.

Why does Russian or Ukrainian text turn into 'РџСЂРёРІРµС‚' with lots of 'Р' and 'С' letters?

In UTF-8, every Cyrillic letter in the `U+0410–U+044F` range is encoded as two bytes starting with either `0xD0` or `0xD1`. In the legacy 8-bit Windows-1251 (CP1251) Cyrillic table, byte `0xD0` is the uppercase letter `Р` and byte `0xD1` is the uppercase letter `С`. When a UTF-8 file is opened as Windows-1251, every single letter expands into a two-character pair starting with `Р` or `С`. Selecting 'Fix UTF-8 read as CP1251' reverses the CP1251 byte table and restores the clean Cyrillic text.

Can this tool also recover Armenian or Georgian UTF-8 text that was opened as Latin-1?

Yes. Because UTF-8 Armenian (`U+0530–U+058F`, starting with bytes `0xD4–0xD6` which look like `Ô²Õ¡Ö€Ö‡` in Latin-1) and UTF-8 Georgian (`U+10D0–U+10FF`, starting with `0xE1 0x83`) use standard 2-byte and 3-byte UTF-8 sequences, the 'Fix UTF-8 read as Windows-1252' mode cleanly reconstructs Armenian, Georgian, Arabic, Hebrew, and CJK UTF-8 strings.

What is the difference between Full-Width (Zenkaku) and Half-Width (Hankaku) in Japanese and CJK typography?

Traditional East Asian typography sets Chinese characters (Kanji/Hanzi) and Japanese Kana on a uniform monospaced square grid (`1em` wide). To align Latin letters and numbers vertically or horizontally within that grid, CJK fonts include **Full-Width forms (`U+FF01–U+FF5E`)** such as `ＡＢＣ１２３` alongside an ideographic full-width space (`U+3000`). When importing Japanese product data, addresses, or forms into Western UI layouts or databases, converting Full-Width characters to standard **Half-Width ASCII (`ABC123`)** prevents awkward spacing and validation failures.

Why can't '???' or '' replacement characters be recovered?

If an application permanently overwrote unrecognized bytes with literal ASCII question marks (`0x3F`, `?`) or the Unicode Replacement Character (`U+FFFD`, ``) before saving the file, the original byte values were destroyed. Mojibake recovery works whenever the original byte values are still preserved as misaligned characters (such as `CafÃ©` or `РџСЂРёРІРµС‚`).

Is my database dump or subtitle text uploaded to any server?

No. Kitiverse is 100% registration-free, zero account walls, private client-side compute, and local device storage. All byte-stream decoding runs locally inside your browser.

Related Instruments in This Workbench

All Text & Content Tools →

Text & Content →

Unicode Glyph Inspector & Font Styler

Inspect character code points (U+XXXX), UTF-8 byte sequences, HTML/CSS escapes, and invisible zero-width characters, or transform text across Mathematical Unicode font styles.

Text & Content →

Word, Character & Byte Counter

Real-time lexical word counter, character and UTF-8 byte analyzer, reading/speaking duration estimator, and SEO keyword density inspector.

Text & Content →

Text Diff Checker

Side-by-side and unified inline text comparison. Character-level precision offloaded to client workers with zero server uploads.

Text & Content →

ANSI to Unicode & Unicode to ANSI Converter

Bidirectionally convert legacy 8-bit designer ANSI fonts (Armenian ARMSCII-8, Georgian AcadNusx, Cyrillic CP1251) and standard UTF-8 Unicode for Illustrator, Photoshop, Figma, and web publishing.

Text & Content →

Arabic, Persian & Kurdish RTL Text Reshaper

Convert disconnected, reversed Arabic, Persian (Farsi), Kurdish, and Urdu text into connected Presentation Forms-B glyphs for DaVinci Resolve, Blender, Cinema 4D, and Adobe apps.

Text & Content →

Case Converter & URL Slug Generator

Transform code identifiers, database columns, and headings across 10 naming conventions including camelCase, snake_case, kebab-case, and SEO URL slugs.

Client-Side Execution & Verification Note:

This utility runs 100% locally in your browser with local device storage and zero server uploads. All outputs are provided on an "as-is" basis—please validate critical data, code, and files before deploying to production.