Base64 vs Hex: Size, Readability, When to Use

Use hex when a person will read, compare, or type the value; use Base64 when the bytes just need to travel as text in the smallest space. Both are encodings, not encryption, and both turn bytes into printable characters. They differ in size and readability. Hex spends two characters per byte (100% overhead). Base64 spends four characters per three bytes, about 33% overhead. Hex is what you see in hashes, color codes, and memory dumps because each byte stays visible as a pair of digits. Base64 is what you see in data URIs, JSON API fields, and email attachments because it is more compact. In RFC 4648 terms, hex is Base16 and Base64 uses a 64-character alphabet: the same idea with a bigger alphabet.

Hex doubles the data; Base64 grows it by one third, rounded up to a multiple of four characters. The formula for Base64 is 4 x ceil(n / 3) characters for n bytes, and for hex it is 2n. For 1,000 zero bytes that is 1,336 Base64 characters against 2,000 hex characters. The rounding matters for tiny inputs: the single byte "h" is 68 in hex (2 characters) but aA== in Base64 (4 characters, two of them padding), so hex is shorter for one byte and ties at two. The string "hello" is 68656c6c6f in hex (10 characters) and aGVsbG8= in Base64 (8 characters). From three bytes up, Base64 is never longer than hex, and the saving approaches one third of the hex length as data grows.

Hex is easier to inspect because one byte is always exactly two characters on a fixed boundary, while Base64 characters carry six bits each and straddle byte boundaries. In hex you can read a byte straight off the string: in 68656c6c6f, the pair 65 is the letter e. In Base64 no character lines up with a byte, so you cannot spot the third byte of aGVsbG8= by eye. That is why debuggers, hash listings, and packet dumps use hex. Hex is also case-insensitive (ff and FF are the same byte), while Base64 is case-sensitive, so lowercasing a Base64 string silently changes the data. If you mainly want to see what bytes are inside a value, convert it to hex; if you want to ship them, use Base64.

For non-ASCII text, both encodings first take the UTF-8 bytes, so the output depends on how many bytes each character needs. The string "héllo €" is 10 bytes in UTF-8, because é takes two and the euro sign takes three. In hex that is 68c3a96c6c6f20e282ac (20 characters); in Base64 it is aMOpbGxvIOKCrA== (16 characters). The 33% saving holds, with two padding characters because 10 is not a multiple of three. PixelTools' Base64 tool encodes through UTF-8 on purpose: the browser's plain btoa() only accepts characters up to U+00FF and throws on an emoji or the euro sign, so a tool built directly on it would fail on exactly this kind of input.

A strict Base64 decoder wants a standard alphabet, no whitespace, and correct padding, but real Base64 rarely arrives that clean, so PixelTools' decoder cleans it up first. It removes a leading data:...;base64, prefix, strips all whitespace (Base64 is commonly line-wrapped at 64 or 76 characters), maps the URL-safe characters - and _ to + and /, and restores missing = padding. RFC 4648 defines that URL-safe alphabet for use in URLs and file names. After cleanup, two checks produce different messages: characters outside the alphabet get an "isn't valid Base64" error, and a length that is one more than a multiple of four gets a "looks truncated" error, since no real Base64 string can have that length. Validity is checked first so garbage is not blamed on padding.

Choose by who or what consumes the value: humans pick hex, transports pick Base64. Use hex for checksums and hashes people compare, color values, byte-level debugging, and anything typed by hand. Use Base64 for embedding images in data URIs, binary fields in JSON, email attachments, and certificates in PEM files, where size and line-friendliness matter. Use URL-safe Base64 when the value sits in a URL or filename, because standard Base64 contains + and / which have special meaning there. Neither protects anything: both decode instantly with no key, so never treat either as a way to hide a secret. If you need confidentiality, encrypt first, then encode the ciphertext.

Base64 can hold any bytes, so a valid string may decode to something that is not text at all. A PNG, a PDF, or an encrypted blob is Base64-safe but not UTF-8-safe. PixelTools' decoder handles this explicitly: if the decoded bytes are not valid UTF-8, it reports that the value may be binary data such as an image or file, rather than showing replacement characters that look like corruption. The decoder uses a strict UTF-8 mode for this reason. The same rule applies to hex: converting a hex dump of a JPEG to text gives noise because the bytes were never characters. If your result looks like gibberish, the encoding probably worked and the content is simply binary.