Text Encoding Explained: Binary, Hex, Base64 & URL
Binary, hexadecimal, Base64, and URL encoding all answer the same question — how do you represent text as something else? — but each exists for a different job, and mixing them up is where bugs come from. This guide explains what each one actually does, with a worked example you can reproduce in the Binary to Text Converter, and clears up the single biggest confusion: encoding is not encryption.
What “encoding” actually means
Encoding is reversible representation. You take the same information and write it in a different alphabet — binary digits, hex pairs, a 64-character set, percent codes — so that some system can store or transmit it safely. Anyone can decode it back; there’s no secret key. That’s the line between encoding and encryption, and we’ll come back to it because it matters for security.
Underneath all four schemes is one idea: a computer already stores text as numbers. The letter A is the number 65 (in ASCII and the ASCII range of UTF-8). Every encoding below is just a different way of writing that 65.
Binary — text as 1s and 0s
Binary writes each character’s number in base 2. A (65) becomes 01000001 — eight bits, one byte. It’s how data physically lives in memory, and it’s the clearest way to see that text is numbers.
H = 01001000
i = 01101001Most “binary to text” tasks are about reading a binary string back into letters, or showing students how characters map to bytes. The Binary to Text Converter goes both ways and auto-detects 7- vs 8-bit groupings. Beyond ASCII (numbers above 127 — accents, emoji), UTF-8 uses two to four bytes per character, which is why an emoji is several bytes, not one.
Hexadecimal — binary made readable
Eight binary digits are hard to scan, so developers compress them into hex (base 16). Each byte becomes exactly two hex digits, using 0–9 and a–f. A (binary 01000001) is 41 in hex.
| Char | Decimal | Binary | Hex |
|---|---|---|---|
| A | 65 | 01000001 | 41 |
| H | 72 | 01001000 | 48 |
| i | 105 | 01101001 | 69 |
Hex is everywhere once you look: colour codes (#41A6FF), memory addresses, hashes, byte dumps. Convert in either direction with the Text to Hex Converter. The reason hex and binary pair so neatly is that one hex digit equals exactly four bits — no awkward remainder.
Base64 — binary that survives text-only channels
Some systems only accept plain text — email bodies, JSON, data URIs, HTTP headers. Send raw bytes through them and the bytes get mangled. Base64 solves this by mapping every 3 bytes onto 4 characters from a safe 64-symbol alphabet (A–Z, a–z, 0–9, +, /), padding the end with =.
"Hi" -> SGk=That’s why an embedded image in CSS (data:image/png;base64,…) or an attachment in an email is a long Base64 string. The trade-off: it inflates size by about 33%, so it’s for transport, not storage. Encode or decode with the Base64 Encoder / Decoder. A common gotcha: Base64 is not encryption — anyone can decode it instantly, so never use it to “hide” a password.
URL (percent) encoding — making text safe inside a link
URLs can only contain a limited set of characters, and some — ?, &, /, #, space — have special meaning. To put those characters in a value (a search query, a parameter), you percent-encode them: each unsafe byte becomes % followed by its two-digit hex code.
hello world? -> hello%20world%3FSo a space is %20 and ? is %3F. This is what turns q=text encoding into q=text%20encoding in a query string. Encode or decode with the URL Encode / Decode tool. Non-ASCII characters are first turned into their UTF-8 bytes, then each byte is percent-encoded.
Which encoding for which job
| You need to… | Use | Tool |
|---|---|---|
| See the raw bytes of text / teach how characters map | Binary | Binary to Text |
| Read a compact, dev-friendly byte representation | Hex | Text to Hex |
| Put binary data inside text-only channels (email, JSON, data URIs) | Base64 | Base64 |
| Put special characters safely inside a URL | Percent | URL Encode |
Encoding vs encryption vs hashing
This is the part that trips people up, and getting it wrong is a real security risk:
- Encoding (everything above) is reversible and public — no key. Goal: compatibility.
- Encryption is reversible but only with a key. Goal: confidentiality.
- Hashing is one-way — you can’t get the input back. Goal: verification (passwords, file integrity).
If you Base64-encode a secret, you have not protected it at all. Use encryption for secrets and hashing for passwords; use encoding only to move data around safely.
FAQ
Is Base64 a form of encryption?
No. Base64 is encoding — it has no key and anyone can decode it in one step. It makes binary data safe to send through text-only channels; it does nothing to keep it secret.
Why does my emoji turn into several bytes?
Characters outside the basic ASCII range are stored in UTF-8 using two to four bytes. So one emoji can be four bytes, which then shows up as multiple hex pairs or a longer binary string — that’s expected, not a bug.
What’s the difference between hex and binary if both show bytes?
They’re the same information at different readability. One byte is eight binary digits or two hex digits. Hex is just a shorter, human-friendlier way to write the same 1s and 0s.
When do I need URL encoding?
Whenever you place a value containing spaces or reserved characters (? & / # =) into a URL — typically query-string parameters. The percent codes keep those characters from being interpreted as URL syntax.
Does encoding change the actual data?
No — it changes only the representation. Decode it and you get the exact original bytes back. That’s the whole point of encoding, and the difference from a one-way hash.
Working with encoded data? Keep the four converters one click apart — Binary, Hex, Base64, and URL — and pick the one that matches the channel you’re sending through, not the one you saw first.