What does the ASCII to Hex Converter do?
Text to hex, character by character. It takes your text and gives back the hexadecimal bytes that spell it. Type Hello and you get 48 65 6C 6C 6F — five characters, five bytes, one line. There's no Convert button; the hex updates as you type, and underneath the answer you get the part most pages leave out: a row per character showing exactly which bytes that character produced and what its Unicode code point is.
Four things are yours to choose. The encoding (UTF-8, Latin-1, UTF-16 big-endian or UTF-16 little-endian), the output shape (six of them, from bare 48 65 to \x48\x65), the letter case of the digits A–F, and an optional line width for a hexdump-style wrap. Input goes up to 8,192 characters. Newlines and tabs survive the trip and come out as 0A and 09 rather than being stripped, because in a hex dump whitespace is data.
All of it runs in your browser. Nothing is uploaded, there's no account, and there's no cap on how many times you use it — which matters, because what people convert to hex is often a password, an API key or a packet capture they shouldn't be emailing anywhere.
How text becomes hex
Every character has a number. Hex is just that number written in base 16, using the digits 0–9 and then A–F for 10 through 15. Capital H is 72 in decimal. 72 is four sixteens with 8 left over, so it's 48. Lowercase e is 101, which is six sixteens with 5 left over, so 65. Do that across Hello and you have 48 65 6C 6C 6F.
Two rules make hand-checking fast. First, every byte is exactly two hex digits — a tab is 09, never 9. Second, the ASCII table has landmarks worth memorising, and once you know them you can read most hex at a glance.
| Character | Decimal | Hex | Worth knowing |
|---|---|---|---|
| space | 32 | 20 | The most common byte in English text |
! | 33 | 21 | Punctuation starts right after the space |
0 | 48 | 30 | Digits run 30–39, so the character 7 is 37, not 07 |
9 | 57 | 39 | Add the digit to 30 and you're done |
? | 63 | 3F | The last byte before the capitals |
A | 65 | 41 | Capitals run 41–5A |
Z | 90 | 5A | 26 letters, 41 through 5A |
a | 97 | 61 | Lowercase is always its capital plus 20 |
z | 122 | 7A | Lowercase runs 61–7A |
~ | 126 | 7E | The last printable ASCII character |
| tab | 9 | 09 | A control character, and still real data |
| newline | 10 | 0A | 0D 0A on Windows — two bytes, not one |
That plus-20 rule between cases is the single most useful thing on the list. If you see 48 65 6C 6C 6F and 68 65 6C 6C 6F in the same log file, the only difference is a capital H, and you can tell without looking anything up.
A worked example, character by character
Here is Hello in UTF-8, exactly as the working table on this page shows it.
| Character | Bytes | Code point |
|---|---|---|
H | 48 | U+0048 |
e | 65 | U+0065 |
l | 6C | U+006C |
l | 6C | U+006C |
o | 6F | U+006F |
Read the Bytes column straight down and you have the output. The ASCII to Hex Converter also puts the whole thing in one copyable line: "Hello" in UTF-8 = 48 65 6C 6C 6F (5 bytes).
Longer inputs work the same way. Hello, World! is 13 characters and 13 bytes — 48 65 6C 6C 6F 2C 20 57 6F 72 6C 64 21, where 2C is the comma, 20 the space and 21 the exclamation mark. Put a line break in the middle instead and Hello + newline + World gives 48 65 6C 6C 6F 0A 57 6F 72 6C 64: 11 bytes, with the 0A sitting in the output as a byte rather than vanishing as formatting. That single difference is why a string that looks identical in two files can fail a checksum.
Set bytes per line to 16 and the output takes the layout hexdump and xxd use, so you can scan a column and compare the same offset across rows. Use 8 on a phone. Leave it blank and everything stays on one line — what you want for a hash or a string escape.
Why you can get more bytes than characters
Because ASCII stops at 127. It's a 128-character set from 1963: English letters, digits, common punctuation, control characters. No curly quotes, no em dash, no accented letters, no emoji. Each of those 128 is one byte that all four encodings agree on. Above 127 they stop agreeing, and there is no longer any such thing as the hex for a character.
Take the word café — four characters, one of them accented.
| Encoding | Hex for café | Bytes | Use it when |
|---|---|---|---|
| UTF-8 | 63 61 66 C3 A9 | 5 | The default. The web, JSON, anything written this century. |
| Latin-1 | 63 61 66 E9 | 4 | Older Western-European software that wants one byte per character. |
| UTF-16 LE | 63 00 61 00 66 00 E9 00 | 8 | Windows APIs and .NET. |
| UTF-16 BE | 00 63 00 61 00 66 00 E9 | 8 | Java and most network protocols. |
All four are correct. They're answers to different questions. The é is C3 A9 in UTF-8 and E9 in Latin-1, and picking between them is a fact about where the bytes are going, not a matter of taste. UTF-8 spends two bytes on most European accents, Greek and Cyrillic, three on CJK and most symbols, and four on emoji — 😀 is one character and F0 9F 98 80. The curly apostrophe is the sneakiest of the lot: don't typed with a smart quote is five characters and seven bytes, 64 6F 6E E2 80 99 74, because U+2019 costs three bytes on its own.
When your text is entirely below 127, the encoding picker changes nothing except that UTF-16 doubles everything with 00 bytes: Hello is 48 65 6C 6C 6F in UTF-8 and Latin-1 alike, and ten bytes rather than five in UTF-16. The result card counts how many of your characters were above 127, so you always know whether the choice mattered.
Six ways to write the same bytes
Hex has conventions, and they're regional in the way driving on the left is regional. The bytes never change; only the punctuation around them does.
| Shape | OK looks like | Where it's the convention |
|---|---|---|
| Spaced | 4F 4B | Hex dumps, documentation, anything read by a person |
| Plain | 4F4B | Hashes, checksums, database blob literals |
0x prefixed | 0x4F 0x4B | C, Go and Rust byte arrays |
\x escaped | \x4F\x4B | String literals in C, Python, JavaScript, shell printf |
| Colon separated | 4F:4B | MAC addresses, TLS fingerprints, openssl output |
| Comma separated | 4F, 4B | Array initialisers and byte lists |
The \x shape has no separators for a reason: \x4F\x4B is a two-character string, not a list of two things. Case is cosmetic in the same way: RFCs, hex dumps and MAC addresses lean uppercase, git object ids and CSS colours lean lowercase, and every hex parser accepts both. Match whatever the codebase you're pasting into already does — and if two hex strings look different, check the case before assuming the bytes differ. That's a common false alarm.
Where hex conversions go wrong
Four failures account for most of them, and none is really about hex.
The text wasn't ASCII and nobody said so. Copy anything out of a word processor, a web page or a chat app and there's a good chance one character is above 127 — a smart apostrophe, usually. It converts fine; it's just that the honest name for the answer is now "UTF-8 hex" rather than "ASCII hex". The ASCII to Hex Converter names the count instead of quietly pretending the distinction doesn't exist.
The character doesn't exist in the encoding you picked. Latin-1 has 256 bytes and none of them is the euro sign. Asking for € in Latin-1 is a question with no answer, so you get told exactly that — named character, code point, and a pointer at UTF-8 — rather than a silent ? substituted where your data used to be. A confidently wrong byte is worse than an error.
Digits got treated as numbers. The character 7 is the byte 37. The number 7 is the byte 07. Both are legitimate, and mixing them up is the single most common reason a hand-built packet or a fixture file doesn't parse. If you want the numeric conversion rather than the character one, that's the hex to decimal converter — a different question with a different answer.
Line endings got counted as formatting. A Windows newline is 0D 0A, two bytes. A Unix one is 0A, one byte. Text editors hide the difference and byte counts don't.
The fastest way to check any result: paste the hex into the hex to text converter and see whether your text comes back. It's a real check, not a formality — the two pages were written separately, and the round trip only succeeds if both agree about the encoding, the byte order and the separators. All six output shapes read back identically, so it works whichever one you picked.
One more thing worth saying plainly, because the category is full of it. A hex converter has no business being a signup flow. Plenty of them are anyway: the same three lines of arithmetic buried four clicks deep inside a developer platform billed per seat, or a page that converts your first 200 characters and then asks for a card to see the rest, or a "free" encoder that uploads your input to a server it doesn't need. This page is the ASCII to Hex Converter and nothing else. It's paid for by ads and by members who pay one flat annual fee to switch them off, 10% of every dollar Microapp earns goes to charity off the top, and none of that changes the tool in front of you. Confirm the no-upload part yourself: open your browser's network tab and type into the box. Nothing fires — which is also why the page keeps working offline once it has loaded.
Related hex and encoding tools
Hex is one of several ways to look at the same bytes. For the return trip, the hex to text converter reads every shape this page writes. To see those bytes as bits instead, the text to binary converter gives you 01001000 where this one gives 48, and the binary decoder takes them back to text. If you're holding a hex string and want its numeric value rather than its characters, that's hex to decimal, and hex to binary for the bit pattern.
For encoding work more broadly, the Base64 encoder and decoder is the shape you'll meet in email attachments, data URLs and JSON payloads, and the text to Unicode converter gives the U+ code points behind the characters rather than the bytes in front of them. All of them run locally in your browser, the same as the ASCII to Hex Converter.
Frequently asked questions
How do I convert ASCII to hex by hand?
Look each character up to get its number, then write that number in base 16. Capital H is 72, which is four sixteens with 8 left over, so 48. Lowercase e is 101, six sixteens with 5 over, so 65. Across Hello that's 48 65 6C 6C 6F. Shortcuts: capitals run 41–5A, lowercase 61–7A (always the capital plus 20), digits are 30 plus the digit. Every byte is two hex digits, so anything under 10 keeps its leading zero.
Why does my text convert to more bytes than it has characters?
At least one character is above code point 127. UTF-8 uses one byte for ASCII, two for most European accents and Greek and Cyrillic, three for CJK and most symbols, and four for emoji. So a nine-character word with one accent is ten bytes, and a single emoji is four. The result card counts your above-127 characters and the working table shows you which ones they were — that count is often the answer to why a length check failed somewhere else.
Which encoding should I pick?
UTF-8 unless you know otherwise. It's a superset of ASCII, so for plain English text it gives exactly the bytes an ASCII table would. Pick Latin-1 for older Western-European software that expects one byte per character — it writes é as E9 rather than C3 A9, and refuses anything it can't represent instead of substituting a question mark. Pick UTF-16 LE for Windows and .NET, UTF-16 BE for Java and network protocols.
What's the difference between 0x48, \x48 and plain 48?
Nothing, as bytes. Bare 48 is documentation and hex-dump style. 0x48 is a numeric literal in C, Go, Rust, Python and JavaScript, so it's what belongs inside a byte array in source code. \x48 is a character escape inside a string literal in those same languages plus shell printf, which is why it carries no separators. A colon between bytes is the MAC-address and TLS-fingerprint convention. Pick whichever matches where you're pasting.
Should hex be uppercase or lowercase?
Either — it's house style, not correctness. Uppercase is usual in RFCs, hex dumps and MAC addresses; lowercase in git object ids, SHA and MD5 output, CSS colours and most command-line output. The bytes are identical and every parser takes both. Hello is 48 65 6C 6C 6F or 48 65 6c 6c 6f, same five bytes.
Is there a limit on how much text I can convert?
8,192 characters, roughly 8 KB of English. That's a page limit rather than a correctness one — the conversion is a per-character walk and stays exact at any length, but past 8,192 the working table runs to thousands of rows and your browser spends longer laying it out than you'd spend reading it. For anything bigger, convert it in sections.
Is anything I paste here sent anywhere?
No. The conversion is a few lines of arithmetic running in your browser, so your text never leaves the page — there's no request that sends it and nothing on our side to store it in. That's a design choice rather than a promise you have to take on trust: a hex converter has no reason to need a server. Open your network tab and type into the box if you'd like to see for yourself.