Text to Binary, ASCII, and Morse: How Text Encoding Actually Works

When you type the letter "A" on your keyboard, your computer doesn't store a letter. It stores the number 65. That number is represented in memory as the binary sequence 01000001. If you sent that same "A" over a telegraph wire in 1890, it would be transmitted as the Morse code sequence · − (a short signal followed by a long signal). In each case, the information — the letter "A" — is the same. What changes is the encoding: the system of rules that maps human-readable characters to machine-transmittable signals.

Understanding text encoding isn't just academic trivia. Encoding mismatches cause garbled text in web pages, corrupted data in file transfers, broken string comparisons in code, and silent data loss in database migrations. This article explains the three most historically important text encoding systems — Morse code, ASCII, and binary (as a representation of modern Unicode) — how they relate to each other, and how to convert between them.

Morse Code: Encoding for the Telegraph Age

Morse code is the oldest widely used text encoding system, developed by Samuel Morse and Alfred Vail in the 1830s and 1840s for use with the electric telegraph. Its fundamental insight is simple: represent each letter as a unique sequence of two symbols — short signals (dots, written as ·) and long signals (dashes, written as −), where a dash is three times the duration of a dot.

The original American Morse code was superseded by International Morse Code, standardized by the International Telecommunication Union as ITU-R M.1677. The international version encodes the 26 Latin letters (A–Z), digits 0–9, and a small set of punctuation marks. Some examples: A is · −, B is − · · ·, S is · · ·, O is − − −, and the famous distress signal SOS is · · · − − − · · · (S-O-S with no inter-letter gaps).

Morse code is notable for being a variable-length encoding optimized for human transmission speed. The most common letters in English — E, T, A, I — have the shortest codes (E is a single dot, T is a single dash). Less common letters like Q (− − · −) and Z (− − · ·) have longer codes. This principle — assigning shorter codes to more frequent symbols — was later formalized in information theory as Huffman coding.

Morse code uses timing-based separators: one dot-length of silence separates the dots and dashes within a character, three dot-lengths separate characters within a word, and seven dot-lengths separate words. This makes it self-delimiting — a skilled operator can parse the stream in real time without needing fixed-length frames or explicit separator characters.

You can convert any text to Morse and back using our text to Morse converter. It handles the full ITU international Morse alphabet including numbers and common punctuation.

ASCII: The Foundation of Modern Text

ASCII (American Standard Code for Information Interchange) was developed by a committee of the American Standards Association beginning in 1961, with the first edition published in 1963 and the major revision published in 1967. It was designed to replace the patchwork of incompatible character encodings used by different computer manufacturers in the early 1960s.

ASCII assigns a number from 0 to 127 to each of 128 characters, requiring 7 bits of storage per character. The 128 code points break down as follows: positions 0–31 and 127 are control characters (33 total, including carriage return, line feed, tab, null, escape, and backspace). Position 32 is the space character. Positions 33–126 are the 94 printable characters: digits 0–9 (positions 48–57), uppercase A–Z (positions 65–90), lowercase a–z (positions 97–122), and 32 punctuation and symbol characters.

The design of ASCII was deliberately elegant. The digits 0–9 occupy positions 48–57, which means their lower 4 bits (the "nibble") directly encode their numeric value: the digit 5 is stored as binary 0110101, and the lower 4 bits 0101 equal 5. This made binary-coded decimal conversion trivial.

Uppercase and lowercase letters differ by exactly one bit: A (65, 1000001) and a (97, 1100001) differ only in bit 5. This meant that case conversion could be done with a single bitwise operation — toggle bit 5 to switch between upper and lower case. This was a deliberate design choice to simplify the hardware of keyboards and printers in the 1960s.

ASCII's limitation is obvious from its name: it's American. It encodes 26 Latin letters with no accents, no diacritics, and no characters from any non-Latin script. It can't represent résumé, naïve, café, über, or any text in Chinese, Japanese, Korean, Arabic, Hebrew, Cyrillic, or hundreds of other writing systems. This limitation drove the development of Unicode.

Convert text to its ASCII decimal values using our text to ASCII converter, which shows the numeric code point for each character.

Binary: How Computers Actually Store Text

