⌘K

Developer

Character Encoding

Character encoding is the mapping between the characters people read and the bytes computers store, defining how text is turned into binary and back again.

Updated 12 Aug 2026

Bytes are not characters

A file holds bytes. Turning those bytes into letters requires an agreed table. ASCII defined 128 characters in seven bits, which covered English and nothing else. Dozens of incompatible eight-bit extensions followed, so the same byte meant different letters in different countries.

Unicode fixed the vocabulary by assigning every character a unique code point. An encoding then decides how those code points become bytes. UTF-8 won because it is backwards compatible with ASCII, uses one to four bytes per character, and never wastes space on plain English text.

Why text turns to gibberish

Mojibake — café rendered as café — happens when text written in one encoding is read as another. The bytes are intact; the interpretation is wrong. The fix is always to identify the original encoding and decode correctly, never to search and replace the broken characters.

Practical rules

  • Use UTF-8 everywhere: files, databases, HTTP headers and HTML meta tags
  • Declare the encoding explicitly rather than relying on detection
  • Avoid the UTF-8 byte-order mark unless a consumer demands it
  • Remember that a character may be several bytes, so byte length is not string length
  • Normalise Unicode before comparing strings that may use combining accents

Base64 Encoder

Encode and decode values to see exactly which bytes you are handling.

Try Base64 Encoder

Characteristics

  • Maps characters to code points, then code points to bytes
  • UTF-8 is variable width: one to four bytes per character
  • ASCII is a strict subset of UTF-8
  • Encoding must be declared or agreed — it is not stored inside plain text

Common uses

  • Reading and writing text files correctly across systems
  • Setting HTTP Content-Type charset and HTML meta charset
  • Configuring database columns and connections
  • Handling CSV exports that contain accented or non-Latin names

Advantages

  • UTF-8 covers every written language in one scheme
  • Backwards compatible with the entire ASCII range
  • Compact for Latin text, unlike fixed-width alternatives
  • Universally supported by modern platforms

Limitations

  • Legacy files in unknown encodings still need guesswork
  • Variable width makes byte offsets unreliable for slicing
  • Visually identical strings can differ at the code-point level
  • Byte-order marks break naive parsers

Examples

One character, several bytes
Character:  é
Code point: U+00E9
UTF-8:      0xC3 0xA9
Read as Latin-1 instead: é   (mojibake)

Frequently asked questions

What is character encoding in simple terms?

The agreed table that says which bytes represent which characters when text is saved or transmitted.

What is the difference between Unicode and UTF-8?

Unicode assigns a number to every character; UTF-8 is one way of turning those numbers into bytes.

Why does my CSV show weird symbols in Excel?

The file is UTF-8 but is being read as a legacy code page. Import it explicitly as UTF-8.

Which encoding should I use?

UTF-8, unless a system you must integrate with mandates something else.

What is a byte-order mark?

A few leading bytes that signal the encoding. It helps some Windows tools and breaks some parsers.

Related terms

All terms

Related tools

Related guides

All guides