Base64 vs Hex Encoding: When to Use Which

Hex and Base64 are two different ways to write down the same bytes. Hex spends exactly 2 characters per byte (a 100% size increase), uses only 0-9 and A-F, ignores case and needs no padding. Base64 spends 4 characters per 3 bytes (about 33% larger), uses 64 symbols where upper and lower case are different data, and pads the end with =. Use hex when a person needs to read, compare or index the bytes; use Base64 when the bytes have to travel inside text and size matters. Try both side by side in the hex encoder and the Base64 encoder.

TL;DR

• Size: hex is always 2× the bytes; padded Base64 is 4 characters for every 3 bytes, rounded up. For 1,000 bytes that is 2,000 hex characters vs 1,336 Base64 characters.
• Not always shorter: for 1 byte Base64 needs 4 characters vs 2 for hex, and for 2 or 4 bytes they tie (4 vs 4, 8 vs 8).
• Case: ff and FF are the same hex byte; in Base64, Zm9v is the text "foo" and zm9v is different bytes.
• URLs and file names: hex is always safe; standard Base64 contains +, / and =, so use the URL-safe variant (- and _) there.
• Neither is encryption. Both are fully reversible by anyone.

Same Bytes, Two Spellings

Take the three bytes of the text Man: 01001101 01100001 01101110. Each encoding just regroups those 24 bits.

• Hex cuts them into 4-bit groups: 0100 1101 | 0110 0001 | 0110 1110 → 4 d | 6 1 | 6 e → 4d616e. Every byte is exactly one pair of characters.
• Base64 cuts the same bits into 6-bit groups: 010011 010110 000101 101110 → T W F u → TWFu. The first byte (M) is split across two characters, T and W.

That one difference explains most of the trade-offs below. Hex lines up with byte boundaries, so you can read byte number n straight off the string. Base64 packs more bits per character (6 vs 4), so it is shorter, but bytes no longer line up with characters. The standard itself says the Base 64 encoding is designed to represent arbitrary bytes in a form that "need not be human readable" (RFC 4648, section 4), while its Base 16 section describes "the standard case-insensitive hex encoding" (section 8).

Side-by-Side Comparison

The URL point is the standard's own caution: RFC 4648 section 3.4 notes that for base 64 the non-alphanumeric characters, in particular /, "may be problematic in file names and URLs", and section 5 defines the URL- and filename-safe alphabet that swaps in - and _.

How Big Is the Difference? (Computed, Not Estimated)

These lengths come from running the same Base64 code that powers the Base64 encoder on byte strings of each length; hex is simply twice the byte count.

Three things stand out. First, padded Base64 is not always shorter: at 1 byte it is twice as long as hex, and at 2 and 4 bytes it ties. Second, the saving settles at one third as the data grows: at 1 MiB, Base64 is 699,048 characters shorter than hex (33.3%). Third, the digest-sized rows are the ones people meet most: 16, 32 and 64 bytes are the raw lengths of an MD5, SHA-256 and SHA-512 digest, which is 32, 64 and 128 hex characters but 24, 44 and 88 padded Base64 characters.

A Worked Example

Here are four short ASCII strings encoded both ways with the site's tools. For plain ASCII, the bytes are just the character codes, so both tools see the same input.

Note the = signs: 13 bytes is not a multiple of 3, so the last group is short and gets two pad characters. Hex never has this problem. Convert in either direction with the hex encoder or the Base64 encoder, and see how to convert hex to text for the hex side step by step.

Case Matters in Base64, Not in Hex

Hex decodes the same whether you write ff or FF. Base64 does not: Zm9v decodes to the text foo, but changing it to zm9v decodes to the bytes ce 6f 6f, which is not the same data (and not valid UTF-8 text either). Any system that changes the case of text, such as a field that is lower-cased or a case-folding comparison, will silently corrupt Base64 and leave hex intact.

Check Before You Compare the Two Tools on Non-ASCII Text

For ASCII text the two tools agree byte for byte, as in the table above. Beyond ASCII they do not, because they treat text differently: the Base64 encoder converts the text to UTF-8 bytes first, while the hex encoder writes out each JavaScript character code as hex digits. Here is the same character through both:

So if you encode the same non-ASCII text in both tools, the two results will describe different bytes, and the hex encoder's output for characters above U+00FF is the character code rather than UTF-8. Stay with ASCII when you want a like-for-like comparison, or use the Base64 tool's UTF-8 bytes as the reference.

When to Use Which

This is a rule of thumb drawn from the properties above, not a standard:

• A person has to read, diff or index the bytes (debugging, logs, comparing two values, spotting which byte changed): use hex. Byte n is always characters 2n and 2n+1.
• Binary has to ride inside text and size matters (embedding data in a text field): use Base64. About 33% overhead beats 100%; at 1 MiB that is 1,398,104 characters against 2,097,152.
• The value goes into a URL or a file name: hex is always safe. If you want Base64's shorter form, use the URL-safe variant, and note that RFC 4648 section 5 allows skipping the = padding when the data length is known.
• The value is only 1 to 4 bytes: the table shows hex is as short or shorter, so there is no size reason to reach for Base64.
• Something might change the letter case: choose hex.
• Confidentiality is the goal: neither helps. Both are plain, reversible encodings.

Common Mistakes

• Assuming Base64 is always smaller. It is for long data, but not for 1-byte values, and it ties at 2 and 4 bytes.
• Lower-casing or re-casing a Base64 string. That changes the data.
• Dropping the padding where it is required. The standard requires padding unless the specification using it says otherwise (RFC 4648 section 3.2).
• Putting standard Base64 into a URL as is. The +, / and = characters are the reason the URL-safe alphabet exists.
• Comparing hex and Base64 of non-ASCII text from different tools without checking they used the same bytes (see above).

FAQ

Is Base64 shorter than hex?

For anything longer than a few bytes, yes: Base64 uses 4 characters for every 3 bytes (about 133% of the byte count) while hex uses 2 per byte (200%). For 1 byte, padded Base64 is longer (4 vs 2 characters), and for 2 and 4 bytes the two are the same length.

Is hex or Base64 more secure?

Neither. They are encodings, not encryption: anyone can reverse them without a key. If the data needs protecting, encrypt it first and then encode the ciphertext with whichever you prefer.

Why does Base64 sometimes end with = or ==?

Base64 works in groups of 3 bytes. If the last group has only 1 or 2 bytes, the output is padded with == or = so the length is a multiple of 4. For example, one byte M becomes TQ==. Hex never needs padding because every byte is exactly two characters.

Can I convert hex to Base64 directly?

Yes, by going through the bytes. The hex 4d616e is the three bytes 4d 61 6e, and the Base64 of those bytes is TWFu. For ASCII text you can see both in the hex encoder and the Base64 encoder.

Which is better for URLs?

Hex is always URL-safe. Standard Base64 is not, because of +, / and =; the URL-safe variant replaces the first two with - and _ and may drop the padding when the length is known. The Base64 encoder has a URL-safe option and a padding toggle.

Is hex the same as Base16?

Yes. RFC 4648 calls its Base 16 encoding the standard case-insensitive hex encoding, which it says may be referred to as base16 or hex. Its alphabet is the sixteen characters 0-9 and A-F.

Ready to try it? Encode text in the hex encoder and the Base64 encoder, move between binary and hex with the binary to hex converter, look up character codes in the ASCII converter, or read how binary maps to text in converting binary to text and back. Browse every encoder in the tools list.