Decimal and binary, not hex
ASCII is specifically the 7-bit character set — codes 0 through 127 — so this tool works in the notations ASCII is usually discussed in: decimal codes and 8-bit binary, plus a lookup for the 33 non-printing control characters (NUL, ESC, DEL, and friends) that make up the first and last entries of the table. For hex-based escape syntax — JavaScript, JSON, HTML/XML entities, or a SQL hex literal — see Hex Encode instead.
Any character above 127 is flagged rather than silently converted — those code points are valid Unicode, but they aren't ASCII, and treating them as if they were is exactly how encoding bugs happen. For the full Unicode picture on out-of-range characters, see Unicode Converter.
Reading the table
Control characters (codes 0–31, plus 127) don't have a printable glyph, so their row shows a placeholder dot in the Char column and their standard abbreviation instead — most come from teletype terminal control codes and still matter today: LF and CR are the two halves of a line ending, HT is a tab, ESC starts terminal escape sequences, NUL terminates C strings.
FAQ
Why does binary sometimes have more than 8 digits?
A character above 127 doesn't fit in a single byte, so its binary form is shown at its natural bit width instead of padded to 8 — a reminder that it's not representable as one ASCII byte at all.
Do the binary codes need to be padded to 8 bits when building text?
No — 1000001 and 01000001 both parse as 65 (A). Padding is for readability, not required.
Try it yourself
For hex-based escape syntax across JavaScript, JSON, HTML/XML, and SQL, see Hex Encode and Hex Decode. For code point, script, and normalization details beyond the ASCII range, see Unicode Converter.