UTF-16 Converter

Encode text to UTF-16 (LE/BE) byte sequences and decode UTF-16 buffers back to text.

Tested tool guide Tested browser tools Checked August 16, 2026

What UTF-16 Converter does, with a checked example

Paste text and this page returns its UTF-16 byte sequence in little-endian, big-endian, or both; paste hex bytes and it runs the encoding backward. Every character becomes one 16-bit code unit - two bytes - except supplementary-plane characters such as most emoji, which become a surrogate pair of two code units, four bytes. The usual surprise is byte order: the same text produces different bytes in the two endiannesses, and only a leading BOM (FF FE or FE FF) tells a decoder which one it is. Conversion happens locally; nothing leaves the page.

Worked example

A concrete input and expected output from the current implementation.

Input

A\uD83D\uDE00 (the text 'A' followed by the grinning-face emoji)

Expected output

LE: 41 00 3D D8 00 DE | BE: 00 41 D8 3D DE 00

A is U+0041, one code unit, two bytes. The emoji is U+1F600, above the BMP, so it becomes the surrogate pair D83D DE00 - four bytes. Each unit's bytes are emitted low-first (LE) or high-first (BE); both encodings are 6 bytes here.

How the result is produced

Code units, not characters

The encoder maps each Unicode code point to one or two 16-bit code units: U+0000 to U+FFFF takes one unit, while code points from U+10000 up (emoji, rare scripts, some CJK extensions) split into a high surrogate (D800-DBFF) and a low surrogate (DC00-DFFF). Each unit is then written as two bytes, low byte first in little-endian mode, high byte first in big-endian mode.

Decoding and byte order

Decoding is the reverse: incoming bytes are paired into 16-bit code units in the endianness you chose, then each unit - or pair of adjacent surrogates - maps back to a character. A leading BOM records which order a file uses: FF FE for little-endian, FE FF for big-endian. Malformed input - an odd number of bytes, or a surrogate without its partner - has no valid decoding.

Good uses

Checking that bytes you are about to write really are UTF-16: encode a sample string and compare the hex against what a Windows wide-string API or a .NET, Java, or Swift string would emit.
Recovering text from a hex dump of a UTF-16 file - Notepad 'Unicode' saves, exported database or game files - by pasting the byte sequence back in and reading the result.
Diagnosing mojibake between systems: encode a known string both ways and compare byte length and leading BOM bytes to identify whether a buffer is UTF-16LE, UTF-16BE, or some unrelated encoding.

Limits and checks

Supplementary characters break the 'two bytes per character' mental model: one emoji is four bytes, so byte counts are not character counts. Any length, storage, or alignment estimate made from character count is wrong above U+FFFF.
Endianness is invisible in the content: the same bytes decode to different text under LE and BE. Without a BOM the tool cannot know which you meant, so the wrong choice yields text that looks plausible but is garbage.
Pasted hex must be whole code units: an odd digit count leaves a dangling byte, and stray non-hex characters break the pairing. Unpaired surrogates cannot round-trip; output full of U+FFFD replacement characters usually means malformed input rather than a wrong setting.

Common questions

What is the difference between UTF-16 and UTF-8?

Both encode the same Unicode characters. UTF-16 uses 2 or 4 bytes per character and is native to Windows, Java, and .NET; UTF-8 uses 1 to 4 bytes, is a superset of ASCII, and dominates the web and file interchange. This page works on text, not on UTF-8 bytes: pasting a UTF-8 hex dump in here would decode it as UTF-16 and produce nonsense.

Do I need to include the BOM?

Only if the receiver cannot infer byte order. Windows Notepad and many .NET and Windows API paths write a BOM and expect one; Unix tools and web specs usually assume a stated endianness. And the BOM is data, not decoration: a file starting FF FE contains the invisible character U+FEFF as its first code point, so decoded output can begin with a character you cannot see.

References and verification

The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.