What Is Mojibake?

Mojibake at a glance

Mojibake is usually not a font problem. It is a mismatch between the bytes that were stored and the encoding used to interpret them.

What does mojibake mean?

Mojibake refers to unreadable or incorrectly rendered text. It commonly appears as accented Latin characters, strange punctuation or repeated symbols. The visible output is often valid text under the wrong interpretation, which is why it can be copied, saved and corrupted again. Mojibake is different from missing-glyph boxes, different from intentional replacement characters and different from damaged storage. It is often reversible when the mistaken decoding path is known.

Correct: café
Mojibake: café

Correct: It’s working
Mojibake: It’s working

Correct: “Hello”
Mojibake: “Hello�

Start with Mojibake Repair and inspect suspicious characters with the Unicode Character Inspector.

Encoding and decoding explained

Encoding

Encoding converts Unicode text into bytes using a character encoding.

é
Unicode code point: U+00E9
UTF-8 bytes: C3 A9

Decoding

Decoding converts bytes back into Unicode text according to an encoding. Encoding and decoding must agree because a byte sequence has no universal textual meaning without an encoding.

Correct path:
é → encode as UTF-8 → C3 A9 → decode as UTF-8 → é

Incorrect path:
é → encode as UTF-8 → C3 A9 → decode as Windows-1252 → é

Unicode code points and UTF-8 bytes are not the same thing. Re-decoding already decoded text can create additional corruption. Read Unicode vs UTF-8 and UTF-8 vs UTF-16, then test bytes with UTF-8 Encoder and Decoder.

Why does é appear instead of é?

The character é is Unicode code point U+00E9. In UTF-8, it is stored as two bytes: C3 A9. If those bytes are interpreted as Windows-1252, C3 maps to Ã and A9 maps to ©, producing é after the visible text is rendered. The displayed second character can depend on the exact single-byte encoding and subsequent processing.

The leading Â often appears when UTF-8 bytes beginning with C2, including non-breaking spaces and symbols, are decoded as a single-byte encoding.

Common mojibake patterns

These patterns are clues, not proof. Do not promise an exact repair only from appearance.

Interactive mojibake analyzer

This local analyzer models likely encode/decode transformations, ranks repair candidates and warns when corruption is uncertain or lossy. It preserves the original input and does not send text to the backend.

Windows-1252 vs ISO-8859-1 confusion

Windows-1252 and ISO-8859-1 overlap substantially. Windows-1252 assigns printable punctuation where ISO-8859-1 defines control characters, and many systems historically labeled Windows-1252 data as ISO-8859-1. Smart quotes and dashes often point toward Windows-1252, but exact repair still requires knowing the actual byte interpretation.

’
U+2019
UTF-8 bytes: E2 80 99
Misdecoded as Windows-1252: ’

The first byte E2 becomes â, and the following bytes become Windows-1252 punctuation/control-derived characters.

What is double encoding?

Double encoding happens when text is encoded into bytes, decoded incorrectly into mojibake, and then the mojibake text is encoded again. Repeated patterns such as ÃÂ can indicate an extra corruption layer.

é
→ é
→ é

Each repair layer must be reversed in the correct order.

What does the replacement character mean?

� is U+FFFD REPLACEMENT CHARACTER. It is inserted when a decoder encounters invalid or unrepresentable input. It often indicates that original byte information was lost. It is not the same as mojibake such as é, and once bytes are replaced with U+FFFD, exact recovery may be impossible without the original file, database backup or raw network payload.

caf�

The missing original byte sequence cannot generally be inferred with certainty. Validate raw bytes with the UTF-8 Validator and inspect U+FFFD with the Unicode Character Inspector.

Mojibake vs missing glyphs

Mojibake displays wrong decoded characters. Missing glyphs happen when the correct code point exists but the font cannot draw it, often showing a box or tofu symbol. Changing fonts may fix missing glyphs, but it usually does not fix mojibake.

Mojibake vs Unicode normalization problems

Mojibake is primarily an encoding or decoding problem. Normalization concerns equivalent code-point sequences, such as NFC and NFD. Normalization does not usually repair é, and mojibake repair does not automatically normalize text. Both issues can occur in the same pipeline.

Mojibake:
é → é

Normalization difference:
U+00E9 vs U+0065 U+0301

Read Unicode Normalization Explained, NFC vs NFD or use Unicode Normalizer.

Can mojibake always be fixed?

Reversible corruption

The original byte information is still represented through a reversible wrong decode. café may often be repairable to café.

