Encoding Converter
Convert text between Base32, Base58, hex, binary, character codes, punycode and quoted-printable — with what each is actually for.
The alphabets are not arbitrary
Each of these is a decision about who is going to read the result. Base32 uses A to Z and the
digits 234567 — the missing ones are the point.
0 1 8 9 are gone: 0 and 1 because they are hard to
tell from O and I, 8 and 9 simply because 26 letters plus six digits already makes 32 and no
more were needed. The result is an alphabet you can read down a phone line.
Base58 is designed for somebody copying a string by hand. From the 62 alphanumerics it removes
exactly four: I O l 0.
The rule behind those four is worth getting right, because the obvious version is wrong. It
is not "drop both halves of each confusable pair" — base58 keeps 1 and
drops l. What it does is thin each group of lookalikes until no two survivors
can be confused:
| Lookalike group | Kept | Dropped |
|---|---|---|
| zero, capital O, lower-case o | o | 0 O |
| one, lower-case L, capital I, lower-case i | 1 i | l I |
Every group loses somebody and every group keeps somebody. Base64, by contrast, removes nothing and adds two symbols — it is the one designed for machines, on the assumption that nobody will ever read it aloud.
Case is information in one and not the other
Base32 has no lower case at all, so case carries nothing and this page upper-cases whatever you paste before decoding it. A base32 string survives being shouted across a room, written on a whiteboard, or passed through a system that normalises case.
Base64 uses both cases as different symbols: A is
0 and a is 26. Upper-casing a base64 string
destroys it silently. That single difference is most of why authenticator secrets and DNS
records are base32 rather than the more compact base64 — they get retyped by people.
All of that readability is bought with size. The cost is set by how many bits each character carries:
| Encoding | Symbols | Bits per character | Size of the output | Meant for |
|---|---|---|---|---|
| hex | 16 | 4.000 | 200.0% | machines and debuggers |
| base32 | 32 | 5.000 | 160.0% | read aloud and retyped |
| base58 | 58 | 5.858 | 136.6% | copied by hand |
| base64 | 64 | 6.000 | 133.3% | machines |
Base58 is within four points of base64 while staying safe to retype, which is a good bargain and the reason it is used for keys and addresses. Base32's 160% is the real price of the phone-line property. Measured on 100 bytes: hex 200, base32 160, base64 136 characters.
One structural difference behind those numbers: base32 and base64 work in fixed blocks — five bytes to eight characters, three to four — so their output length is a simple function of the input length, and they pad to fill the last block. Base58 is arithmetic on one enormous number, so it has no block size, no padding, and a length that depends on the actual value of the bytes rather than just how many there are.
Punycode is a different kind of encoding entirely
The others turn bytes into text. Punycode turns text into narrower text: it exists
because the domain name system carries ASCII and people want domains in their own script. A
label that needs encoding is prefixed with xn--, and everything after
that is plain ASCII.
| Domain | As ASCII | Labels encoded |
|---|---|---|
café.com | xn--caf-dma.com | 1 of 2 |
münchen.de | xn--mnchen-3ya.de | 1 of 2 |
пример.рф | xn--e1afmkfd.xn--p1ai | 2 of 2 |
example.com | example.com | 0 of 2 |
Conversion happens label by label, so an already-ASCII domain passes through untouched and only the parts that need encoding are changed. A domain written entirely in another script has every label encoded separately — пример.рф becomes xn--e1afmkfd.xn--p1ai, including the country suffix.
It is also where a real security problem lives. Two domains can look identical on screen and be
entirely different names underneath, because the letters come from different scripts. The
encoded form is the one that tells you the truth, which makes pasting a suspicious link in here
a genuinely useful thing to do — the xn-- prefix on a domain
you thought was ordinary English is the tell.
How to use
- Paste your text or your already-encoded data.
- Pick the source encoding and the target.
- Read the converted result.
- Check a round trip if the data matters.
- Remember that none of these provide any security whatever.
Frequently asked questions
Is any of this encryption?
None of it, and this matters. Every encoding here is fully reversible by anyone, with no key required. They exist to move data safely through channels that expect particular characters, not to conceal anything — treating an encoding as protection is a genuine and recurring security mistake.
What is Base58 for?
Bitcoin addresses and similar identifiers. It deliberately omits the characters most easily confused when read aloud or transcribed by hand — zero and capital O, capital I and lowercase l — which makes an address far less error-prone for a human to copy.
Why does Base32 exist when Base64 is more compact?
Because it is case-insensitive and uses a character set that survives being spoken aloud, written on paper or typed on a numeric keypad. That makes it suitable for things humans handle directly, which is exactly why two-factor authentication secrets are Base32.
What is punycode?
The encoding that represents non-ASCII domain names within the ASCII-only system the domain infrastructure requires. It is also the mechanism behind homograph attacks — a domain using Cyrillic characters that look identical to Latin ones displays as a familiar name while resolving somewhere else entirely.
What is quoted-printable?
An email encoding that leaves ordinary ASCII text readable while escaping anything else as an equals sign followed by hex digits. It is why raw email sometimes shows those sequences mid-word, and why long lines are broken with a trailing equals sign.
Does my text get uploaded?
No. Every conversion runs entirely in your browser, which matters a good deal here — people paste tokens, keys and identifiers into encoding tools far more often than they probably should.
Why does my decoded text look like nonsense?
Usually a character encoding mismatch underneath. These schemes encode bytes rather than characters, so text converted to bytes as UTF-8 and decoded as something else produces mojibake. Confirming which byte encoding was used is what resolves it.
🔒 This tool runs entirely in your browser. Nothing you enter is uploaded, logged, or stored.