The Unicode to UTF Converter is a free, browser-based tool that turns readable text into the raw UTF-8, UTF-16 or UTF-32 byte values that computers actually store. Type or paste your text, pick an encoding, and the tool immediately prints each byte as binary, octal, decimal, hexadecimal or any base from 2 to 36. It shows exactly what happens under the hood when a file, database or network message saves your words.

It is useful whenever you need to inspect or reproduce byte-level data: debugging a mojibake problem, checking how many bytes an emoji really costs, writing a serialization routine, documenting an API payload, or proving that two strings that look identical are stored differently. Because every script on Earth is covered, you can test accented Latin, Cyrillic, Arabic, CJK and emoji in the same run.

The page is written in plain HTML, CSS and JavaScript, and the encoders are implemented directly from the Unicode Standard, so there is no server, no upload and no third-party library. UTF-8, UTF-16 (including surrogate pairs and byte order) and UTF-32 are all calculated inside your browser, so your text never leaves your device.

Unicode assigns every character a number called a code point, written like U+0041 for the letter A. A Unicode Transformation Format (UTF) is simply a rule for turning those numbers into bytes. The number in the name describes the size of the code unit it works with, not a fixed character size.

UTF-8 uses 8-bit units and is the dominant encoding on the web. A code point below 128 becomes one byte; larger code points become two, three or four bytes. Because plain ASCII text stays one byte per character, UTF-8 is compact for English and still supports every symbol. This is why Café is four characters but five UTF-8 bytes.

UTF-16 uses 16-bit units. Most common characters fit in one unit, and characters above U+FFFF (many emoji and rare scripts) are stored as a surrogate pair of two units, which is four bytes. UTF-16 also has a byte order, so big-endian and little-endian versions differ, and a byte order mark (BOM) is often used to signal which one is in play.

UTF-32 uses 32-bit units, so every code point takes exactly four bytes. It is simple and fixed-width, which makes random access easy, but it uses far more space than UTF-8 and is rarely chosen for storage or transfer.

The tool walks your input one code point at a time, applies the UTF rule you selected, and then writes each resulting 8-bit byte in the numeral base you chose. Spaces, punctuation, letters, digits, symbols and emoji are all handled; accented characters and emoji are never split into the wrong number of pieces, even when they are made of surrogate pairs.

Every option is a small, independent switch. You can, for example, output UTF-16 big-endian bytes in hexadecimal with a BOM for a Windows API, or the same text as UTF-8 binary without padding for a teaching slide. The Load an example link and the buttons in the Examples section preset the encoding and options for you, and the statistics line reports the character, code point and byte counts for the current setting.

Three encodings in one place: Switch between UTF-8, UTF-16 and UTF-32 from a single dropdown instead of opening separate tools. The statistics line and the output update the moment you change it.

Example: the word Go is 47 6F in UTF-8 (one byte each), 00 47 00 6F in UTF-16 big-endian, and 00 00 00 47 00 00 00 6F in UTF-32 big-endian.

Byte order (UTF-16 and UTF-32): Big-endian stores the most significant byte first, little-endian stores it last. The byte order selector appears only when it matters, so you cannot set it by accident for UTF-8, which is byte-oriented and has no endianness.

Example: the letter A is 00 41 big-endian and 41 00 little-endian in UTF-16.

Optional BOM: Ticking Add BOM prepends the correct byte order mark for the chosen encoding and endianness: EF BB BF for UTF-8, FE FF or FF FE for UTF-16, and 00 00 FE FF or FF FE 00 00 for UTF-32. Signalling the encoding this way is useful when a reader has no other hint.

Example: Hi in UTF-16 big-endian with a BOM starts FE FF 00 48 00 69.

Output base: Render each byte as binary, octal, decimal, hexadecimal, or any base from 2 to 36. Bases above 10 use the letters A to Z for the extra digits, exactly like hexadecimal uses A to F.

Example: byte 255 prints as 11111111 in binary, 377 in octal, 255 in decimal and FF in hexadecimal.

Byte delimiter: Set any separator between bytes. A dash is the default and keeps values easy to read; a space, a comma, a newline or no separator at all suit code, spreadsheets or a specific parser.