When we say "text to binary," we mean expressing each character's numeric value as a sequence of 0s and 1s — the base-2 number system that underlies all digital computing. Binary isn't a separate encoding from ASCII or Unicode; it's the representation layer beneath them. ASCII says "A equals 65." Binary says "65 equals 01000001."

Every piece of data in a computer — text, images, audio, video, executable code — is ultimately stored as binary. What makes text special is the encoding layer that maps specific binary patterns to specific characters. In ASCII, the byte 01001000 means "H" (72 in decimal). The byte 01101001 means "i" (105 in decimal). The two bytes together, 01001000 01101001, encode the string "Hi."

Our text to binary converter transforms text into its binary representation — each character displayed as its 8-bit (byte) binary value. You can also use our hex/decimal converter to move between binary, decimal, and hexadecimal representations of character codes.

The relationship between text encodings and binary is hierarchical. At the bottom is binary — raw 0s and 1s. Above that is the encoding scheme (ASCII, UTF-8, UTF-16) that maps binary patterns to code points. Above that is the character standard (ASCII for 128 characters, Unicode for 149,000+ characters) that maps code points to characters. When you "convert text to binary," you're traversing all three layers: character → code point → binary.

From ASCII to Unicode: Solving the 128-Character Limit

ASCII's 128-character limit was a problem almost immediately. European languages needed accented characters. Asian languages needed thousands of ideographs. Mathematicians needed special symbols. The initial solution was "extended ASCII" — using the unused 8th bit to encode 128 additional characters, giving 256 total. But different systems used those extra 128 positions for different characters: IBM's Code Page 437 (used on the original IBM PC) put box-drawing characters and some accented letters there. ISO 8859-1 (Latin-1) put Western European accented characters there. Windows-1252 added smart quotes and other typographic characters. This meant the same byte value could represent different characters depending on which code page was active — a recipe for garbled text when files moved between systems.

Unicode was created in the late 1980s to solve this once and for all. Rather than 128 or 256 characters, Unicode aims to assign a unique number (called a "code point") to every character in every writing system, past and present. As of Unicode 16.0, there are 154,998 assigned characters spanning 168 modern and historic scripts, plus symbols, emoji, and control characters. Code points are written as U+XXXX — for example, A is U+0041, the Euro sign is U+20AC, and the emoji "fire" is U+1F525.

Unicode is a character standard, not an encoding. The encoding — how those code points are stored as bytes — is handled by UTF-8, UTF-16, or UTF-32.

UTF-8 is the dominant encoding on the web (used by over 98% of websites). It's a variable-length encoding: ASCII characters (U+0000 to U+007F) use 1 byte (and are byte-identical to ASCII, ensuring backward compatibility). Characters from U+0080 to U+07FF (most Latin accented characters, Greek, Cyrillic, Arabic, Hebrew) use 2 bytes. Characters from U+0800 to U+FFFF (CJK ideographs, most of the Basic Multilingual Plane) use 3 bytes. Characters from U+10000 to U+10FFFF (emoji, historic scripts, mathematical symbols) use 4 bytes. This means English text in UTF-8 is exactly the same size as ASCII, while supporting the full range of Unicode when needed.

UTF-16 uses 2 bytes for characters in the Basic Multilingual Plane (U+0000 to U+FFFF) and 4 bytes for characters outside it (using surrogate pairs). It's used internally by JavaScript, Java, and Windows.

UTF-32 uses 4 bytes for every character regardless of code point. It's simple but space-inefficient, used primarily in internal processing where fixed-width access is needed.

For a deeper look at how Unicode enables "fancy text" styles using mathematical symbol blocks, see our article on What Is Unicode? How Fancy Text Actually Works.

How the Three Encodings Relate

Morse, ASCII, and binary aren't competing systems — they're solutions to the same problem (encoding text as signals) designed for different transmission media and different eras.

Morse code was designed for human operators transmitting over telegraph wires. Its variable-length, timing-based structure is optimized for human speed and real-time parsing. You couldn't efficiently use Morse for computer communication because the timing-based separators require continuous attention and are error-prone at machine speeds.

ASCII was designed for machines communicating over serial data links (teletypes, terminals, modems). Its fixed-width, 7-bit structure is optimized for reliable machine parsing — every character is exactly 7 bits, no timing analysis needed. But it's limited to 128 characters, insufficient for global text.

