Text to ASCII Converter, Encode & Decode Code Points (Dec, Hex, Bin)

The Text to ASCII converter translates any string into its numeric code points and back, supporting decimal (e.g. 72 101 108 108 111 for Hello), hexadecimal (0x48 0x65 0x6C 0x6C 0x6F), and binary (0b01001000 0b01100101 …) output. Paste any text and the matching code stream appears instantly; paste a stream and the original text comes back round-trip. Every code point is classified (printable ASCII, control, extended, or Unicode), the conversion is bidirectional and lossless within the 0..0x10FFFF range, and nothing leaves your browser, the whole algorithm runs as a JavaScript state machine on the client.

How to use

1. Pick the direction. Use the Text → Codes tab to encode any string into numeric code points, or Codes → Text to paste a code stream and decode it back.
2. Type or paste. Either text or the code stream updates the other side live as you edit.
3. Choose the output base, decimal, hex, or binary, and the separator (space, comma, or run-on). When using hex or binary you can also toggle a 0x / 0b prefix.
4. Load a Quick test case below the editor to verify the converter against the canonical ASCII table.

The ASCII standard

ASCII (American Standard Code for Information Interchange) was first published as ASA X3.4-1963 and revised to ASA X3.4-1977 then ANSI X3.4-1986. The standard defines 128 code points, 7 bits, numbered 0 through 127:

• Codes 0..31 (plus 127) are control characters with names like NUL, SOH, STX, ETX, BEL, LF, CR, ESC, and DEL. They predate ASCII being used as a text encoding and were originally designed for controlling teleprinters, line printers, and teletypes rather than being displayed.
• Codes 32..126 are printable characters: space (32), digits 0 to 9 (48 to 57), uppercase A-Z (65 to 90), lowercase a-z (97 to 122), and the visible punctuation marks.
• Code 127 is DEL, the canonical "rub-out" character.

