Home / Text Encoding & Byte Tools / Text to Hex Converter

Text Encoding & Byte Tools

Text to Hex Converter

Convert Unicode text to exact hex bytes, reverse-decode hex strictly, and inspect normalization, BOM, byte order, code points and byte offsets locally.

Wave164 · Unicode text ⇄ exact byte representation

Text ↔ Hex Byte & Unicode Encoding Studio

Encode text to exact bytes, control Unicode normalization and byte order, reverse-decode hex strictly, then inspect code points, offsets and round-trip evidence without uploading content.

local · reversible · byte-audited

Character encodingUnicode normalizationHex prefixSeparatorBytes per output lineUppercase hexPrepend BOM where definedStrip BOM on reverse decode

Unicode text

Import text file

Hex bytes

Ready.

1. Encoding & round-trip evidence

Encoded bytes—

Unicode code points—

UTF-16 code units—

Raw hex digits—

BOM detected—

Combining marks—

Normalization changed text—

Strict round-trip—

Strict decoded text

2. Unicode code-point → byte-offset map

#	Character	Code point	UTF-16 units	Byte offsets	Encoded bytes

3. Raw byte table

Offset	Hex	Decimal	Binary

4. Cross-check representations

Base64 of the same bytes

Percent notation of the same bytes

5. Audit & export

Encode or decode to generate an audit.

Local numeric history

Why this is more than “letters become hex”

Encoding defines the bytes

The same Unicode text has different hex under UTF-8 and UTF-16. ASCII/Latin-1 modes reject code points they cannot represent instead of silently inventing bytes.

Normalization can change bytes

NFC/NFD/NFKC/NFKD can change the code-point sequence before encoding. The Studio reports when normalization changes the input so equal-looking text is not mistaken for byte-identical text.

BOM and endianness are explicit

UTF-16 byte order and optional BOM bytes are shown separately. A BOM is metadata at the byte level, not part of the visible text after stripping.

Reverse decode is strict

Malformed hex, odd-length continuous input, invalid UTF-8 and invalid ASCII bytes are blocked rather than replaced silently during reverse verification.

Code point ≠ byte

One visible character can be several Unicode code points, UTF-16 code units and encoded bytes. The offset table keeps those layers separate.

Hex is not encryption

Hex only changes how bytes are written. Anyone with the encoding can reverse it; it provides no confidentiality or cryptographic protection.

Truth boundary: Text is handled locally. UTF-8 uses the browser Encoding API; UTF-16/ASCII/Latin-1 are explicit byte mappings in this Studio. Latin-1 here means ISO-8859-1, not Windows-1252. File import is capped at 2 MB for browser responsiveness. This tool does not detect an unknown source encoding, decrypt data, prove visual grapheme identity, or guarantee that another program interprets the same bytes with the same encoding.

Text must become bytes before it can become hex

Hex is only a notation for bytes. UTF-8, UTF-16 little-endian, UTF-16 big-endian, ASCII and ISO-8859-1 can therefore produce different results for the same visible text.

Unicode normalization is a real byte-level choice

Canonically equivalent strings such as precomposed and combining-mark forms can look alike while producing different byte sequences. Apply normalization only when the protocol or storage format actually expects it.

Strict reverse decode is the fastest verification

Decode the produced bytes using the same encoding and compare the normalized source with the result. Invalid UTF-8, invalid ASCII bytes or malformed hex should be treated as evidence—not silently repaired.

Privacy and portable evidence

Text stays in this browser tab. History stores only numeric counts and settings-only share links exclude source text, hex output and local history.

Byte representation is separated from Unicode text

The review reports exact UTF-8 bytes, strict decode status, BOM presence and round-trip behavior so hex/decimal/binary notation is not confused with Unicode code-point notation.