Unicode with UTF-8 encoding was designed for the global internet. Its variable-length structure (1–4 bytes) is optimized for backward compatibility with ASCII while supporting every script in the world. It's the final answer to the text encoding problem — and the reason you can have English, Chinese, Arabic, emoji, and mathematical symbols all in the same document.

The binary representation is the physical layer beneath all of these. ASCII 65 and Unicode U+0041 and UTF-8 byte 0x41 all refer to the same letter "A" stored as the same binary pattern 01000001. The encoding tells you how to interpret the binary; the binary is the actual data.

Encoding in Practice: Common Conversions

Text to binary is useful for educational purposes (understanding how data is stored), debugging encoding issues (examining the actual bytes), and some niche applications like binary art or steganography. Our text to binary converter outputs each character as an 8-bit binary string separated by spaces.

Text to ASCII values is useful for debugging character encoding issues (seeing the numeric code point of each character), understanding the difference between visually similar characters (like the regular space U+0020 vs. non-breaking space U+00A0), and teaching how computers represent text. Our text to ASCII converter shows the decimal value for each character.

Text to Morse code is useful for amateur radio, survival signaling, educational demonstrations, and simple encryption (Morse isn't encryption in any cryptographic sense, but it does make text unreadable to casual observers). Our text to Morse converter handles the full ITU alphabet.

Text to Base64 is a different kind of encoding entirely — it converts arbitrary binary data into an ASCII-safe string using a 64-character alphabet. It's used for embedding binary data in text-based formats like JSON, XML, and email (MIME). For details, see our article on Base64 encoding and try our Base64 encoder/decoder.

Encoding Problems and How to Fix Them

The most common encoding problem is mojibake: garbled text produced when bytes encoded in one system are decoded in another. For example, the UTF-8 encoding of "é" is the two-byte sequence 0xC3 0xA9. If those bytes are interpreted as ISO-8859-1 (Latin-1), they display as "é" — because 0xC3 maps to "Ã" in Latin-1 and 0xA9 maps to "©". The fix is ensuring UTF-8 is declared at every handoff point: the HTML <meta charset="UTF-8"> tag, the HTTP Content-Type: text/html; charset=utf-8 header, the database connection charset, and the file-reading code in your application.

Another common problem is the "replacement character" — the black diamond with a question mark (U+FFFD, �). This appears when a decoder encounters a byte sequence that's invalid in the declared encoding. It means bytes were corrupted or the encoding declaration is wrong. Unlike mojibake, replacement character errors often indicate actual data loss — the original bytes may not be recoverable.

A third problem is the Byte Order Mark (BOM), U+FEFF, which some editors prepend to UTF-8 files. In UTF-16 and UTF-32, the BOM serves a purpose (indicating byte order). In UTF-8, it's unnecessary and often harmful — it can cause scripts to fail, JSON parsers to choke, and invisible characters to appear at the beginning of files. If you encounter mysterious parse errors at the start of an otherwise valid file, check for a BOM with a hex editor.

The Bottom Line

Text encoding is the invisible infrastructure beneath everything digital. Every character you read on screen is the result of a chain of encoding decisions — from the Unicode standard that assigns it a number, to the UTF-8 encoding that stores that number as bytes, to the binary representation of those bytes in memory. Understanding this chain helps you debug garbled text, choose the right encoding for your project, and appreciate how seamlessly modern systems handle the dozens of writing systems that ASCII could never support.

Whether you're converting text to binary to understand how computers store it, to ASCII values to debug an encoding issue, or to Morse code for a ham radio session, the underlying principle is the same: text is numbers, and encoding is the dictionary that translates between them.

References

Wikipedia — ASCII — History, design decisions, and full character table.

The Unicode Consortium — Official home of the Unicode standard.

UTF-8, a Transformation Format of ISO 10646 (RFC 3629) — The specification defining UTF-8 encoding.

ITU-R M.1677-1 — International Morse Code — The current standard for international Morse code.

Joel Spolsky — The Absolute Minimum Every Software Developer Must Know About Unicode and Character Sets — The classic introduction to text encoding for developers.