Example: the first two bytes of OK become 4F-4B by default, and 4F, 4B with a comma and a space.

Prefix and zero-padding: Add prefix tags each byte as 0b, 0o or 0x for binary, octal and hexadecimal so the base is unambiguous. Add zero-padding pads every byte to the full width of the base (eight digits for binary, three for octal and decimal, two for hexadecimal and base-36), so all values line up.

Example: the byte 7 becomes 00000111 in padded binary and 07 in padded hexadecimal.

Live conversion and statistics: The output is produced as you type or whenever an option changes, and the statistics line reports characters, code points and total bytes (including any BOM). Grapheme counting means combined emoji sequences are not over-counted.

File upload, copy, download and clear: Load a .txt file instead of typing, copy the result with one click, download it as a file, or clear both boxes to start over.

Click Try it on any example to load it into the tool. Each example also switches on the encoding and options it demonstrates, and the text on the right is the exact output the tool produces with those settings.

🐙 Octopus
🐬 Dolphin
🦀 Crab

F0-9F-90-99-20-4F-63-74-6F-70-75-73-0A-F0-9F-90-AC-20-44-6F-6C-70-68-69-6E-0A-F0-9F-A6-80-20-43-72-61-62

OK 👍

0b01001111, 0b01001011, 0b00100000, 0b11110000, 0b10011111, 0b10010001, 0b10001101

🌟 Star
🌙 Moon
☄ Comet

FE-FF-D8-3C-DF-1F-00-20-00-53-00-74-00-61-00-72-00-0A-D8-3C-DF-19-00-20-00-4D-00-6F-00-6F-00-6E-00-0A-26-04-00-20-00-43-00-6F-00-6D-00-65-00-74

Café 🌍

FF-FE-00-00-43-00-00-00-61-00-00-00-66-00-00-00-E9-00-00-00-20-00-00-00-0D-F3-01-00

naïve

110-097-195-175-118-101

The table lists every English letter and digit with its code point and its UTF-8, UTF-16 and UTF-32 byte values in hexadecimal. Because these characters all sit below U+0080, UTF-8 uses a single byte for each, UTF-16 stores each in one 16-bit unit and UTF-32 stores each in one 32-bit unit. The UTF-16 and UTF-32 columns are shown in big-endian order.

FAQ 1: What does "Unicode to UTF-8" actually mean?
Answer: Unicode assigns each character a code point number. Converting to UTF-8 means turning those code point numbers into the specific byte sequence UTF-8 defines. The same idea applies to UTF-16 and UTF-32; only the byte pattern changes, the underlying code points stay the same.

FAQ 2: Which encoding should I choose?
Answer: Use UTF-8 for almost anything web, file or network related; it is the standard on the web and stays compact for Latin text. Choose UTF-16 when an API, Windows call or a specific file format asks for it, and UTF-32 when a fixed four-byte width makes indexing simpler. If a target system specifies an encoding, follow its documentation.

FAQ 3: Why do some characters turn into more than one byte?
Answer: The UTF formats are variable length for anything above ASCII. In UTF-8 a code point above U+007F needs two, three or four bytes, and in UTF-16 a code point above U+FFFF is stored as a surrogate pair of two 16-bit units. That is normal and correct, because it is how a single character can cost several bytes.

FAQ 4: What is a BOM, and should I add one?
Answer: A BOM (byte order mark) is a short signature at the start of the data that tells a reader the encoding and, for UTF-16 and UTF-32, the byte order. Add it when a consuming program expects one or when the encoding would otherwise be unclear. For UTF-8 on the web it is usually best left off, because the HTTP header or HTML meta tag already declares the encoding.

FAQ 5: Which byte order should I pick for UTF-16 or UTF-32?
Answer: Byte order is a storage detail, not a different encoding. Big-endian writes the most significant byte first and is common in network protocols, while little-endian is typical on x86 and in Windows. If the system that will read the bytes expects either one, follow its documentation; a BOM can also record the choice for you.

FAQ 6: Is my text uploaded to a server?
Answer: No. All encoding runs in your browser using plain JavaScript, so your text never leaves your device. There is no server-side processing and nothing is stored.