Ambiguous corruption

Several original strings or encoding paths may be plausible. A good tool should show alternatives.

Irreversible corruption

Original bytes may have been replaced with U+FFFD, dropped, converted through a lossy character set, truncated, manually edited, normalized through an irreversible compatibility step or re-encoded through multiple unknown systems. For a repair workflow, read How to Fix Broken UTF-8 Text.

How to identify the original encoding

1. Preserve the original file or byte stream.
2. Check metadata and protocol declarations.
3. Inspect a BOM.
4. Validate as UTF-8.
5. Look for characteristic byte patterns.
6. Review the source system and language.
7. Compare likely encodings.
8. Use encoding detection as a probability, not certainty.
9. Test a sample before converting a whole dataset.
10. Verify repaired text with a native speaker or authoritative source when possible.

File extensions alone do not identify encoding. Use Character Encoding Detector, UTF-8 Validator and UTF-8 Encoder and Decoder.

How to fix mojibake safely

1. Make a backup.
2. Preserve original bytes.
3. Identify the visible corruption.
4. Infer the likely mistaken decoding.
5. Re-encode the mojibake text using the mistaken encoding.
6. Decode those bytes using the intended encoding.
7. Compare candidate repairs.
8. Validate characters and language.
9. Test on a small sample.
10. Write repaired output to a new file or field.
11. Keep an audit log.
12. Avoid repeatedly repairing already-correct values.

Current text: café
Encode as Windows-1252 bytes
Decode resulting bytes as UTF-8
Result: café

This procedure works only when the corruption path matches.

Mojibake in web pages

Common causes include missing or incorrect <meta charset>, wrong HTTP Content-Type, disagreement between server and HTML declarations, database connection encoding mismatch, template files saved in another encoding, text decoded twice, proxy transformation and incorrect form-submission handling.

<meta charset="utf-8">

Content-Type: text/html; charset=utf-8

The charset declaration should appear early in HTML. Inspect response headers, raw bytes, template encoding, database connections, frontend conversions and reverse-proxy behavior.

Mojibake in databases

Application connection encoding may differ from table encoding. Data may be inserted as bytes under the wrong character set, or it may already be corrupted before insertion. Changing a column declaration does not automatically repair stored bytes. Export and import tools may use different encodings, collation does not repair mojibake, and double conversion can worsen corruption.

original_value
repaired_value
repair_status
repair_method

For production migrations, sample affected rows, identify patterns, create reversible migrations, record backups, verify counts and hashes, and avoid global replacement without validation.

Mojibake in CSV and spreadsheet files

CSV does not reliably declare encoding by itself. Spreadsheet applications may guess. UTF-8 without BOM may be misdetected by older workflows, while a UTF-8 BOM can help some spreadsheets but affect other tools. Regional settings can affect delimiters independently of encoding. Export and import settings must agree.

Export explicitly as UTF-8, preserve the original file, validate before import, test accented and non-Latin sample values, and avoid opening and resaving through unknown encodings.

Mojibake in APIs and JSON

JSON text uses Unicode characters and is commonly transported as UTF-8. HTTP headers and actual payload bytes must agree. Manual encode/decode calls can corrupt already-decoded strings. Base64 is not a character encoding, escaped JSON such as \u00E9 is not mojibake, logging systems may introduce encoding problems, and signatures or hashes depend on exact bytes.

Content-Type: application/json

Unicode string
→ serialize JSON
→ encode payload as UTF-8
→ transmit bytes
→ decode once
→ parse JSON

Mojibake in copied PDF text

PDF text extraction may produce incorrect character mappings. Embedded fonts may map glyphs to unexpected values, visual glyph order may differ from logical text order, and missing spaces or incorrect ligatures are not always classic mojibake. OCR errors are different from encoding errors, and a generic encoding repair may not fix a bad PDF character map.

Try Clean Copied PDF Text and inspect output with the Unicode Character Inspector.

Mojibake in JavaScript

JavaScript strings are already decoded Unicode text. TextEncoder encodes strings as UTF-8, and TextDecoder decodes byte arrays. Using the wrong decoder creates mojibake. Deprecated escape() and unescape() hacks, including decodeURIComponent(escape(text)), are unsafe and unreliable.

const original = "café";

const bytes = new TextEncoder().encode(original);
const decoded = new TextDecoder("utf-8", {
    fatal: true,
}).decode(bytes);

console.log(decoded);

