How do I see the ASCII code of each character in my text?
Paste the text into this converter and click Convert. It lists one decimal number per character, separated by spaces, so Hi! becomes 72 105 33. Numbers up to 127 are standard ASCII. Anything larger is a Unicode character from outside ASCII, which makes the tool a quick way to expose characters you can't see on screen.
Hidden characters this exposes
Two strings can look identical and still fail to match, because one contains a character that renders as nothing, or as a near-twin of an ASCII character. Converting both to codes settles it. These are the ones that cause most trouble:
| Looks like | Code | What it actually is |
|---|---|---|
| a space | 160 | No-break space (U+00A0), common in text copied from web pages and Word |
| nothing | 8203 | Zero-width space (U+200B) |
| nothing | 65279 | Byte order mark / zero-width no-break space (U+FEFF), often at the start of a pasted file |
' |
8217 | Right single quotation mark (U+2019), the "smart" apostrophe |
" |
8220, 8221 | Left and right double quotation marks |
- |
8211, 8212 | En dash and em dash |
| a gap | 9 | Tab, which many editors display as spaces |
Real example: it’s typed on a phone converts to 105 116 8217 115. The plain ASCII version, it's, would contain 39 in third place. That one number is why a search, a password comparison or a WHERE name = ... query can quietly fail.
A zero-width space is even harder to spot. x, then U+200B, then y displays as xy but converts to 120 8203 121, three characters where you expected two.
A debugging routine
- Copy the exact value that misbehaves, straight from the source (the database cell, the form field, the CSV), not a retyped version.
- Paste it here and click Convert.
- Scan the numbers for anything over 127. Each one is a non-ASCII character, and its position in the list tells you which character it is.
- Scan for anything under 32 other than 9 and 10. Those are control codes that rarely belong in user data.
- Look up an unfamiliar number in the Unicode code charts by converting it to hex first (8203 is 200B), or compare it against the ASCII table if it's under 128.
- Fix the source with a find and replace, then convert again to confirm the stray code has gone.
Same letter, two different encodings
Accented letters can be stored in two ways, and this tool shows which one you have. A precomposed é is a single character, code 233. The decomposed form is a plain e (101) followed by a combining acute accent (769, U+0301), so it converts to 101 769. Both render identically, but they compare as different strings unless your code normalises them first. The rules for that are in Unicode Standard Annex #15, which defines the NFC and NFD forms. Text from macOS file names and some keyboards tends to arrive decomposed.
Notes on how the output is built
- Every character counts, including spaces (32), tabs (9) and line breaks (10). Nothing is skipped or trimmed.
- An emoji gives one number, not two.
👍is128077, its full code point. JavaScript's oldercharCodeAtwould report it as two UTF-16 halves; this tool reads whole characters. - Line breaks come out as 10 every time. Browsers normalise text-box line endings to a single line feed, so you can't use this page to detect Windows CR LF line endings in a file.
- The numbers are code points, not bytes. For byte-level checks, such as how many bytes a value takes in a UTF-8 column, use text to hex, which prints the actual UTF-8 bytes.
Turning codes back into text
Once you've identified the culprit, you can rebuild a clean string from codes with ASCII to text: type the numbers you want, separated by spaces, and convert. That's also handy for producing a test string that deliberately contains a no-break space or a zero-width character, so you can check your own code handles it.
Last updated