ASCII to hex conversion turns each character in a text string into its standard 7-bit code, then writes that code in base 16. The standard 7-bit ASCII table defines exactly 128 characters, numbered 0 through 127, and each of those numbers has a fixed hexadecimal equivalent: uppercase A is decimal 65 and hex 41, the digit 0 is decimal 48 and hex 30, the space character is decimal 32 and hex 20, and the printable tilde is decimal 126 and hex 7E. The ASCII Converter handles the first half of that pipeline by emitting each character's decimal code, and the mapping from decimal to hex is a purely arithmetic step you can apply to those numbers. Every assignment follows IETF RFC 20 and is cross-checked against the Unicode C0 Controls and Basic Latin chart, so the same letter always maps to the same decimal code and the same hex code on any conformant tool.
What "ASCII to Hex" Actually Means
The phrase covers two distinct operations. The first is the encoding step: each character in the input string is replaced by its assigned 7-bit code value. The second is the representation step: that integer is written in hexadecimal so it is easier to read alongside bytes, memory addresses, configuration data, and protocol logs. Both steps are deterministic, and no information is lost or gained by switching between decimal and hex — they are simply two notations for the same underlying number.
It is worth being precise about the boundary. ASCII is a 7-bit character set, which means the highest legal code is 127. The phrase "extended ASCII" is sometimes used loosely for values 128–255, but those values are not part of any single standard; different operating systems and applications assign them differently. Windows-1252 and ISO-8859-1 are two common but incompatible code pages that occupy that range, and a tool that silently reinterprets 128–255 as ASCII will produce text that looks correct on one machine and breaks on another. A strict converter refuses to guess.
How to Convert ASCII to Hex Using the ASCII Converter
- Open the ASCII Converter and choose the text-to-codes direction so each character is mapped to its decimal code value.
- Type or paste the ASCII text you want to encode into the input field. Stay within the 7-bit range — ordinary English letters, digits, punctuation, and the basic control characters are all fine.
- Select Convert ASCII. The output field shows each character as a space-separated decimal integer from 0 to 127, in the same order as the input.
- Convert each decimal integer to its two-digit hexadecimal equivalent. For reference, decimal 65 becomes hex 41, decimal 48 becomes hex 30, decimal 32 becomes hex 20, and decimal 10 becomes hex 0A. The Text To HEX tool can take that decimal list and emit a hex string directly if you want to skip the manual arithmetic.
- Copy the result. If the input included tabs, line feeds, or other control characters, the converted output may be hard to read because those codes render invisibly — review the decimal list to confirm what was actually encoded before treating the hex form as canonical.
Why the Output Is Decimal, Not Hex
The ASCII Converter emits decimal because decimal is the canonical form of the 7-bit code value defined in RFC 20, and decimal is the form most programming languages, configuration files, and reference tables use to describe ASCII. Hex is one possible representation of the same integer, so the conversion is reversible without any loss of precision. A simple worked example for the string "Hi": the letter H is decimal 72 and hex 48, the letter i is decimal 105 and hex 69. The converter produces "72 105" and the matching hex string is "48 69".
There is a practical reason to keep the converter decimal-first. Every value in the output is a single integer between 0 and 127, which is exactly the range a strict ASCII tool can validate. The moment the output crosses into hex, the user can be tempted to add leading zeros, group bytes, or slip a 0x prefix in front of one token and not another, and that small inconsistency is exactly the kind of mistake that breaks parsers and debuggers. Decimal output is harder to misformat.
ASCII Characters and Their Decimal and Hex Values
The following table shows a small window of the 7-bit ASCII table. The decimal and hex values in it are not computed — they are the permanent assignments defined by RFC 20 and reproduced by the Unicode C0 Controls and Basic Latin chart. There is no range of "correct" answers; every conformant implementation must produce these same pairs.
| Character | Decimal code | Hex code | Category |
|---|---|---|---|
| NUL | 0 | 00 | Control |
| TAB | 9 | 09 | Control |
| LF | 10 | 0A | Control |
| CR | 13 | 0D | Control |
| Space | 32 | 20 | Printable |
| 0 | 48 | 30 | Digit |
| A | 65 | 41 | Uppercase letter |
| a | 97 | 61 | Lowercase letter |
| ~ | 126 | 7E | Punctuation |
| DEL | 127 | 7F | Control |
Every value in the table is 7-bit, so each hex code is exactly two hex digits. That is a defining property of standard ASCII — there is no length-prefix, no variable-width encoding, and no multi-byte sequence to worry about. If the hex output ever shows three or more digits for a single character, the input is no longer ASCII and a different converter is required.
Control Characters and Invisible Output
Codes 0 through 31 and code 127 are control characters, and most of them do not produce a visible glyph. TAB (decimal 9) advances the cursor, LF (decimal 10) starts a new line, CR (decimal 13) returns to the start of the current line, and NUL (decimal 0) and DEL (decimal 127) are typically invisible in any text editor. When the ASCII Converter emits these characters in codes-to-text mode, the output textarea may look shorter than the number list suggests, because the renderer is showing line breaks and tabs but nothing else. That is correct behavior, not a bug.
The invisibility has a practical consequence. If you copy the decoded text into another application, the receiving application will interpret those control characters according to its own rules, and a TAB or LF embedded in the middle of a single-line field can produce surprising results. For most debugging tasks, the decimal or hex number list is the safer artifact to keep, because every character is visible as a number. A byte-aware editor that shows non-printable characters explicitly is another reasonable choice when you need to see exactly what was encoded.
When the Converter Rejects Input
The converter is strict on purpose. Encoding rejects the first character outside 7-bit ASCII and reports its position, so if the input contains an em dash, an accented letter, or an emoji, the tool refuses to silently reinterpret it as UTF-8 or as a legacy code page. Decoding requires plain decimal integers and rejects signs, fractions, hexadecimal prefixes, empty tokens, and any value above 127. The accepted range is exactly 0 through 127, and the input limit is 100,000 UTF-16 code units, with a 50,000-code bound on decoding.
These guards do not exist to make the tool difficult to use. They exist because the phrase "ASCII to hex" is often used loosely to mean "text to hex" in general, and a tool that quietly accepts Unicode characters and emits them as multi-byte UTF-8 hex will produce output that looks reasonable but cannot be decoded back to the original text on a system that expects a different encoding. Failing closed forces the right tool to be used for the right job. For Unicode code points, UTF-8 bytes, legacy code pages, binary files, or locale-specific character conversion, use a converter that explicitly names the required encoding rather than treating it as ASCII.
Tools That Cover the Adjacent Cases
ASCII to hex is one slice of a larger family of encoding problems. The ASCII Converter handles the strict 7-bit slice. The Text to HEX tool encodes any UTF-8 text into hexadecimal bytes so that accented characters and emoji round-trip cleanly. The Hex to Text Converter parses hexadecimal bytes with explicit separator and 0x-prefix rules and decodes only complete valid UTF-8 without silent replacement. For character-level work that needs the actual Unicode code point in U+ notation, the Unicode Encoder / Decoder is the right destination. Each of these tools names the encoding it implements, which is the safer pattern than treating "text" as a single monolithic category.