function decodeUtf8(bytes) {
    return new TextDecoder("utf-8", {
        fatal: true,
    }).decode(bytes);
}

fatal: true reports invalid sequences. Without it, replacement characters may be inserted. Browser support for legacy labels should be tested.

Mojibake in Python

Python str contains Unicode text and bytes contains encoded bytes. .encode() converts text to bytes; .decode() converts bytes to text.

original = "café"

encoded = original.encode("utf-8")
decoded = encoded.decode("utf-8")

print(decoded)

original = "café"

utf8_bytes = original.encode("utf-8")
mojibake = utf8_bytes.decode("windows-1252")
repaired = mojibake.encode("windows-1252").decode("utf-8")

print(mojibake)
print(repaired)

def repair_utf8_as_windows_1252(text: str) -> str:
    try:
        raw_bytes = text.encode("windows-1252")
        return raw_bytes.decode("utf-8")
    except (UnicodeEncodeError, UnicodeDecodeError) as error:
        raise ValueError(
            "Text does not match the expected mojibake pattern."
        ) from error

Do not apply this to every string. Preserve original data, use strict errors and test candidate encodings.

Mojibake in PHP

PHP strings are byte sequences. Encoding-aware functions must be used deliberately, and applying a conversion in the wrong direction can create mojibake. Input must be validated before bulk repair.

function repairUtf8DecodedAsWindows1252(
    string $text
): string {
    $bytes = mb_convert_encoding(
        $text,
        "Windows-1252",
        "UTF-8"
    );

    return mb_convert_encoding(
        $bytes,
        "UTF-8",
        "Windows-1252"
    );
}

if (!mb_check_encoding($value, "UTF-8")) {
    throw new InvalidArgumentException(
        "Input is not valid UTF-8."
    );
}

mbstring is required, labels may differ by runtime, bulk repair must be tested on representative samples, and PHP strings do not automatically track their encoding.

Common mojibake repair mistakes

Applying replacements such as é → é

Replacement tables miss many sequences and can alter legitimate text.

Repairing every string automatically

Correct text can be damaged.

Running the same repair twice

This can reverse correct text or create new corruption.

Discarding the original bytes

Exact recovery may become impossible.

Treating encoding detection as certainty

Detection is heuristic.

Changing the database charset and assuming data is repaired

Stored bytes may remain corrupted.

Ignoring double encoding

One repair pass may not be enough.

Confusing mojibake with normalization

They require different fixes.

Confusing mojibake with OCR errors

PDF and image extraction may produce unrelated errors.

Silently replacing invalid bytes

Replacement characters can destroy evidence needed for repair.

Using lossy encode/decode error modes

Ignoring invalid bytes may hide corruption.

Repairing signed or hashed data

Changing bytes invalidates signatures and hashes.

How to prevent mojibake

Files

Save source and data files as UTF-8, declare encoding explicitly, validate imports and test non-ASCII samples.

Web

Send the correct HTTP charset, include <meta charset="utf-8">, and keep templates and source files in UTF-8.

Databases

Use full-Unicode configuration, configure connections consistently, avoid unnecessary conversions, and test migration and backup tools.

APIs

Encode payloads once, decode payloads once, define byte encoding and validate raw payloads when required.

Applications

Separate text from bytes, avoid ambiguous conversion helpers, log encoding metadata rather than sensitive text, preserve originals during repair and add Unicode regression tests.

Practical mojibake debugging workflow

1. Preserve the original source.
2. Determine whether you have bytes or already-decoded text.
3. Check the declared encoding.
4. Validate raw bytes as UTF-8.
5. Inspect suspicious characters and code points.
6. Identify common mojibake signatures.
7. Test likely decoding paths.
8. Rank candidate repairs.
9. Compare repaired text with expected language.
10. Check for double encoding.
11. Write repaired output separately.
12. Add regression tests before deploying a bulk fix.

Use Mojibake Repair, UTF-8 Validator, Character Encoding Detector, Unicode Character Inspector and Unicode Text Compare.

Try these UnicodeNow tools

These tools help identify bad byte paths, validate UTF-8, inspect code points and compare repaired text.

For hex-level inspection, also use Hex to Text.

Frequently asked questions

References

• The Unicode Standard
• Unicode glossary
• RFC 3629: UTF-8
• WHATWG Encoding Standard
• Unicode Character Database
• MDN: TextEncoder
• MDN: TextDecoder
• Python Unicode HOWTO
• Python codec documentation
• PHP multibyte string documentation
• HTML character encoding guidance