What is the difference between Base64 and hex encoding?
Base64 encodes binary data with 64 ASCII characters (A-Z, a-z, 0-9, + and /) and makes it about 33% larger. Hex (Base16) uses 16 characters (0-9 and a-f) and doubles the size, a 100% overhead. That makes Base64 the better choice for transport (email attachments, data URIs, JWT payloads) and hex the better choice for people reading bytes (memory dumps, hashes, cryptographic keys).
Both Base64 and hex (hexadecimal) encoding turn binary data into text, but they use different character sets, produce different output sizes and turn up in different places. Choosing the wrong one creates unnecessary overhead or compatibility problems.
Base64 vs hex in RFC 4648
Both encodings are defined in RFC 4648, and the difference comes down to how many bits each character carries. Hex, which the RFC calls Base 16, uses 16 characters and stores 4 bits in each one, so every byte becomes two characters and the output is always twice the size of the input. Base64 uses 64 characters and stores 6 bits in each, turning every 3 bytes into 4 characters. That makes Base64 about 1.33 times the input, rounded up to a multiple of 4 with = padding at the end. Hex never needs padding, and the RFC describes it as case-insensitive, while Base64 needs both upper and lower case letters to reach 64 symbols. Standard Base64 includes + and /, so for URLs and filenames the RFC defines base64url, which swaps them for - and _ and lets you drop the padding when the length is known. I use hex when I need to read bytes and Base64 when size matters.
| Property | Base64 | base64url | Hex (Base16) |
|---|---|---|---|
| RFC 4648 section | 4 | 5 | 8 |
| Alphabet | A-Z a-z 0-9 + / | A-Z a-z 0-9 - _ | 0-9 A-F (case-insensitive) |
| Bits per character | 6 | 6 | 4 |
| Bytes in, characters out | 3 in, 4 out | 3 in, 4 out | 1 in, 2 out |
| Padding | = or == when the input is not a multiple of 3 bytes | Can be skipped when the length is known | Never needed |
Output length for n bytes | 4 * ceil(n / 3) | ceil(4 * n / 3) without padding | 2 * n |
"f" (1 byte) | Zg== (4 chars) | Zg (2 chars, unpadded) | 66 (2 chars) |
"foobar" (6 bytes) | Zm9vYmFy (8 chars) | Zm9vYmFy (8 chars) | 666F6F626172 (12 chars) |
| 100,000 bytes | 133,336 chars | 133,334 chars, unpadded | 200,000 chars |
How each encoding works
Hexadecimal (hex) encoding
Hex represents each byte of binary data as two hexadecimal characters (0-9, a-f). One byte = 8 bits = two hex characters. Output uses only 16 characters: 0123456789abcdef.
Example: The text "Hi" in hex is 4869, "H" is byte 72 = 48 in hex, "i" is byte 105 = 69 in hex.
Size overhead: Hex output is exactly 2× the size of the input in bytes.
Base64 encoding
Base64 represents three bytes of binary data as four characters, using a 64-character alphabet (A-Z, a-z, 0-9, +, /). Three input bytes = four output characters.
Example: "Hi" in Base64 is SGk=.
Size overhead: Base64 output is approximately 1.33× (33% larger) than the input.
Efficiency comparison
| Property | Hex | Base64 |
|---|---|---|
| Character set | 16 chars (0-9, a-f) | 64 chars (A-Z, a-z, 0-9, +/) |
| Size overhead | 100% (2× input size) | ~33% (1.33× input size) |
| Output per byte | 2 chars | 1.33 chars |
| URL-safe by default | Yes | No (Base64url variant needed) |
| Human readability | Easy to read byte values | Harder to visually parse |
Base64 is more efficient because each character carries 6 bits instead of 4. Hex is simpler and easier to read when you're inspecting bytes.
When to use hex
Cryptographic hashes: MD5, SHA-1 and SHA-256 outputs are almost always shown as hex strings. 5f4dcc3b5aa765d61d8327deb882cf99 is the MD5 hash of the word "password" in hex: easy to compare, a fixed length and no padding. Our hash generator shows its output the same way.
Colour codes: CSS hex colours (#FF5733) are the hex encoding of the red, green and blue byte values.
IPv6 and MAC addresses: usually written in hex (00:1A:2B:3C:4D:5E).
Byte-level debugging: when you need to inspect exact byte values, hex makes each byte visually distinct as a two-character pair.
When to use Base64
Embedding binary data in text formats: JSON, XML and HTML can't hold raw binary, and Base64 is the standard way to embed images, files and other binary data in them.
HTTP authentication headers: Basic Auth credentials are Base64-encoded (RFC 7617).
JWT tokens: the three sections of a signed JWT are Base64url-encoded; how to decode a JWT safely shows them decoded.
Data URIs: embedding images directly in HTML or CSS, as in src="data:image/png;base64,iVBOR...". See how to Base64 encode an image in your browser.
API payloads: sending binary data (files, images) inside JSON bodies.
The most common confusion
Using hex when efficiency matters. For small strings and hashes, hex is fine. For embedding images or files, though, hex doubles the size: a 100 KB image becomes 200 KB of hex, while the same image in Base64 is about 133 KB. That difference is why Base64, not hex, became the standard for embedding binary data.
Base64url vs standard Base64
Standard Base64 uses + and /, which are special characters in URLs. Base64url replaces them with - and _ so the result can go in a URL without percent-encoding. JWTs use Base64url; standard binary embedding uses Base64. If a standard Base64 decoder gives you garbled output or an error on a JWT, replace - with + and _ with /, and add = padding until the length is a multiple of 4.
Frequently asked questions
Is hex or Base64 more secure?
Neither. Both are encoding schemes, not encryption, and anyone can reverse either format without a key. RFC 4648 says base encoding "does not provide any computational confidentiality". For secrecy, encrypt the data first (with AES, for example), then encode the ciphertext in Base64 or hex if it has to travel as text.
Why do cryptographic hashes use hex instead of Base64?
Consistency and readability. A hex hash always has twice as many characters as the hash has bytes: MD5 is 16 bytes (128 bits), so 32 hex characters. Hex is easy to compare by eye, and lowercase hex is the usual format across languages and tools. Base64 would be shorter (a 32-byte SHA-256 hash is 64 hex characters but 44 in Base64) but is less common for hashes in practice.
Can I convert between hex and Base64?
Yes. Both represent binary data, so you convert through the bytes: hex to bytes to Base64, or Base64 to bytes to hex. Our Base64 tool handles text and files in Base64; for hex you'd typically use a language function or script.
What encoding should I use for file uploads in APIs?
Base64 is the standard for embedding file content in JSON API bodies. Hex would work, but it makes the payload 50% larger than Base64 for the same file, which slows uploads for no benefit.
Why does Base64 sometimes end in =?
The = sign is padding that brings the output up to a multiple of 4 characters. Base64 works on 3-byte groups: when the last group has 1 byte the output ends in ==, with 2 bytes it ends in =, and when the input length is a multiple of 3 there is no padding at all. That is why "foobar" encodes to Zm9vYmFy with no = sign.
Is hex faster than Base64?
Both are simple table lookups, and for most applications the speed difference is too small to matter. The size difference is fixed: hex output is 50% larger than Base64 for the same input. Choose on size and readability, not speed.
The bottom line
Use hex for hashes, byte-level inspection and anywhere people need to read individual byte values. Use Base64 to embed binary data in text formats, HTTP headers and APIs, where size matters more than readability. Encode and decode Base64 with our free Base64 tool, and see what is Base64 encoding for how the encoding works step by step.
