Ascii converter
What Is ASCII? The Character Code Behind Modern Text
ASCII (pronounced "ask-ee") stands for the American Standard Code for Information Interchange — the 1963 standard that assigned every basic English character a number from 0 to 127. An ASCII converter translates between characters and their numeric codes in both directions: type text to see the decimal, hex, and binary code for each character, or enter codes to decode them back into readable text.
ASCII was a landmark in computing history: before it, every manufacturer used incompatible character encodings, and moving text between machines was a translation project. ASCII's 128-code table — 33 control characters (0–31 plus 127), printable punctuation, digits, uppercase and lowercase letters — became the universal foundation. The design shows its teletype roots: digits 0–9 are codes 48–57, uppercase A–Z are 65–90, lowercase a–z are 97–122, and the control characters (like 10 for line feed, 13 for carriage return, 27 for escape) are the ghosts of mechanical teleprinters still haunting modern protocols.
Every modern text encoding builds on ASCII. UTF-8 — the dominant encoding of the web, used by over 98% of websites — is deliberately backward-compatible: the first 128 UTF-8 code values are byte-for-byte identical to ASCII. That means pure-English text is simultaneously valid ASCII and valid UTF-8, which is why ASCII knowledge transfers directly to debugging modern text. When you see "mojibake" (garbled text like é instead of é), you're seeing bytes interpreted in the wrong encoding — and ASCII is the baseline that makes the diagnosis possible.
Programmers meet ASCII codes constantly: key codes in event handlers, escape sequences in strings (\n is 10, \t is 9), URL percent-encoding (%41 is 'A'), HTTP headers, and protocol specs written in terms of code values. The converter makes these translations instant — no more counting to 65 on your fingers. Input is processed instantly and never stored. Companion encodings: our binary converter for base-2, hex converter for base-16, and Morse converter for the telegraph classic.
How to Use the ASCII Converter
- Choose the direction. Text → ASCII codes to encode, or ASCII codes → Text to decode.
- Enter your input. Type or paste any text for encoding; for decoding, enter decimal codes separated by spaces or commas (e.g., 72 101 108 108 111).
- Select the code format. View codes as decimal (the classic ASCII numbers), hexadecimal (programmer shorthand), or binary (the bit patterns) — or all three side by side.
- Convert. The tool maps each character to its code (or each code to its character) instantly, flagging any out-of-range values when decoding.
- Copy the result. Copy the code sequence for use in code, documentation, or protocol work — or the decoded text back into your document.
- Explore the full table. Browse the complete 0–127 chart below to build familiarity with the layout — it pays off every time you debug text.
The ASCII Table: Codes 0–127
| Dec | Hex | Char | Description | Dec | Hex | Char | Description |
|---|---|---|---|---|---|---|---|
| 0 | 00 | NUL | Null | 64 | 40 | @ | At sign |
| 9 | 09 | TAB | Horizontal tab | 65 | 41 | A | Uppercase A |
| 10 | 0A | LF | Line feed (\n) | 90 | 5A | Z | Uppercase Z |
| 13 | 0D | CR | Carriage return (\r) | 97 | 61 | a | Lowercase a |
| 27 | 1B | ESC | Escape | 122 | 7A | z | Lowercase z |
| 32 | 20 | space | Space | 48 | 30 | 0 | Digit 0 |
| 33 | 21 | ! | Exclamation | 57 | 39 | 9 | Digit 9 |
| 127 | 7F | DEL | Delete | 65–90 | 41–5A | A–Z | Uppercase letters |
The table's structure is worth memorizing in broad strokes rather than individual codes: 0–31 are control characters (invisible, but structurally vital — newlines, tabs, escapes); 32–47 are space and punctuation; 48–57 are the digits; 58–64 more punctuation; 65–90 uppercase; 91–96 punctuation including brackets; 97–122 lowercase; 123–126 final punctuation; 127 DEL. Notice the elegant arithmetic: lowercase is uppercase + 32 (A=65, a=97), and digits are contiguous starting at 48 — which is why converting a digit character to its value is just `code - 48` in every programming language, and why case-flipping is a single bit operation (bit 5, value 32).
Key Features
| Feature | What It Does | Why It Matters |
|---|---|---|
| Text → codes | Shows decimal, hex, and binary per character | Instant lookup without consulting a chart |
| Codes → text | Decodes space/comma-separated values | Read numeric dumps as text |
| Control-char names | Displays NUL, LF, CR, TAB, ESC symbolically | Invisible characters made visible |
| Multi-format output | Decimal, hex, and binary side by side | One conversion serves every context |
| Range validation | Flags values outside 0–127 when decoding | Catches typos and encoding confusion |
| Extended code info | Notes on 128–255 (extended/latin-1) | Clarifies the ASCII vs. extended boundary |
ASCII vs. Extended ASCII vs. Unicode: The Boundaries
Three related terms cause endless confusion, so let's draw the lines precisely. ASCII is codes 0–127, period — standardized, universal, unambiguous. "Extended ASCII" is not one standard but a family of 8-bit extensions using codes 128–255 differently: Latin-1 (ISO-8859-1) for Western European languages, Windows-1252 (a Latin-1 superset that's the de facto standard on legacy Windows), DOS code pages, and others. The same byte value means different characters in different extensions — byte 0xE9 is é in Latin-1 but something else in another code page — which was the great text-mangling engine of the 1990s.
Unicode solved this by assigning every character in every writing system a unique code point (U+0041 = 'A', U+1F600 = 😀), and UTF-8 is its dominant byte encoding — designed so the first 128 code points encode as single bytes identical to ASCII. This backward compatibility is why ASCII never died: it became the header of the Unicode universe. When the converter flags a decode value above 127, it's telling you you've left ASCII proper and entered extension/Unicode territory, where the byte's meaning depends on the encoding — exactly the distinction that prevents mojibake.
Practical rule of thumb: if your text is English-only, ASCII thinking is sufficient and everything "just works." The moment you handle other languages, emoji, or curly quotes, think in UTF-8 and code points instead of ASCII codes — and reach for Unicode-aware tools rather than forcing an ASCII frame onto non-ASCII data.
ASCII in the Wild: Where the Codes Surface Daily
Once you know the table, you start seeing it everywhere. Keyboard events in programming: checking `keyCode` or `key` values is ASCII arithmetic (is it between 65 and 90? it's an uppercase letter). Escape sequences in strings — \n (10), \t (9), \r (13), \0 (0) — are ASCII codes in disguise, and understanding them explains why Windows line endings (\r\n, 13+10) differ from Unix (\n, 10): a teletype needed both a carriage return and a line feed as separate mechanical actions, and the convention fossilized.
URL percent-encoding is hex ASCII: %41 = 65 = 'A', %20 = 32 = space. HTTP is an ASCII-based protocol — headers, methods, and status lines are all ASCII text, which is why non-ASCII content needs encoding schemes. Base64 maps binary data onto 64 ASCII characters specifically so it survives ASCII-only channels like email. Checksums and hashes display as hex ASCII. Even file formats announce themselves in ASCII magic numbers (89 50 4E 47 = ‰PNG, where 50 4E 47 is literally "PNG"). The converter is the Rosetta Stone for all of these: paste the codes, read the text, and the abstraction becomes concrete.
Use Cases
For developers: "The problem:" debugging text at the byte level
The problem: A string comparison fails even though the strings "look identical" — there's an invisible character hiding in one of them (a non-breaking space, a zero-width joiner, a stray carriage return), or a protocol expects exact byte values and yours are off.
How this tool helps: Paste the suspect text into text→codes mode and every character's code is exposed — the invisible becomes visible. A 160 where you expected 32 (non-breaking vs. regular space) or a 13 lurking before your 10 (Windows line ending in Unix-expected input) jumps out immediately. It's the fastest path from "impossible bug" to "oh, of course."
For students: "The problem:" learning character encoding fundamentals
The problem: Your course covers ASCII, and the table feels like 128 arbitrary facts to memorize before the exam.
How this tool helps: Don't memorize — internalize the structure: digits at 48, uppercase at 65, lowercase at 97, each group contiguous; lowercase = uppercase + 32. Encode your name, decode 72 105, play with the converter until the ranges feel natural. Exams test the patterns (what's 'a'+1? what's the code 32 below 'A'?) far more than random codes, and the patterns are genuinely simple once seen.
For CTF and puzzle players: "The problem:" a string of numbers that might be ASCII
The problem: The challenge gives you 72 101 108 108 111 44 32 87 111 114 108 100 33 and you suspect decimal ASCII — but manual lookup of thirteen codes is slow.
How this tool helps: Paste into codes→text mode and get "Hello, World!" instantly. Try decimal first, then hex, then binary groupings — CTF challenges cycle through these representations, and quick checks beat deliberation. Keep our binary converter and hex converter alongside for the full rotation.
For embedded and hardware hackers: "The problem:" serial protocols speaking in codes
The problem: Your microcontroller's serial monitor shows numeric codes, or the device datasheet specifies commands as byte values (send 0x1B 0x5B 0x32 0x4A to clear the screen — that's an ANSI escape sequence).
How this tool helps: Translate between the numeric command bytes and their ASCII meaning instantly — 0x1B is ESC, and suddenly the "magic sequence" reads as the escape-based terminal command it is. Understanding ASCII control codes turns datasheet hex dumps from opaque to legible.
For writers and editors: "The problem:" invisible characters corrupting a manuscript
The problem: Text pasted from the web, PDFs, or word processors carries invisible passengers — non-breaking spaces, soft hyphens, smart quotes in the wrong encoding — that break formatting, search, and ebook conversion.
How this tool helps: Run suspicious passages through text→codes mode to identify the intruders by their code values, then search-and-replace them with the correct characters. It's forensic editing: tedious to describe, deeply satisfying to fix, and the only reliable method when the characters are literally invisible.
Typing the Untypeable: Alt Codes and Character Input
ASCII knowledge has one more practical outlet: typing characters your keyboard doesn't show. On Windows, holding Alt and typing a decimal code on the numeric keypad inserts the character — Alt+65 gives 'A', Alt+169 gives '©' (in the Windows-1252 interpretation), Alt+0153 gives '™'. On macOS, Option combinations serve a similar role, and Linux offers Ctrl+Shift+U followed by a hex code point for full Unicode input. These aren't party tricks: they're how you type ©, ®, °, ±, and en/em dashes in environments without a character picker.
The same principle powers HTML entities: A renders as 'A' (decimal reference), A as 'A' (hex reference) — numeric character references are literally ASCII/Unicode codes embedded in markup. When a CMS mangles a special character, replacing it with its numeric reference is the bulletproof fix, because the reference survives every encoding transition intact. And in programming, escape sequences (\x41 in many languages = hex 41 = 'A', \u0041 = Unicode code point) are the code-form of the same idea. The converter sits at the center of all of these: whatever numeric form a context demands, translate once here and paste with confidence.
ASCII Art and the Creative Afterlife of a 1963 Standard
A standard designed for teletypes became an art medium. ASCII art — images composed of text characters, from simple smileys :-) to elaborate multi-line scenes — flourished in the era of text-only terminals and early internet, where images were impossible and creativity routed around the constraint. The craft is genuine: artists exploit characters' visual density (# is dark, . is light) to shade images, exactly as halftone printing does with dots.
ASCII art survives in surprising niches: code comments (project banners and section dividers), terminal startup messages, README files, email signatures, and esoteric programming culture. There are even converters that render images as ASCII art by mapping pixel brightness to character density — the same principle, automated. It's a reminder that constraints breed creativity, and that a 128-character code table from 1963 still has cultural momentum sixty years later. Try encoding a small piece of ASCII art with this converter's text→codes mode: watching a picture dissolve into numbers and back is a neat demonstration of the text/image duality that underlies all digital media.
Frequently Asked Questions
What does ASCII stand for?
American Standard Code for Information Interchange. It was published in 1963 (as ASA X3.4) and standardized the 128-code character set — 33 control codes plus 95 printable characters — that became the foundation of digital text.
How many characters are in ASCII?
128 total: codes 0–127. Of these, 95 are printable (space through ~, codes 32–126), 33 are control characters (codes 0–31 plus 127), and the split reflects ASCII's teletype origins — the controls operated the machinery, the printables put marks on paper.
What's the ASCII code for 'A'? For 'a'? For '0'?
'A' is 65, 'a' is 97, '0' is 48. The three anchor points worth memorizing: uppercase starts at 65, lowercase at 97 (exactly 32 higher), digits at 48. Everything else in the printable range follows contiguously from these.
Is ASCII the same as UTF-8?
Not the same, but compatible by design: UTF-8 encodes the first 128 Unicode code points as single bytes identical to ASCII. Pure-ASCII text is valid UTF-8 and vice versa. UTF-8 extends far beyond ASCII (over a million possible code points) using multi-byte sequences for everything else.
What are ASCII control characters used for today?
Several remain load-bearing: 9 (tab), 10 (line feed, \n), 13 (carriage return, \r), and 27 (escape, starting terminal control sequences). Others (like 7, the BEL that rang the teletype's bell — still beeps terminals today) survive as curiosities. Most of the 0–31 range is legacy, but the survivors are everywhere.
Why do uppercase and lowercase differ by exactly 32?
By design — and it's no coincidence that 32 is a power of two (2⁵). Flipping bit 5 converts case, which let early hardware implement case conversion (and case-insensitive comparison) with a single AND/OR operation. It's a beautiful example of encoding design serving the machinery.
What is extended ASCII?
Codes 128–255, which standard ASCII leaves undefined. Various incompatible standards filled this range — Latin-1, Windows-1252, DOS code pages — so "extended ASCII" isn't one encoding but many, and the same byte renders differently under each. This ambiguity is exactly what Unicode was created to eliminate.
How do I convert ASCII codes back to text?
Enter the decimal codes separated by spaces or commas into codes→text mode (e.g., 72 105 → "Hi"). The converter validates the range and renders control characters by their symbolic names (LF, TAB) so invisible codes don't silently vanish.
Why does garbled text (mojibake) happen?
Bytes get decoded with the wrong encoding — e.g., UTF-8 bytes read as Windows-1252, turning é into é. ASCII-only text is immune (it's identical in most encodings), which is why mojibake always strikes non-English text first. The fix is decoding with the correct encoding, not retyping.
Is my input stored when I use this tool?
No. Conversions happen instantly and nothing is stored on the server.