メインコンテンツへ移動
ToolsByUs

Base64 vs Hex

Both are RFC 4648 text encodings of the same bytes — the difference is arithmetic and habitat. Hex doubles size but stays nibble-aligned and padding-free, so it owns checksums, MAC addresses and debugging. Base64 grows data by a third instead, so it owns bulk transport: MIME, JWTs, data URIs and cookies.

端末内で処理

以下の解説は英語のみでご覧いただけます。

Base64 vs Hex explained

The two encodings look interchangeable: both turn arbitrary bytes into printable text, both decode losslessly, and both are defined side by side in RFC 4648. They are not competitors so much as two spellings with different arithmetic — hexadecimal gives each byte two characters; base64 packs three bytes into four characters. Everything else on this page, from padding to habitat, follows from that arithmetic.

The numbers, precisely: hexadecimal is base16 — sixteen characters, 4 bits each — so one 8-bit byte becomes exactly two characters and payloads grow 100 percent. Base64 uses sixty-four characters, 6 bits each, and since the least common multiple of 8 and 6 is 24, three bytes become four characters: a 33 percent overhead, topped up with = padding whenever the input is not a multiple of three bytes.

This page turns that arithmetic into decisions: a side-by-side table, the size maths with a worked example, where each encoding has become the convention, and the footguns — padding, alphabet variants, case — that strict decoders reject. The converters below switch between them locally, nothing uploaded.

To see the size difference on your own payload, the Base64 to Hex converter re-encodes it locally and shows the doubled character count.

Slimming a hex string down for transport works the same way — the Hex to Base64 converter packs every three bytes into four characters, entirely in your browser.

Same bytes, two alphabets

Both encodings solve one problem: bytes are 8-bit values, but text transports — URLs, headers, XML, JSON, email — are happiest with printable ASCII. Hex draws on the sixteen characters 0-9 and a-f; base64 draws on A-Z, a-z, 0-9, + and /. Neither encrypts or compresses anything: both are publicly specified, keyless and instantly reversible, and a base64 string is transport safety, not security.

AspectBase64Hexadecimal
Alphabet64 chars: A-Z, a-z, 0-9, +, /16 chars: 0-9, a-f
Bits per character64
Size overhead+33% — 4 chars per 3 bytes+100% — 2 chars per byte
Padding= pads output to a multiple of 4None — a byte is always exactly 2 chars
VariantsURL-safe form swaps + and / for - and _Case-insensitive by convention
Canonical homesMIME, JWTs, data: URIs, cookiesChecksums, UUIDs, MAC addresses, hex dumps
StandardRFC 4648 sections 4 and 5RFC 4648 section 8

The arithmetic: a third versus a doubling

Hex is nibble-aligned: a byte splits into two 4-bit halves, each rendered as one character, so lengths are predictable — an n-byte value is always 2n characters, no padding, no edge cases. Base64 regroups bits into 6-bit chunks, and 24 bits is the first point where byte-world and base64-world align, so three bytes become four characters. One leftover byte pads to ==, two pad to a single =.

A worked pair makes the ratio concrete: the bytes for Hi are 48 69 in hex — four characters — and SGk= in base64 — also four characters, padding included. At real sizes the gap dominates: one megabyte of data becomes roughly 1.33 MB as padded base64 but exactly 2 MB as hex, which is why bulk transports standardised on base64 while short values stayed hex.

Where each encoding lives

Base64 owns bulk and transport. MIME uses it for email attachments, HTTP Basic authentication encodes credentials with it, JWTs base64url their header, payload and signature, data: URIs embed images and fonts directly in pages and stylesheets, and cookies carry base64url values because + and / misbehave in URLs and headers. Anywhere binary must survive a text-only pipe at minimum cost, base64 is the answer.

Hex owns the small and the human-checked. Cryptographic digests are printed as hex by convention — SHA-256 output, git commit identifiers — because fixed-width, unpadded, byte-aligned pairs are trivial to compare by eye or aloud. MAC addresses, the UUID text form and CSS colours like #RRGGBB are all hex, and hex editors, memory dumps and protocol debuggers use it because every byte reads as a self-contained unit.

Footguns and when to pick which

Base64's footguns are all in the alphabet. Standard and URL-safe variants differ in two characters and must never be mixed; padding is required by strict decoders yet stripped by JWT convention; output is case-sensitive; and MIME wraps lines at 76 characters. Hex has exactly one: case. Lowercase is the convention and uppercase appears in some tools, but mixing them is cosmetic — every strict decoder accepts either.

So: pick base64 when volume matters or a protocol demands it — attachments, tokens, embedded binary. Pick hex for short values that humans will compare, copy or debug: digests, identifiers, colours. The choice reverses constantly in real systems — a JWT arrives base64url and its SHA-256 fingerprint is hex — and the converters below handle the crossing in your browser.

Frequently asked questions

Which is more compact, base64 or hex?

Base64, always and exactly. Hex writes 2 characters per byte; base64 writes 4 characters per 3 bytes, so for the same input base64 output is two-thirds the length of hex. Concretely, one megabyte of data becomes about 1.33 MB as padded base64 versus exactly 2 MB as hex.

Is base64 encryption, or does it hide anything?

No — neither encoding provides secrecy. Both are keyless, publicly specified transformations that anyone can reverse instantly: a base64 string of a password decodes to that password everywhere. They solve transport, not confidentiality — binary data surviving a text-only channel. For secrecy you need encryption, after which the ciphertext may still be base64-encoded for transport.

Do the base64 and hex converters upload my data?

No. Encoding, decoding and conversion all run inside your browser tab; there is no upload endpoint, and the site's Content-Security-Policy allows network requests only to itself. Watch the DevTools Network panel while converting and you will see no outbound requests — payloads, including secrets pasted by mistake, never leave the tab.

Why are hashes and checksums shown in hex?

Convention hardened by mechanics. Hex output is fixed width, needs no padding, and each byte's two characters line up so comparisons and diffs align visually; an all-alphanumeric alphabet survives copy-paste, logs and CSVs. Every tool from openssl to git prints digests as hex, so hex is what humans learned to read.

What is base64url and when is it needed?

The URL-safe variant from RFC 4648 section 5: minus and underscore replace plus and slash, because + reads as a space in form encoding and / breaks path segments. JWTs, cookies and query parameters use it so tokens survive URLs untouched. Decoders should accept both alphabets; strict ones reject a mixed one.

Why does base64 sometimes end in = or ==?

Padding. Base64 output must be a multiple of four characters, and when the input is not a multiple of three bytes, one or two = characters pad the final group: one leftover byte adds ==, two add a single =. Hex never needs padding, since two characters per byte always divide evenly.

ToolsByUs team · How we check our tools