UTF-8 Encoder/Decoder — Convert Text to UTF-8 Hex Bytes
Ever wondered why a smiley emoji takes 4 bytes and a plain letter takes 1? This UTF-8 encoder / decoder shows you exactly. Paste "Hello 🌍" and it produces the byte sequence "48 65 6C 6C 6F 20 F0 9F 8C 8D" — each byte as two hex digits. Paste those bytes back and recover the original text. Backend developers use it to debug mojibake and encoding mismatches; security researchers use it to spot overlong UTF-8 encodings; i18n engineers use it to verify that multi-byte CJK and emoji characters are handled correctly. No signup needed.
What Is UTF-8 Encoder/Decoder?
A UTF-8 encoder converts text into its UTF-8 byte sequence — the binary representation used to store and transmit text in most modern systems, databases, and protocols. A UTF-8 decoder reverses the process, converting a byte sequence back into readable text. This tool handles both directions in the browser, with no data sent to any server.
UTF-8 is the dominant character encoding for the web, used by over 98% of websites. Every character — from ASCII letters to accented characters, emoji, and CJK ideographs — maps to between one and four bytes in UTF-8. Understanding this encoding is essential for debugging text corruption, working with binary data, building internationalized applications, and inspecting file contents at the byte level.
Hello 🌍→48 65 6C 6C 6F 20 F0 9F 8C 8DBefore & After: UTF-8 Encoder/Decoder Examples
Real input → output pairs showing exactly what this tool does to your text.
| Input | UTF-8 Encoder/Decoder Output |
|---|---|
Hello | 48 65 6C 6C 6F |
café | 63 61 66 C3 A9 |
🌍 | F0 9F 8C 8D |
中文 | E4 B8 AD E6 96 87 |
48 65 6C 6C 6F (decode) | Hello |
Key Features
Converts text to the UTF-8 byte sequence defined in RFC 3629 (2003) — the dominant web encoding used by over 98% of websites per W3Techs. Designed by Ken Thompson and Rob Pike in 1992 for backward compatibility with ASCII.
See exactly how many bytes each character requires: ASCII = 1 byte, accented Latin = 2 bytes, CJK characters = 3 bytes, emoji = 4 bytes — critical for systems with byte-length limits, not character-length limits.
Hex byte sequences (like "48 65 6C 6C 6F") are automatically decoded to text; plain text is automatically encoded to hex bytes. No mode toggle needed.
UTF-8 encoding and decoding runs entirely in your browser. No text is sent to any server — safe for inspecting private messages and sensitive data.
When to Use UTF-8 Encoder/Decoder
Use for debugging Unicode encoding issues, inspecting emoji and special character byte sequences, or working with raw UTF-8 byte data.
Auto-detects direction. Unlike Hex to Text (which uses single-byte ASCII), this correctly handles multi-byte UTF-8 characters including emoji and accented letters.
Who Should Use This Tool?
Inspect and verify UTF-8 byte sequences when debugging character encoding issues in databases, APIs, or file systems.
Verify multi-byte character encoding for non-ASCII text including CJK characters, Arabic, Hebrew, and emoji.
Examine UTF-8 encoding and decoding behavior to identify encoding-based attack vectors such as overlong encodings.
Industry Standard
UTF-8 was designed by Ken Thompson and Rob Pike in 1992 and standardised in RFC 3629 (2003). It is the dominant encoding for the web — used by over 98% of websites according to W3Techs. The HTML5 specification requires UTF-8 as the document character encoding. Linux, macOS, and modern Windows all use UTF-8 as their default filesystem encoding. The Unicode Consortium maintains the UTF-8 specification as part of the Unicode Standard.
Key Use Cases
- →Encode text to UTF-8 bytes to inspect how many bytes a string occupies, especially for emoji and multi-byte characters.
- →Decode a UTF-8 byte sequence received from a binary file or network stream back into readable text.
- →Verify that a text string round-trips correctly through encode/decode without corruption.
- →Debug character encoding issues where text displays as garbled characters (mojibake) after database retrieval.
- →Inspect the byte count of text for systems with byte-length limits rather than character-length limits.
UTF-8 Encoder/Decoder vs Other Formats
How this tool compares to related approaches and methods
| Method / Format | Best For |
|---|---|
| THISThis tool | Inspecting UTF-8 byte sequences, debugging mojibake, and verifying multi-byte character encoding |
| Hex to Text (ASCII only) | ASCII text inspection and packet payload analysis — use UTF-8 encoder for emoji and non-ASCII text |
| Python text.encode("utf-8") | Server-side UTF-8 encoding in Python scripts, database inserts, and file writes |
| hexdump -C (terminal) | File-level byte inspection — shows raw bytes of a file rather than a typed string |
UTF-8 Encoder/Decoder Rules: How It Works
- →ASCII characters (U+0000–U+007F) encode as 1 byte — identical to plain ASCII, giving full backward compatibility.
- →Latin extended and most European characters (U+0080–U+07FF) encode as 2 bytes.
- →CJK ideographs, Arabic, Hebrew, and most other scripts (U+0800–U+FFFF) encode as 3 bytes.
- →Emoji, rare symbols, and supplementary characters (U+10000–U+10FFFF) encode as 4 bytes.
- →Byte count ≠ character count — "Hello" is 5 bytes; "héllo" is 6 bytes; "h🌍lo" is 8 bytes.
- ×UTF-8 is not encryption — it's a storage format. Anyone can decode UTF-8 bytes back to text.
- ×UTF-8 is not the same as UTF-16 or UTF-32 — other encodings that also represent Unicode but use different byte structures.
- ×UTF-8 is not Base64 — Base64 encodes bytes as ASCII text; UTF-8 encodes characters as bytes.
- ×The byte order mark (BOM) is optional in UTF-8 and often causes parsing problems — most tools should omit it.
Where It's Applied
How to Use UTF-8 Encoder/Decoder
- Paste or type your text into the Input Text box.
- The result appears instantly on the right.
- Click Copy to copy the output to your clipboard.
- Click Clear to reset and process new text.
This Converter vs Manual Methods
Why use this tool instead of doing it by hand?
| Method | Limitation |
|---|---|
| Python text.encode("utf-8") | Requires Python knowledge and coding — not quick for one-off byte inspection |
| hexdump -C file.txt | Inspects files, not typed strings; requires a terminal and Unix system |
| Browser DevTools character inspection | Does not show UTF-8 byte sequence directly; requires manual byte calculation from the code point |
| charCodeAt() in browser console | Returns UTF-16 code units, not UTF-8 bytes — different multi-byte structure for non-BMP characters |
| ✓ BESTThis tool | None |
Common Mistakes & Pro Tips
- !Confusing UTF-8 encoding with Base64 encoding — UTF-8 is how characters are stored as bytes; Base64 is how binary data (including UTF-8 bytes) is encoded as safe ASCII text for transmission. They serve different purposes and are often combined: text → UTF-8 bytes → Base64 string.
- !Assuming character count equals byte count — a single emoji can occupy 4 bytes, and accented Latin characters occupy 2 bytes each in UTF-8. Always check byte length when working with systems that impose byte-based limits.
- !Using UTF-8 where utf8mb4 is required in MySQL — MySQL's "utf8" charset only stores up to 3-byte characters and silently truncates emoji (which need 4 bytes). The correct MySQL charset for full Unicode support including emoji is utf8mb4. PostgreSQL's UTF8 correctly handles 4-byte characters without this issue.
Frequently Asked Questions
Everything you need to know about UTF-8 Encoder/Decoder
What is UTF-8 and why is it the standard?
+
UTF-8 is a variable-width character encoding that can represent every character in the Unicode standard. It uses 1 byte for ASCII characters, and 2–4 bytes for other characters. It is the standard because it is backward-compatible with ASCII, space-efficient for English text, and capable of encoding every language and emoji defined in Unicode. Over 98% of the web uses UTF-8.
What is the difference between UTF-8 encoding and URL encoding?
+
UTF-8 encoding converts text to raw bytes. URL encoding (percent-encoding) converts those bytes into a format safe for use in URLs by representing each byte as %XX where XX is the hexadecimal value. URL encoding builds on UTF-8: first the text is encoded to UTF-8 bytes, then those bytes are percent-encoded. Use the URL Encoder/Decoder for URL-safe encoding.
What is the difference between UTF-8, UTF-16, and UTF-32?
+
All three encode the Unicode character set but use different byte structures. UTF-8 uses 1–4 bytes per character and is backward-compatible with ASCII — dominant on the web and in Linux/macOS. UTF-16 uses 2 or 4 bytes per character and is the native string format in JavaScript, Java, C#, and Windows internals. UTF-32 uses exactly 4 bytes per character — simple but space-inefficient, used in some Unix environments. For web APIs and files, UTF-8 is almost always the correct choice.
What is mojibake and how does UTF-8 encoding cause it?
+
Mojibake (文字化け — Japanese for "character transformation") is garbled text that appears when text encoded in one character encoding is decoded as another. Example: the é character encoded as UTF-8 (bytes C3 A9) decoded as ISO-8859-1 appears as "é". Common causes: databases configured with latin1 instead of utf8mb4, missing charset=utf-8 in HTML, or reading a UTF-8 file as Windows-1252. The UTF-8 encoder/decoder shows the raw byte sequence so you can identify encoding mismatches.
How does UTF-8 encode emoji?
+
Emoji characters have Unicode code points above U+FFFF (the "Basic Multilingual Plane"), requiring 4 bytes in UTF-8. Example: 🌍 (U+1F30D) encodes as bytes F0 9F 8C 8D. The leading F0 byte signals a 4-byte sequence. By contrast, ASCII characters (A–Z, 0–9) need only 1 byte; accented Latin characters like é (U+00E9) need 2 bytes (C3 A9); CJK characters like 中 (U+4E2D) need 3 bytes (E4 B8 AD). Systems with byte limits (SMS: 140 bytes; databases with column byte limits) may cut off text at the byte boundary.
Why does the BOM (Byte Order Mark) cause problems in UTF-8?
+
The BOM (U+FEFF, bytes EF BB BF in UTF-8) is an optional signature at the start of a UTF-8 file. It is never needed in UTF-8 (unlike UTF-16 where byte order matters), and many tools treat it as literal content rather than a file signature. The BOM causes problems in: PHP scripts (outputs before headers, breaking session/cookie handling), CSV files opened in Excel (causes "EF BB BF" to appear in the first cell), HTTP responses (some parsers fail), and Linux/macOS terminal commands (the leading BOM is processed as part of the first line). Best practice: write UTF-8 without BOM unless Windows Notepad interoperability is required.
What is the UTF-8 maximum byte count per character and why?
+
UTF-8 uses a maximum of 4 bytes per character because Unicode defines code points from U+0000 to U+10FFFF — a range of about 1.1 million characters. This range fits in 21 bits (2²¹ = 2,097,152). UTF-8's 4-byte sequences provide 21 bits of payload (3 bits in the leading byte + 6 bits in each of 3 continuation bytes). RFC 3629 (2003) limited UTF-8 to 4 bytes by restricting it to the Unicode range — earlier versions theoretically supported up to 6 bytes to cover code points up to 2³¹, but those code points were never assigned.