Converting ASCII to char means mapping a decimal value between 0 and 127 back to the exact character that the standard 7-bit ASCII table assigns to it: 65 becomes "A", 97 becomes "a", 32 becomes a space, and 10 becomes a line feed. The task shows up whenever you have a list of decimal numbers — from a log file, a programming exercise, a network protocol dump, or a textbook example — and you need to see or copy the characters they stand for. Standard ASCII only covers values 0 through 127, so any number outside that range signals that the data is not ASCII and needs a different decoder such as a UTF-8 or code-page tool. Because the 7-bit table is fully standardized (see IETF RFC 20 and the Unicode C0 Controls and Basic Latin chart), the conversion is deterministic: the same decimal value always yields the same character on any compliant system, and a strict converter will fail closed rather than guess at the result.
How the ASCII table is organized
The 7-bit ASCII table divides its 128 code points into a few loose groups. Codes 0 through 31 are the C0 control characters, which were originally designed to control teleprinters and early terminals — tab, line feed, carriage return, escape, and so on. Code 32 is the space; codes 33 through 47 cover punctuation; codes 48 through 57 cover the digits 0 through 9; codes 65 through 90 cover the uppercase Latin letters A through Z; and codes 97 through 122 cover the lowercase Latin letters a through z. The remaining slots (58–64, 91–96, 123–126) hold punctuation and brackets, and 127 is DEL, the delete control. The exact assignments come from RFC 20, the standard that defined ASCII, and they are mirrored in the Unicode C0 Controls and Basic Latin chart so that the first 128 Unicode code points remain byte-for-byte compatible with ASCII. Memorizing the high-level shape of the table — digits at 48, uppercase at 65, lowercase at 97 — makes most "char from ASCII" lookups trivial without a reference.
How to convert ASCII codes to characters
For a quick, error-checked conversion, open the ASCII Converter and follow these steps:
- Pick "Codes to Text" so the tool knows you are feeding in decimal numbers rather than plain text.
- Paste your list of decimal values into the input area, separating numbers with spaces, commas, or line breaks — any mix works because the tokenizer treats whitespace and commas as separators.
- Click "Convert ASCII" and read the result in the output area.
- Inspect the output for invisible control characters (tabs, line feeds, NULs) and copy only the visible portion, or copy the decimal output if you need to keep the structure intact.
The same tool also runs in reverse: choose "Text to Codes" to turn each character into a space-separated decimal integer. Both directions enforce the same 0–127 boundary.
A worked example
Take the decimal list "72 101 108 108 111". Reading against the ASCII table, 72 is "H", 101 is "e", 108 is "l", 108 is "l", and 111 is "o". Concatenated, the five codes spell "Hello". This is the same arithmetic a decoder performs internally: tokenize the input on whitespace and commas, parse each token as an unsigned integer from 0 to 127, and look up the character. Nothing else changes between your input and the output. For the binary side of the same characters, see the practical ASCII-to-binary walkthrough.
Understanding control characters in the output
The most surprising part of decoding ASCII is that codes 0–31 and 127 produce no printable glyph at all. Code 9 is a tab, 10 is a line feed, 13 is a carriage return, 0 is NUL, and 127 is DEL. When you decode a list that contains 9, your output textarea may advance to the next tab stop; when it contains 10 or 13, it may insert a line break; when it contains other controls such as 1, 2, 7, or 127, you will see nothing because they have no visual representation in plain text. Copying these invisible characters into another application can trigger application-specific behavior — for example, a tab inside a filename field may be silently stripped, and a stray NUL can confuse a parser. If visibility matters, use the decimal output instead, or paste the codes into a byte-aware editor such as a hex viewer. The controls most people encounter are listed below.
| Decimal | Name | Visual behavior |
|---|---|---|
| 0 | NUL | No glyph |
| 9 | Tab | Advances to next tab stop |
| 10 | Line Feed (LF) | Inserts a line break |
| 13 | Carriage Return (CR) | Inserts a line break |
| 32 | Space | Visible blank |
| 127 | DEL | No glyph |
When ASCII is not the right encoding
ASCII is often used loosely as a synonym for "plain text", but the strict 7-bit table only covers the Latin alphabet, digits, common punctuation, and 33 control codes. It does not include accented letters (é, ñ, ü), non-Latin scripts (汉字, Ж, א), emoji, or any symbol above decimal 127. If your input contains such characters, an ASCII decoder must reject them, because the phrase "extended ASCII" can refer to several incompatible code pages (Windows-1252, ISO-8859-1, MacRoman, and others) that disagree on values above 127. The ASCII Converter fails closed: it stops at the first character outside 0–127 and reports its position, rather than guessing a code page. For accented Latin text, emoji, or CJK, use a UTF-8 aware converter; for raw bytes from a network dump, use a hex-to-text tool that decodes UTF-8 strictly. The official assignments are pinned in the Unicode C0 Controls and Basic Latin chart.
ASCII Converter vs related encoding tools
Different encoding tools solve different jobs, and it helps to know which one matches the data you actually have. The table below lists the most common adjacent tools and what each one is for.
| Tool | Input format | Output format | Use when |
|---|---|---|---|
| ASCII Converter | ASCII text or decimal 0–127 | Decimal codes or ASCII text | Strict 7-bit round-trips |
| ASCII Table | None (reference) | One-row searchable reference | Looking up a single value |
| Text to Hex | UTF-8 text | Hexadecimal bytes | You need the byte-level encoding |
| Binary to Text | UTF-8 text or 8-bit binary | UTF-8 text or 8-bit binary | Working in binary rather than decimal |
| Base64 Encode / Decode | UTF-8 text or Base64 | Base64 or UTF-8 text | Transport-safe text payloads |
The key difference is scope. ASCII Converter handles a complete text sequence as decimal 7-bit values, while a hex or binary converter encodes the UTF-8 byte representation of the same characters (which can span one or more bytes per character). For Unicode code points, UTF-8 bytes, legacy code pages, or locale-specific character conversion, switch to a converter that names its encoding explicitly rather than assuming ASCII.
Practical limits to keep in mind
The ASCII Converter enforces strict two-way conversion between standard 7-bit ASCII and decimal code values. Encoding rejects the first character outside 7-bit ASCII and reports its position in the input. Decoding requires plain decimal integers and rejects signs, fractions, hexadecimal prefixes, empty tokens, and any value above 127. The input limit is 100,000 UTF-16 code units, with a 50,000-code bound on decoding, so extremely large lists should be split into chunks. All processing stays in the current browser tab — encoding, decoding, and validation run locally and no input is uploaded. Eight independent standard fixtures pin the lower boundary, TAB, LF, space, digit zero, uppercase A, lowercase a, and the upper boundary, so the round-trip is reproducible. These bounds exist so the tool can fail closed when the data is not ASCII, which is the safest behavior for a deterministic 7-bit table.