Every character you type is stored as a number. The letter A is 65, a space is 32, and the line break at the end of this paragraph is 10. Most of the time you never see those numbers, which is exactly as it should be. But when something goes wrong with text, the numbers are usually where the answer is.
This converter goes both ways: text to character codes, and character codes back to text, in four different number bases.
Why you would want the numbers
The usual reason is debugging. A comparison that should match keeps failing, a field that looks empty is not, an import rejects a row that appears identical to the one above it. Converting the text to character codes exposes what is actually in the string. A non-breaking space shows up as 160 rather than 32. A Windows line ending is revealed as 13 followed by 10 where you expected just 10. A zero-width space - invisible by definition, and a common stowaway in text copied from Word or a web page - appears as 8203.
The second reason is that some systems still speak in codes. Older protocols, certain configuration formats, and a lot of embedded hardware documentation express characters numerically. Being able to read a line of hex and turn it back into words saves a great deal of guessing.
Choosing a base
Decimal is the everyday one - 65 for A. This is what most ASCII tables print and what you will see in documentation aimed at general readers.
Hexadecimal is what programmers use, because two hex digits cover exactly one byte. A is 41, and any byte from 00 to FF fits in two characters. Hex dumps, colour codes, memory addresses and network captures are all hex.
Binary gives you the actual bits - A is 01000001. Rarely practical for real work, but it is the format that makes bitwise operations comprehensible, which is why it turns up constantly in teaching material.
Octal is the historical one. It survives mainly in Unix file permissions and a few older systems.
Separators and padding
The separator setting is more consequential than it looks. Choose a space, comma or newline and each code is written out with no padding: 65 66 67. Choose no separator and the tool pads every value to a fixed width instead - two digits for hex, eight for binary, three for decimal - producing an unbroken string like 010203.
This padding is not decoration. Without it, an unseparated string is ambiguous: does 1234 mean characters 12 and 34, or 1, 2, 3 and 4? Fixed-width encoding removes the question, and the decoder relies on it. If you are pasting in codes from elsewhere with no separators, make sure the base you pick matches the width they were written at.
Beyond ASCII
Strictly, ASCII covers only the first 128 values. This tool does not stop there. Paste an accented letter, a Chinese character or an emoji and you will get its full Unicode code point - é is 233, 中 is 20013. Decoding works the same way in reverse. The name is conventional rather than precise, and the extra range is almost always what you actually need, since very little real text stays inside the original 128 characters.