How many bits or bytes are there in a character?
Categories:
Understanding Character Encoding: Bits, Bytes, and Characters

Explore the fundamental concepts of character encoding, from ASCII to Unicode, and clarify how many bits or bytes are used to represent a single character in different systems.
The question of "how many bits or bytes are in a character?" seems simple, but its answer is surprisingly nuanced and depends entirely on the character encoding scheme being used. In the early days of computing, a character almost always meant one byte. However, with the advent of global communication and the need to represent a vast array of languages and symbols, this simple 1:1 relationship evolved dramatically. This article will demystify character encoding, explaining the journey from fixed-width encodings like ASCII to variable-width encodings like UTF-8, and how they impact the storage and transmission of text.
The Basics: Bits, Bytes, and Early Encodings
At its core, a computer stores all information as binary digits, or bits. A bit is the smallest unit of data, representing either a 0 or a 1. A byte is a collection of 8 bits. This 8-bit structure became the standard unit for addressing memory and data transfer. Early character encodings, like ASCII, were designed around this 8-bit byte.
ASCII (American Standard Code for Information Interchange)
ASCII was one of the first widely adopted character encoding standards. It uses 7 bits to represent 128 characters, including uppercase and lowercase English letters, numbers, punctuation marks, and control characters. Since computers typically work with bytes (8 bits), an ASCII character effectively occupies one byte, with the 8th bit often unused or used for parity checking.
For example, the character 'A' in ASCII is represented by the binary sequence 01000001
, which is 65 in decimal. This fits perfectly within a single byte.
print(ord('A')) # Output: 65
print(bin(ord('A'))) # Output: 0b1000001 (7 bits, often padded to 8 for a byte)
Python example showing ASCII value and binary representation of 'A'
Expanding Beyond ASCII: Extended ASCII and Code Pages
As computing spread globally, the 128 characters of ASCII proved insufficient. To accommodate additional characters for European languages (like accented letters) and graphical symbols, various "extended ASCII" encodings emerged. These encodings utilized the full 8 bits of a byte, allowing for 256 different characters. However, the problem was that there was no single standard for these extra 128 characters. Different regions and operating systems used different "code pages" (e.g., ISO-8859-1 for Western European, CP437 for DOS), leading to "mojibake" (garbled text) when files were opened with the wrong encoding.
In these extended ASCII schemes, a character still occupied exactly one byte. The challenge was interoperability.
The Unicode Revolution: Variable-Width Encodings
The limitations of 8-bit encodings led to the development of Unicode, a universal character set designed to encompass all characters from all writing systems in the world. Unicode assigns a unique number (a "code point") to every character. As of Unicode 15.0, there are over 149,000 characters defined.
However, Unicode itself is just a mapping of characters to numbers. To store these numbers in bytes, various encoding forms were developed, the most common being UTF-8, UTF-16, and UTF-32.
UTF-8 (Unicode Transformation Format - 8-bit)
UTF-8 is the dominant encoding on the web and in many operating systems. It is a variable-width encoding, meaning a character can take up a different number of bytes depending on its code point:
- 1 byte: For ASCII characters (U+0000 to U+007F). This makes UTF-8 backward compatible with ASCII.
- 2 bytes: For many common non-ASCII characters, including most Latin-script characters with diacritics, Greek, Cyrillic, and Armenian.
- 3 bytes: For most common CJK (Chinese, Japanese, Korean) characters, and many other symbols.
- 4 bytes: For less common characters, including some CJK characters, emojis, and historical scripts.
This variable-width nature is efficient because common characters use fewer bytes, while less common ones are still supported. This means that in UTF-8, a single character can be 1, 2, 3, or 4 bytes long.
UTF-16 (Unicode Transformation Format - 16-bit)
UTF-16 is another variable-width encoding, primarily used internally by Windows and Java. It uses either 2 or 4 bytes per character:
- 2 bytes: For characters in the Basic Multilingual Plane (BMP), which covers the first 65,536 code points (U+0000 to U+FFFF). This includes most commonly used characters.
- 4 bytes: For characters outside the BMP, using a mechanism called "surrogate pairs."
UTF-32 (Unicode Transformation Format - 32-bit)
UTF-32 is a fixed-width encoding where every character occupies exactly 4 bytes. While simpler to work with from a programming perspective (no need to worry about variable lengths), it is highly inefficient for most text, as it uses 4 bytes even for simple ASCII characters that could be represented in 1 byte. It's rarely used for storage or transmission.
So, to answer the question directly:
- In ASCII or Extended ASCII, a character is typically 1 byte.
- In UTF-8, a character can be 1, 2, 3, or 4 bytes.
- In UTF-16, a character can be 2 or 4 bytes.
- In UTF-32, a character is always 4 bytes.
flowchart TD A[Character] --> B{Encoding Scheme?} B -- ASCII / Extended ASCII --> C[1 Byte] B -- UTF-8 --> D{Code Point Range?} D -- U+0000 to U+007F --> E[1 Byte] D -- U+0080 to U+07FF --> F[2 Bytes] D -- U+0800 to U+FFFF --> G[3 Bytes] D -- U+10000 to U+10FFFF --> H[4 Bytes] B -- UTF-16 --> I{Code Point Range?} I -- U+0000 to U+FFFF --> J[2 Bytes] I -- U+10000 to U+10FFFF --> K[4 Bytes] B -- UTF-32 --> L[4 Bytes]
Character byte representation based on encoding scheme
Practical Implications and Best Practices
Understanding character encodings is crucial for preventing data corruption, ensuring proper display of text, and optimizing storage and network usage. Here are some practical implications:
- File Sizes: A text file containing only English ASCII characters will be smaller if encoded in UTF-8 than in UTF-16 or UTF-32. A file with many Chinese characters might be smaller in UTF-8 (3 bytes/char) than in UTF-16 (2 bytes/char for BMP, but many CJK are BMP) or UTF-32 (4 bytes/char).
- String Length vs. Byte Length: In programming languages, the "length" of a string often refers to the number of characters, not the number of bytes. If you need to know the byte length (e.g., for network transmission or file size limits), you must encode the string first.
- Database Storage: Databases must be configured with appropriate character sets (like
utf8mb4
in MySQL for full Unicode support, including emojis) to correctly store and retrieve diverse character data. - Web Development: Always declare the character encoding in HTML (
<meta charset="UTF-8">
) and HTTP headers to ensure browsers render content correctly.
const asciiChar = 'A';
const emojiChar = '😊';
const chineseChar = '你好';
// In JavaScript, .length counts code units, not necessarily characters or bytes
console.log(`'${asciiChar}' length (JS):`, asciiChar.length); // 1
console.log(`'${emojiChar}' length (JS):`, emojiChar.length); // 2 (UTF-16 surrogate pair)
console.log(`'${chineseChar}' length (JS):`, chineseChar.length); // 2
// To get byte length in UTF-8
const encoder = new TextEncoder();
console.log(`'${asciiChar}' byte length (UTF-8):`, encoder.encode(asciiChar).length); // 1
console.log(`'${emojiChar}' byte length (UTF-8):`, encoder.encode(emojiChar).length); // 4
console.log(`'${chineseChar}' byte length (UTF-8):`, encoder.encode(chineseChar).length); // 6 (3 bytes per char)
JavaScript example demonstrating character length vs. byte length in UTF-8