UTF-8 Characters: Examples and How Encoding Works

UTF-8 turns letters, symbols, and emoji into bytes that computers can store, send, and rebuild. It is the reason “Hello”, “café”, “東京”, and “😄” can live in the same file without a fight. W3Techs reports that UTF-8 is used by about 98% of websites with a known character encoding [source: W3Techs].

TLDR: UTF-8 is a smart text encoding system. It uses 1 to 4 bytes for each character. For example, A uses 1 byte, but 😄 uses 4 bytes. If a shop adds emoji to 10,000 product reviews, UTF-8 keeps the text readable for users in many languages.

What is UTF-8?

UTF-8 is a way to write text as numbers.

Computers do not really store letters. They store bytes. A byte is a small chunk of data made of 8 bits. Bits are just 1s and 0s. Very tiny. Very strict. Kind of boring.

UTF-8 makes those boring bits useful.

It says, “This number means this character.” So the letter A becomes one set of bytes. The euro sign € becomes another. A smiling face 😄 gets its own byte pattern too.

That is the magic. Same system. Many scripts. One shared plan.

Characters vs encoding

Here is the simple split.

A character is the thing you see, like A, é, or 火.
A code point is the official Unicode number for that character.
Encoding is how that number becomes bytes.

Think of Unicode as a giant guest list. Every character gets a seat number. UTF-8 is the bus that brings those seats to your screen.

For example:

A has the Unicode code point U+0041.
é has the code point U+00E9.
€ has the code point U+20AC.
😄 has the code point U+1F604.

The code point is not always the same as the bytes. That little detail causes many headaches. Honestly, it feels like text should be easier by now.

How UTF-8 uses bytes

UTF-8 is called a variable length encoding. That means not every character uses the same amount of space.

It works like this:

1 byte for common English letters, digits, and basic punctuation.
2 bytes for many accented letters and nearby scripts.
3 bytes for many Asian characters and symbols.
4 bytes for many emoji and rare characters.

This is clever. Plain English stays small. Global text still works.

Here are some real examples:

Character	Meaning	UTF-8 bytes	Bytes used
A	Latin capital A	`41`	1
é	e with accent	`C3 A9`	2
€	Euro sign	`E2 82 AC`	3
😄	Smiling emoji	`F0 9F 98 84`	4

Those byte values are often shown in hexadecimal. That is base 16. It sounds scary. It is just a shorter way to write binary.

Why does English get 1 byte?

UTF-8 was built to play nicely with older systems.

Long before emoji took over group chats, many computers used ASCII. ASCII covered basic English letters, numbers, and symbols. It used values from 0 to 127.

UTF-8 keeps those same values. So plain ASCII text is also valid UTF-8 text.

That was a huge win. Old files did not burst into flames. Servers did not need to panic. Developers still panicked, of course, but slightly less.

What happens when encoding goes wrong?

Bad encoding creates ugly text. You have seen it.

It looks like this:

cafÃ© instead of café
â‚¬ instead of €
ðŸ˜„ instead of 😄

This mess is often called mojibake. Great word. Terrible experience.

It happens when bytes are read using the wrong encoding. Maybe the file is UTF-8, but the app reads it as Windows-1252. Maybe a database column was set wrong. Maybe an email tool guessed badly.

The catch is that the bytes may be fine. The reader is the problem.

Imagine sending C3 A9. In UTF-8, that means é. But another system may read those bytes as two separate characters. Then you get garbage. It drives me crazy that one tiny setting can turn a clean customer name into soup.

UTF-8 in everyday life

You use UTF-8 all the time.

When you send a message with emoji.
When a website shows Japanese text.
When a product name contains crème brûlée.
When a username includes non-English letters.
When a CSV file stores names from many countries.

Here is a small user case.

A support team exports 50,000 customer messages. About 22% contain emoji. Around 18% include accented names, such as José or Zoë. If the export uses UTF-8, the file works in most modern tools. If it uses the wrong encoding, the team may spend hours cleaning weird symbols before they can even start reading complaints. Fun? No. Avoidable? Yes.

How UTF-8 knows byte length

UTF-8 has patterns.

The first byte tells the computer how many bytes belong to the character.

0xxxxxxx means 1 byte.
110xxxxx starts a 2 byte character.
1110xxxx starts a 3 byte character.
11110xxx starts a 4 byte character.

Extra bytes start with 10. That tells the reader, “I am not the start. I am part of the same character.”

So UTF-8 is not guessing. It follows rules.

Quick examples you can remember

Use these as pocket examples.

Hello uses 5 bytes. One byte per letter.
café uses 5 bytes. The é takes 2 bytes.
€10 uses 5 bytes. The € takes 3 bytes. The digits take 1 each.
Hi 😄 uses 7 bytes. H, i, and the space use 3 bytes total. The emoji uses 4.

This is why character count and byte count are not the same. A tweet, password, database field, or API limit may care about bytes. Not just visible characters.

Best practices for UTF-8

Most modern apps should use UTF-8 by default.

Save text files as UTF-8.
Use <meta charset="UTF-8"> in web pages.
Set databases and tables to UTF-8 capable settings.
Send API responses with a clear charset.
Test with emoji, accents, and non-Latin text.

Do not test only with Bob and Alice. Add Renée, Иван, 東京, and 😄. They will find problems faster.

The simple mental model

Unicode gives each character a number. UTF-8 turns that number into bytes. Your app stores or sends those bytes. Another app reads the bytes and rebuilds the character.

So remember this. UTF-8 is the friendly translator between human text and computer bytes. It keeps English compact. It supports global writing. It gives emoji a safe home. And yes, it saves you from many weird, tiny text disasters.