ASCII Table

Where the ASCII table actually helps

The first mass of tasks is logs and protocols. In HTTP every header line ends with the byte pair 13 and 10, and until you know that, traffic between a client and a server looks like a pile of random symbols. In telemetry and exchanges with microcontroller devices, data often arrives as raw bytes: without the table you cannot tell whether 0x0A inside the stream is a separator or whether 0x1B opens a terminal command. Even parsing a CSV with an odd delimiter boils down to the question "what is the character with code 9", and the answer takes one search.

The second mass of tasks lives in programming. Escape sequences in C, Python and JavaScript are codes from this table: \n, \t, \r, \0. Comparing characters by code drives sorting: digits come before uppercase letters, uppercase before lowercase, and that is not a whim but a direct consequence of code order. Character-by-character parsing, input validation, hunting for unprintable characters in data — all of it leans on the ranges 0–31 and 32–126. Computer science exercises that ask you to turn a word into codes and back use the same table, and the underlying theory pairs well with the article on binary code.

• Log analysis: what the byte 0x0A or 0x1B inside a stream means
• Protocols: CR+LF in HTTP, delimiters on serial ports
• Code: escape sequences \n, \t, \r and the NUL that ends C strings
• Sorting: why digits sort before letters and uppercase before lowercase
• Study tasks: convert a word to codes and rebuild it
• Debugging: finding unprintable characters that break string comparison

Typical mistakes when working with codes

The most common mistake is mixing number systems. The numbers 65, 0x41 and 101 describe the same code, but read differently: 65 is decimal, 41 after 0x is hexadecimal, 101 is octal. Someone who sees byte 0x41 in a log sometimes looks up row 41 in the table and finds the wrong character: code 41 in decimal is a closing parenthesis. The rule is simple: determine the base first, then search. Hex is always recognizable by the letters A–F in the notation or by the 0x prefix.

The second mistake is extending the table to Cyrillic. The Russian capital А looks like the Latin A, but its Unicode code is U+0410, and in UTF-8 it takes the two bytes D0 90. String comparisons fail for exactly this reason when one letter is typed on a Latin layout and the other on a Cyrillic one, even though the text looks identical on screen. The related confusion is "a character equals a byte": in UTF-8 that holds only for the ASCII range, and a single emoji can take four bytes. To check what a file actually contains, start with the encoding detector.

• 65, 0x41 and 101 are one code in three bases, not three different codes
• Cyrillic is outside 0–127: the Russian А is U+0410, not 65
• In UTF-8 a character above 127 takes two or more bytes
• Space has code 32, not 0, and it is a printable character too
• CR and LF are two different codes: Windows pairs them, Unix uses LF alone
• DEL is 127, not 8: code 8 is backspace, moving one character left

Worked example: the letter A from code to byte

Take the uppercase Latin A and follow it through the table. The decimal code is 65, hexadecimal 0x41, octal 101, binary 01000001. All four notations describe the same byte content. In binary, two bits are set: the one weighted 64 and the one weighted 1, and 64 plus 1 gives exactly 65. The highest bit is zero — the code falls into the first 128 values, so the character is guaranteed to be in the table. The bit-level view also explains case switching: lowercase a is written 01100001, differing from the uppercase by the single bit weighted 32, which is why 65 plus 32 equals 97.

The same method works for any character in the table. Lowercase a differs from uppercase by exactly one bit: 01100001 versus 01000001. The digit 0 is 00110000, so all digits occupy 48–57 in a row. Space is 00100000: the only set bit is weighted 32, and the code of space really is 32. Below is a summary for the characters people come back to most.

ASCII uses seven of the eight bits in a byte, so in pure ASCII the highest bit of every byte is zero; the eighth bit was historically reserved for parity checking.

ASCII among other ways of writing data

A code table is the bridge between text and numbers. From there numbers move freely between bases: 0x41 becomes 65 and 01000001, and every step of that is handled by the base converter. For long byte sequences, a binary translator works better than a table — it breaks a string into ones and zeros character by character, covered in more detail in the article on binary code. When bytes need to travel inside text, they get packed into Base64, where every three bytes become four characters; the mechanics are explained in the plain-language guide to Base64.

It helps to keep the limits in view too. ASCII covers only Latin letters with digits and signs: every other language needs other Unicode codes, arbitrary byte sequences need hex dumps, and files of unknown origin need an encoding check first. But because UTF-8 preserved all 128 codes as they were, the table remains a working tool rather than a museum piece: any byte below 128 you will decode from it as confidently as in 1963.

• ASCII codes are the first 128 Unicode code points, with no deviations
• A hex dump reads in digit pairs: each pair is one byte
• A separate converter handles numbers between any bases
• Base64 is not a character encoding but a way to pack bytes into text
• Mojibake usually means a re-encoding mismatch, not broken data