The international standardisation counterpart ISO/IEC 646 (1991) keeps the same 128 positions but lets each country swap a small number of code points for local letters (for example, #, $, @, [, \, ], ^, `, {, |, }, ~ in the US variant, ASCII proper, are replaced by accented letters in national variants). RFC 20 (1969) restates ASCII for network interchange and is the authority cited by HTTP, SMTP, and telnet specifications.

Worked examples

The following six examples are the Quick test cases pre-loaded into the converter; click any one to load it.

Round-trip tests (72 101 108 108 111 → "Hello" → 72 101 108 108 111) close exactly. Plain numbers without a 0x or 0b prefix are interpreted as decimal by default; the decoder accepts 0xFF, 0b1010, 65, and even raw hex FF in mixed sequences (the parser tries decimal first, then hex).

Code stream examples in different bases

The Text → Codes tab supports any of three numeric bases and any of three separators:

• Decimal, space-separated (default for Hello): 72 101 108 108 111.
• Hex with 0x prefix, comma-separated: 0x48, 0x65, 0x6C, 0x6C, 0x6F.
• Binary with 0b prefix, run-on (no separator): 0b010010000b011001010b011011000b011011000b01101111.

When you need to embed a code stream in source code, the comma + hex form is the most readable. When debugging byte streams or writing them into a hex dump, raw 0x with spaces is standard. When teaching byte-level encoding, run-on binary illustrates the 8-bit structure most clearly.

Decoding rules

The decoder accepts the following token shapes:

Tokens are split on whitespace (space, tab, newline) and commas. A run-on sequence like 0x48 0x65 0x6C 0x6C 0x6F is fine; 0x480x65… (no separator) is not, at least one whitespace or comma must appear between tokens. Out-of-range codes (below 0 or above 0x10FFFF) and unparseable tokens are surfaced as red rows in the per-token breakdown and the decoded-text panel shows "Invalid code sequence".

Where it shows up

ASCII predates modern computing and has surprising staying power:

• Internet standards (HTTP, SMTP, telnet, NNTP). RFC 20 is referenced directly. Most protocol headers are restricted to printable ASCII plus CRLF line endings; non-ASCII bytes must be encoded (typically as UTF-8).
• Programming and debugging. When you hexdump a file, every printed ASCII byte is the result of cp < 0x80. The actual on-disk bytes for an English sentence are identical to its ASCII code points. Beyond that, character-encoding bugs (the classic mojibake, "Müller" appearing as "Müller") are usually a single byte being interpreted with the wrong code-page, and inspecting code points is the first diagnostic.
• Cryptography and hashing. Many hashing algorithms (MD5, SHA-1, SHA-256) operate on the raw bytes of the input, regardless of how those bytes are displayed. The hex representation of a hash is just 32 (or 20, or 64) ASCII code points reading the bytes back out as text.
• Steganography and forensics. Messages hidden inside image files are often written as ASCII strings to make them copy-pasteable; seeing them as decimal code points makes the structure (32..126 printable range vs. binary noise) obvious.
• Teaching. Students learning about character sets hit ASCII first, then move on to Latin-1, then Unicode and UTF-8. The converter's per-character table makes every byte in any printable string explicit and clickable.

Common mistakes

• Confusing code point with byte. The code point for A is 65 in ASCII and in Unicode (specifically the Basic Latin block). In UTF-8, the dominant encoding on the web, code points 0..127 are still encoded as one byte, but code points 128 and above become 2, 3, or 4 bytes. A string of 10 non-ASCII code points can easily become 30 bytes on disk.
• Treating a control character as printable. 0 (NUL) and 10 (LF) are ASCII code points but they don't render as anything on a screen, pasting them into a "render the character" function gives you whitespace, not a glyph. The converter's per-character breakdown flags every control code point separately.
• Mixing 0x-prefixed and bare hex in a single round-trip. 0x41 and 41 are both valid for 65, but a sequence like 0x41 42 0x43 works only because 42 happens to also be valid as decimal; 0x41 4B 42 is ambiguous. Stick to one form per decode.
• Forgetting leading-zero padding. 0x05 and 0x5 are the same code point (5), but the byte representation is 05 and 5 respectively. If you're aligning output to a hex-dump style, pad to two hex digits (05) so columns line up.
• Confusing Latin-1 (extended) bytes with ASCII. Code points 128..255 are not ASCII. If you see an 0xFF byte and treat it as ASCII, you'll get the ÿ glyph at most, not the original character the file was written with. Use the per-character breakdown, where 128..255 are flagged "extended".

Worked numerical examples (with hand-verified arithmetic)

The seven pre-loaded Quick test cases are derived from the canonical ASCII table and checked manually:

1. A → 65 / 0x41 / 0b01000001. The uppercase letter A is the first code point in the alphabet, and it is the smallest example that flips all six high bits to the right state. Convert to hex by reading the bits two at a time from the right: 0001 (4) becomes the leading nibble, 0001 (1) the trailing; pad to 0x41. Convert to binary the same way, padded to 8 bits.
2. Hello → 72 101 108 108 111. Each letter of "Hello" maps to its standard decimal: H=72, e=101, l=108, l=108, o=111. The full sequence is the canonical documentation example for terminal emulators, network packets, and echo 'Hello' | xxd style diagnostic commands. Hex: 0x48 0x65 0x6C 0x6C 0x6F.
3. Space (32 / 0x20 / 0b00100000). Space is the lowest printable code point. In hexdump outputs space renders as a single character on its own line, and in telnet protocol trailers the space character separates <CR><LF> markers. Crucially, 0x20 is 32 in decimal, it is the boundary between control (0..31) and printable (32..126).
4. Tilde ~ → 126 / 0x7E / 0b01111110. Tilde is the highest printable code point in ASCII. Above 126 starts the "delete" code point (127) and above 127 the code points are out-of-ASCII. This is the same constant that anchors the "printable range" checks in many C ctype.h macros and in many assertion libraries.
5. \n → 10 / 0x0A / 0b00001010. The newline character, also called LF (Line Feed). In the converter's per-character table this is flagged "control" rather than "printable ASCII". It appears in source code as the two-character escape \n but in memory and on the wire it is one byte.
6. abc → 97 98 99. Lowercase letters sit 32 above their uppercase counterparts, a property of the ASCII table preserved through Unicode's Basic Latin block. So A = 65, a = 97, the difference is exactly 32. This is why the C standard library's tolower macro is c | 0x20 and toupper is c & 0xDF.
7. Round-trip 72 101 108 108 111 → "Hello". Pasting the decimal code stream from example 2 back into the Codes → Text tab yields the original "Hello". The reverse direction yields the same code stream back. This bidirectional round-trip is the strongest test that the converter is correctly handling the table.

Code point ranges at a glance

The ASCII standard partitions the 128 code points into named ranges that you can use as a quick mental filter:

All 95 printable code points are exactly the character set printers and terminals were designed to render, and the entire ASCII standard is what an 8-bit byte with the high bit cleared looks like. Code points 128..255 are outside ASCII and live in extended encodings like Latin-1 (ISO-8859-1) or Windows-1252; for full Unicode coverage (which extends to code points in the millions), the standard also defines UTF-8, UTF-16, and UTF-32 encodings that take more than one byte per code point.

Common queries (technical reference)

A few one-line lookups that come up often in code, debugging, and protocol work:

• Decimal of a digit: 48 + d for digit d (e.g. '7' → 55).
• Hex of a digit: 0x30 + d.
• Decimal of a letter, given its index i from 0: uppercase = 65 + i (so A=65, Z=90); lowercase = 97 + i (so a=97, z=122).
• Toggle case: uppercase letter c ↔ lowercase is c ^ 0x20, this works for every English letter in ASCII because the only difference is the 0x20 bit.
• Numeric value of a digit character: c - '0' (or equivalently c - 48).
• Convert an alphabet letter to its zero-based index: for uppercase c, c - 'A'; for lowercase c, c - 'a'. Both return 0 for A/a and 25 for Z/z.

Because these relations hold exactly across the entire ASCII table, entire generations of C, JavaScript, and shell tools use them as fast, branchless byte-flipping primitives. They are still the recommended way to convert digits and letters today; the rest of the standard (accents, CJK, emoji) lives in code points above 127.

ASCII vs Latin-1 vs Unicode (a 30-second reminder)

ASCII gives you 7-bit (128 code points). Latin-1 (ISO-8859-1) keeps the same 128 code points in the lower half and uses the upper 128 for the common accented letters of Western Europe (é, ñ, ü, ß, ø, ÿ). Windows-1252 is a superset of Latin-1 used historically by Microsoft Windows. Unicode extends the table to 1,114,112 code points organised into 17 planes of 65,536 each, encompassing every modern script plus many historical scripts, mathematical symbols, and emoji. UTF-8, UTF-16, and UTF-32 are encodings for the same Unicode code points, UTF-8 uses one byte for code points 0..127, two bytes for 128..2047, three bytes for 2048..65535, and four bytes above that. Because UTF-8 was designed to be a byte-for-byte superset of ASCII, every ASCII string is automatically a valid UTF-8 string and decodes to the same code points, which is the single most important reason ASCII has lasted this long.

Frequently Asked Questions

What does "ASCII" actually mean? American Standard Code for Information Interchange, a 7-bit character encoding standardising 128 code points (0..127). The first 32 plus 127 are control characters; the remaining 95 (codes 32..126) are printable. ASCII was published as ASA X3.4-1963 and revised through ANSI X3.4-1986; ISO/IEC 646 is the international standardisation.

Can this converter handle non-ASCII characters like é or 中? Yes, but those characters are Unicode code points, not ASCII. Code point U+00E9 (é) sits at decimal 233, well outside the ASCII 7-bit range (0..127). The converter processes it via JavaScript's String.codePointAt and String.fromCodePoint and classifies it as "extended" (128..255) or "Unicode" (≥ 256). For full multi-byte character work, pair this converter with a UTF-8 encoder, UTF-8 outputs 1, 2, 3, or 4 bytes per code point depending on the codepoint value.

How does this differ from the chars-to-bytes conversion in my programming language? Most languages treat strings as sequences of UTF-8 code units (JavaScript) or Unicode code points (Python 3, Rust). When you ask for Hello.getBytes() in Java or 'Hello'.encode() in Python 3, you get an array of five bytes, [72, 101, 108, 108, 111], which are the code points themselves for ASCII characters. Outside ASCII, the byte array diverges from the code-point array because UTF-8 expands higher code points.

Can I decode a hex-dump that has no separator? Not reliably. Run-on hex like 48656C6C6F is ambiguous without length cues, is 48 65 6C 6C 6F (Hello) or 4 86 56 C6 C6 F (and C6 is not in ASCII anyway)? Always paste a separator (space, comma, tab, newline) between tokens. The converter accepts spaces, tabs, newlines, and commas as inter-token separators.

What is the highest printable ASCII code? Code point 126, the tilde ~. Code 127 is DEL (a control character), and from 128 onward you leave ASCII entirely, those values are inherited from Latin-1 / extended ASCII but were never part of the original standard.

can the Text To Ascii be used for professional or commercial purposes? yes, the Text To Ascii provides mathematically correct results that are suitable for professional, commercial, and educational use. For the Text To Ascii, For the Text To Ascii, For high-stakes applications (medical, legal, financial), verify results with a domain expert. For the Text To Ascii, the Text To Ascii formulas used are well-established and validated against reference standards.

For the Text To Ascii, How often are the underlying formulas updated? For the Text To Ascii, the Text To Ascii formulas are based on established scientific, mathematical, or industry-standard references and rarely require updates. When standards change (e.g., new physical constants, revised tax brackets, updated standards), the Text To Ascii is updated to reflect the current authoritative source. For the Text To Ascii, For the Text To Ascii, Each calculator's references section lists the specific sources used.

References

• ASA X3.4-1977, American National Standard Code for Information Interchange (ASCII).
• ANSI X3.4-1986, Coded Character Sets, 7-Bit American National Standard Code for Information Interchange.
• ISO/IEC 646:1991, Information technology, ISO 7-bit coded character set for information interchange.
• RFC 20 (1969), ASCII format for network interchange, IETF.
• IETF STD 3, RFC 2119, RFC 7230 (HTTP/1.1), all cite RFC 20 as the printable character set.
• Unicode Standard, Chapter 2, General Structure (covers relationship between ASCII and Unicode).
• Wikipedia, ASCII, historical timeline and variant-table summary.
• Kernighan, B. W., & Ritchie, D. M. (1988). The C Programming Language, 2nd ed., §2.7, code-point example: each ASCII character maps to its byte value.