| # | Character | Decimal | Hex | Octal | Binary | UTF-8 | Name | Block |
|---|---|---|---|---|---|---|---|---|
| No characters yet β type something above. | ||||||||
Paste or type your text into the input box. Every character is analyzed instantly and entirely in your browser as you type.
Choose a numeric base (decimal, hex, octal, or binary), a separator, and whether codes should be zero-padded, to control how the flat code output is formatted.
Read the per-character table below the output β it lists each character's position, every base, UTF-8 bytes, UTF-16 code units, HTML entity, name, block, and category in its own column.
Switch to the reverse tab to paste codes back into text. Mixed notations like 0x41, U+0041, and A are all accepted in the same input, separated by spaces, commas, or semicolons.
One paste produces decimal, hexadecimal, octal, and binary for every character simultaneously, so you never re-run the same text through four separate tools. Switch the output base and the flat code string updates instantly.
The tool iterates your text by Unicode code point, not by UTF-16 unit, so an emoji or other character outside the basic plane is reported as a single character. Its UTF-16 surrogate pair is shown separately in its own column, not mistaken for two unrelated characters.
Each row shows the exact UTF-8 byte sequence for that character, in hex. It is the column that explains why a two-byte letter like Γ± silently breaks a fixed-width byte field or a byte-counted string limit that assumed one character equals one byte.
Line feed, carriage return, NUL, and the non-breaking space are named explicitly β LF, CR, NUL, NBSP β instead of rendering as an empty or invisible table cell. Invisible formatting differences in pasted text stop being a mystery.
The reverse direction tolerates mixed separators and mixed notations in a single paste β 0x41, 0o101, 0b1000001, U+0041, and A all decode correctly, with the trailing semicolon on an HTML entity optional. Malformed tokens are reported individually by position while the valid ones still decode.
Your text is analyzed and converted entirely on your device using native JavaScript string iteration. Nothing is uploaded, no account is required, and no server ever sees what you paste β verify it yourself by watching your browser's network tab while you type.
"What is the ASCII code of Γ©?" has no single correct answer β Γ© is not in ASCII at all, and its numeric value depends entirely on which encoding you mean. This tool shows the Unicode code point, the UTF-8 bytes, and the UTF-16 units side by side, so you get the real answer instead of a number that is wrong for your context.
Every row carries position, decimal, hex, octal, binary, UTF-8 bytes, UTF-16 units, name, block, and category β the full set of facts you need when a byte count is off by one or a character is silently corrupting a fixed-width field. It is built to answer "why," not just to look impressive.
The bundled character-name table covers ASCII, the C0 and C1 control ranges, Latin-1 Supplement, and Latin Extended-A β a deliberate, documented limit, not an oversight. Outside that range you still get the Unicode block and general category, computed live from JavaScript's own Unicode property escapes, and the name column shows an em dash rather than a guess.
Every character your computer displays is, underneath, a number. A "character code" is the mapping between that number and the glyph, control action, or symbol it represents. The hard part was never assigning numbers β it was agreeing, across every machine and network, on exactly which number meant which character. That agreement is what an encoding standard provides, and it is also what breaks when two systems disagree.
The American Standard Code for Information Interchange was formalized for network use in RFC 20 in 1969. ASCII assigns exactly 128 values, 0 through 127, fitting in seven bits. The first 32 (0β31) plus position 127 are control characters β line feed, carriage return, tab, and others that manage devices rather than print glyphs. The rest cover the English alphabet in both cases, the digits, and common punctuation β enough for American computing at the time, but no accented letters, no currency signs beyond the dollar, and no non-Latin scripts.
Once computers needed accented letters, Cyrillic, or other scripts, vendors used the eighth bit ASCII left unused, doubling the range to 256 values and filling 128β255 with whatever their market needed. Latin-1 (ISO 8859-1) put Western European accented letters there; other code pages put Cyrillic, Greek, or Hebrew in the same slots instead. The number 233 might be Γ© on one machine and something else on another, and a file saved under one code page could open as garbled text under another β the same bytes, two different meanings, with no way to tell which was intended.
Unicode separated two questions code pages had conflated: which abstract character is this, and how is it stored as bytes. It assigns every character a single, fixed code point β a number from U+0000 to U+10FFFF, written with the U+ prefix β regardless of how it is eventually stored. The Unicode Character Database catalogs every assigned code point with its name, general category, and other properties. Storage is then handled by a separate, chosen encoding: the same code point can be serialized as UTF-8, UTF-16, or UTF-32, each producing a different byte sequence for the identical character.
UTF-8, defined in RFC 3629, is the encoding that won the web. It represents each code point as one to four bytes: the original 128 ASCII characters stay one byte each, which is what makes UTF-8 backward-compatible with ASCII files. A code point above U+007F needs two, three, or four bytes β which is exactly why an accented letter like Γ± encodes as two bytes (0xC3 0xB1) in UTF-8, even though it is one character and one code point. JavaScript strings are UTF-16 internally, so code-point-aware iteration matters: a character outside the Basic Multilingual Plane, such as most emoji, is stored as a pair of 16-bit surrogate units but is still exactly one code point.
For the 128 original ASCII characters, the question has one clean answer. For anything else β Γ©, Γ±, δΈ, or an emoji β it does not, because that character was never in ASCII to begin with. What people usually mean is "what number represents this character," and the honest answer requires specifying an encoding: the Unicode code point (encoding-independent), the UTF-8 byte sequence, or the UTF-16 code units, all of which can differ. A tool that returns a single "ASCII code" for a non-ASCII character is answering a question you didn't ask; showing all three together is the only way to actually answer it.
No. Every conversion β text to codes and codes back to text β runs in your browser using native JavaScript string and Unicode APIs. Nothing is uploaded, there is no account, and no server call happens at any point. You can confirm this by watching your browser's network tab while you type.
Neither character is in ASCII, so there is no single ASCII code for them β ASCII only defines the 128 values 0β127. Both have a Unicode code point (Γ© is U+00E9, Γ± is U+00F1), and each encodes to a different byte sequence depending on the encoding: two UTF-8 bytes each, or one UTF-16 code unit each. This tool shows all of those side by side instead of forcing a single, misleading number.
This tool iterates your text by Unicode code point, so an emoji outside the Basic Multilingual Plane is correctly counted as one character, with its UTF-16 surrogate pair shown in a separate column. Tools and languages that iterate by UTF-16 code unit instead β including plain JavaScript string indexing β see the same emoji as two separate 'characters,' which is why string length and character counts can disagree between tools.
A code point is the abstract number Unicode assigns to a character, independent of storage β U+00F1 for Γ±, for example. A byte is a unit of actual storage or transmission. How many bytes a given code point takes depends entirely on the encoding: one byte in UTF-8 for ASCII characters, two bytes in UTF-8 for Γ±, or a fixed two bytes per UTF-16 code unit (sometimes two units) in UTF-16. The code point never changes; the byte representation does.
The bundled name table covers ASCII, the C0 and C1 control ranges, Latin-1 Supplement, and Latin Extended-A β a deliberately limited, documented range, not the full Unicode Character Database, which lists tens of thousands of names and would cost real download weight to ship. Outside that range the tool still reports the Unicode block and general category (computed live from JavaScript Unicode property escapes) and shows an em dash for the name rather than guessing.
Yes, using the reverse tab. It accepts decimal, hex, octal, and binary, plus the explicit notations 0x41, 0o101, 0b1000001, U+0041, A, and A, mixed freely in the same input and separated by whitespace, commas, or semicolons. Malformed tokens β not a valid number, above U+10FFFF, or a lone surrogate (U+D800βU+DFFF) β are reported individually by their position, and every other valid token still decodes.
Windows-style line endings use two control characters per line break: carriage return (CR, U+000D) followed by line feed (LF, U+000A). If your pasted text was saved or copied from a Windows source, you will see both listed as separate rows in the per-character table β that is not a bug in the tool, it is exactly what is in your text, made visible instead of hidden.
The per-character table is capped at 2,000 rows for readability and performance, with a visible notice telling you how many characters were not listed beyond that point. The flat code output β the decimal, hex, octal, or binary string β is never truncated and always reflects your full input, no matter how long.
The first 32 ASCII codes are not characters you type. Here is what LF, CR, TAB and NUL actually mean, why CRLF still exists, and how to find invisible ones.
Read more →
Mojibake has one common cause: UTF-8 bytes read as Latin-1. Here is how to recognise the pattern, trace it to the layer that broke, and confirm the fix.
Read more →
Past the basics of ASCII and UTF-8: how the standard was renamed, how the 17 Unicode planes are laid out, and why normalization breaks sorting and search.
Read more →