Text to Hexadecimal Converter

What hexadecimal is

Hexadecimal is base 16, using the digits 0 to 9 and then the letters A to F. One hex digit covers exactly four bits, so two hex digits describe one byte precisely and without waste. That clean fit is the whole reason it survives: a byte written as 3C is instantly readable as two four-bit halves, where the same value in binary (00111100) makes you count.

You meet it in memory addresses, CSS colours, MAC addresses, hash digests, and anywhere raw bytes need to be shown to a human.

ASCII

ASCII (American Standard Code for Information Interchange) was published in 1963 by the American Standards Association, in the United States. It assigns 128 characters to the numbers 0 to 127, which fits in seven bits. The spare eighth bit was originally used for parity checking.

The layout was designed rather than accumulated. Uppercase and lowercase are exactly 32 apart, which is a single bit, so changing case is one bitwise operation. The digits 0 to 9 sit at 0x30 to 0x39, so the low nibble is the digit itself.

UTF-8, which is what this page uses

UTF-8 encodes well over 98% of the web. It was designed by Ken Thompson and Rob Pike in 1992, and its cleverness is that it extends ASCII without breaking it:

So any pure-ASCII file is already valid UTF-8, which is why the transition happened at all.

This matters for what you see above. Type café and the output is 63 61 66 C3 A9: five bytes for four characters, because the é needs two. Type 中 and you get E4 B8 AD, three bytes for one character. Byte count and character count are different numbers, and the breakdown above shows both.

If you were expecting E9 for that é, you are thinking of Latin-1, an older single-byte encoding. It is not the same thing, and mixing the two is the origin of the mangled é you see on badly configured websites.

Reading hex back

Each pair of hex digits is one byte, and the bytes are decoded as UTF-8, so multi-byte sequences reassemble into the character they came from. 48 65 6C 6C 6F gives Hello. Bytes below 0x20, plus 0x7F, are control characters with no visible glyph, so they are marked rather than printed.

A malformed sequence, meaning one that is not valid UTF-8, decodes to the replacement character �. That is not a bug in the conversion; it is what every correct UTF-8 decoder does with bytes that cannot mean anything.