ASCII: one byte, seven usable bits
ASCII (American Standard Code for Information Interchange) assigns a number from 0 to 127 to each letter, digit, punctuation mark, and control character it defines. Because 127 fits in 7 bits, ASCII text technically only needs the lower 7 bits of each byte — the 8th bit was historically left unused, or repurposed by various vendors for their own extensions, which is part of why "extended ASCII" isn't one standard but many incompatible ones. This tool implements strict 7-bit ASCII: any byte value from 0x80 upward is rejected as outside ASCII's defined range, rather than silently mapped to some vendor-specific extended character.
What ASCII actually covers
The 128 code points split roughly into three groups: 33 control characters (0–31, plus 127) that were originally meant to control physical teletype hardware — line feed, carriage return, tab, and the "bell" character among them, several of which are still meaningful in modern text processing even though the hardware they were designed for no longer exists; 94 printable characters (33–126) covering uppercase and lowercase English letters, digits 0–9, and standard punctuation; and one space character (32). Notably absent: any accented letter, any non-Latin script, currency symbols other than the dollar sign, and emoji — all of which require an encoding with a larger code space, which is exactly what UTF-8 was designed to provide.
Why hex and ASCII pair so naturally
Because ASCII is a single-byte encoding, every ASCII character corresponds to exactly one hex byte pair, with no variable-width complications the way UTF-8 has for non-ASCII characters. That one-to-one mapping is why hex dumps of plain-text files are so straightforward to read once the pattern is familiar: each pair of hex digits is one character, in order, with no lookahead or multi-byte decoding required. It's also why ASCII is often the first encoding developers reach for when manually inspecting unknown byte data — if hex bytes decode to sensible-looking English text under strict ASCII rules, that's a strong signal the data actually is ASCII (or ASCII-compatible UTF-8) text, rather than something else entirely.
Where ASCII still matters
Even though UTF-8 has effectively superseded ASCII for general text, ASCII compatibility remains a hard requirement in many places: HTTP headers, email headers, DNS hostnames, many configuration file formats, and most programming language identifiers (variable and function names) are still restricted to ASCII or a close variant, specifically because pure ASCII is unambiguous, has no encoding-detection problem, and is supported identically by essentially every system ever built. Protocols that need to transmit non-ASCII data through an ASCII-only channel — punycode for internationalized domain names, or MIME encoded-words in email headers — work by encoding the non-ASCII content into a pure-ASCII-safe format rather than by changing the channel's fundamental restriction to ASCII.
A brief history worth knowing
ASCII was standardized in 1963 and revised through the 1960s, largely to give American computer manufacturers a common character encoding so text could move between different vendors' hardware without corruption — a real problem at the time, since manufacturers had been using incompatible in-house encodings. It drew heavily on existing telegraph and teletypewriter codes, which explains why so many of its low-numbered control characters (bell, backspace, carriage return) map to physical actions a teletype machine would take rather than abstract text-formatting concepts. That hardware-oriented origin is also why some ASCII control characters feel redundant or obscure today — they were meaningful instructions to a specific class of 1960s hardware that has long since disappeared from common use.
Recognizing ASCII in a hex dump
A practical trick for scanning hex dumps by eye: printable ASCII bytes fall in a narrow, recognizable hex range — 0x20 through 0x7E. Uppercase letters run 0x41–0x5A, lowercase letters0x61–0x7A, and digits 0x30–0x39. Bytes well outside that range (very low values other than common whitespace like 0x09/0x0A/0x0D, or anything at 0x80 and above) are a signal that the data either isn't plain ASCII text, or contains binary structure mixed in with text — exactly the kind of pattern recognition that makes hex dumps useful for quickly classifying unknown file content before reaching for more specialized tools.