Six ways to represent the same bytes
Hex encoding shows up in a different syntax depending on where it's going. This tool picks the right one instead of leaving you to hand-format it:
- Plain hex — raw
48656c6c6f, optionally spaced and uppercase - JavaScript —
\x48\x65...string escapes, valid to paste directly into a JS string literal - JSON —
\u0048\u0065..., the only escape form JSON strings accept (JSON has no\x) - HTML / XML —
He...numeric character references - SQL —
0x48656c6c6f, the hex-literal syntax MySQL and SQL Server accept for binary/string data
Plain hex and SQL mode encode the input's raw UTF-8 bytes. JavaScript and JSON mode encode UTF-16 code units instead, matching how those languages actually represent a string internally. HTML and XML mode encode full Unicode code points, per the numeric character reference spec. For most ASCII text the three approaches produce visually similar output — they diverge once the input has accented letters, symbols, or emoji, so pick the mode by target syntax rather than assuming they're interchangeable.
FAQ
Why does JavaScript mode mix \x and \u?
\xHH only covers code unit values 0–255; anything higher (accented letters past the Latin-1 range, symbols, emoji) needs the four-digit \uHHHH form. Both are valid inside the same JS string literal.
Why is the SQL output all one block with no spaces?
0x... hex literals in SQL are a single continuous token — a space in the middle would break the syntax, so this mode never adds one.
What's the difference between HTML and XML mode here?
None — both use identical &#xHH; numeric character reference syntax. They're offered separately since it's not obvious HTML and XML share this without checking.
Try it yourself
Decode hex back to text — in any of these six formats — with Hex Decode. For binary data as text more generally, see Base64 Encode.