The 128 codes
ASCII numbers its characters 0 to 127, which fits in seven bits. Codes 0 to 31 and 127 are control codes, like tab (9), line feed (10), carriage return (13) and delete (127). Codes 32 to 126 are the printable characters: the space, punctuation, the digits starting at 48, uppercase letters at 65 and lowercase at 97.
The layout is deliberate. Lowercase sits 32 codes after uppercase, which is a single bit (0x20), so a program can change case by flipping one bit. The digits 0 to 9 use the codes 0x30 to 0x39, so the low four bits of a digit's code are the digit itself.
The spare bit
ASCII uses seven bits of an 8-bit byte, so the top bit is free. Vendors used it for 128 more characters, and those 8-bit code pages, like ISO 8859-1 (Latin-1) and Windows-1252, keep ASCII in the lower half and add accented letters and symbols above it. They aren't ASCII. A file labeled ASCII that contains an é is really in a code page or in UTF-8, and opening it with the wrong one gives mojibake.
UTF-8 keeps the lower half identical and uses the top bit as a signal: a byte of 128 or more is part of a longer character. That's why any ASCII file is already a valid UTF-8 file.
ASCII inside other formats
Many formats are built on ASCII even when they carry other text. RFC 3986 says a URL is composed from a limited set of characters, which is why everything else gets percent encoding. Base64 picks its alphabet from US-ASCII, so its output is plain ASCII text, one byte per character: 44 bytes for a 32-byte hash. Base32 and hex do the same, and JSON's structural characters like {, }, : and , are all ASCII too.
The practical rule: treat ASCII as the first 128 characters of UTF-8, and you rarely need to think about it as a separate encoding.