About

Base64 encoding represents binary data using 64 ASCII characters (A - Z, a - z, 0 - 9, +, /) plus padding (=). Every 3 input bytes become 4 Base64 characters, inflating size by roughly 33%. Hexadecimal uses 16 symbols (0 - 9, A - F) and maps each byte to exactly 2 characters. Misinterpreting the encoding scheme during protocol debugging, firmware flashing, or cryptographic key exchange corrupts payloads silently. This tool decodes Base64 to its raw byte sequence, then emits each byte as a hex pair. It also reverses the process. It assumes standard Base64 (RFC 4648); URL-safe variants (- and _) should be replaced before conversion.

Formulas

Base64 encodes every group of 3 bytes (24 bits) into 4 printable characters. The conversion from a Base64 string to hex proceeds in two stages: decode, then format.

decode: B₆₄ → bytes = atob(B₆₄)

hexByte(b) = b.charCodeAt(0).toString(16).padStart(2, "0")

hex = n−1∑i=0 hexByte(bytes[i])

Where n is the byte length of the decoded data. Each byte value ranges from 0x00 to 0xFF. The output length in hex characters is exactly 2n.

The reverse operation parses hex pairs back to byte values and re-encodes via btoa:

byte(h) = parseInt(h, 16)

B₆₄ = btoa(String.fromCharCode(byte₀, byte₁, …, byte_n−1))

The output size ratio: Base64 is approximately 43 the size of raw bytes, while hex is exactly 2× the byte count.

Reference Data

ASCII Character	Decimal	Hex	Binary	Base64 Index
A	65	41	01000001	0
B	66	42	01000010	1
Z	90	5A	01011010	25
a	97	61	01100001	26
z	122	7A	01111010	51
0	48	30	00110000	52
9	57	39	00111001	61
+	43	2B	00101011	62
/	47	2F	00101111	63
=	61	3D	00111101	Padding
NUL	0	00	00000000	-
LF	10	0A	00001010	-
CR	13	0D	00001101	-
Space	32	20	00100000	-
DEL	127	7F	01111111	-
Å (byte 0xC5)	197	C5	11000101	-
μ (byte 0xB5)	181	B5	10110101	-
0xFF	255	FF	11111111	-
0x80	128	80	10000000	-
0x0F	15	0F	00001111	-

Frequently Asked Questions

Standard Base64 (RFC 4648) only accepts characters A - Z, a - z, 0-9, +, /, and = for padding. URL-safe Base64 replaces + with - and / with _. This tool expects standard Base64. Replace - with + and _ with / before converting. Also strip any line breaks or whitespace that MIME-encoded Base64 may contain.

The tool automatically strips common prefixes (0x, 0X, \x) and separators (spaces, colons, commas, dashes) before parsing. Input like 0x4F 0x4B or 4F:4B:21 is handled correctly. Ensure each byte is represented by exactly 2 hex digits after cleanup; an odd number of nibbles will trigger an error.

It handles any Base64 input including those representing binary payloads (images, certificates, encryption keys). The decoded bytes are converted to hex regardless of whether they represent printable ASCII. However, atob() in browsers uses Latin-1 encoding, so each decoded character maps to exactly one byte value from 0x00 to 0xFF.

The practical limit is governed by the browser's JavaScript string length and available memory. Most modern browsers handle strings up to several hundred megabytes. For inputs exceeding roughly 10 MB of Base64, performance may degrade. The tool processes conversion synchronously; for very large payloads, consider splitting the input into chunks externally.

Each byte requires exactly 2 hex characters. A 3-byte payload like "ABC" (bytes 0x41, 0x42, 0x43) produces 6 hex characters: 414243. Base64 encodes 3 bytes into 4 characters, so the Base64 string "QUJD" yields 6 hex digits. The ratio of hex length to decoded byte count is always 2:1. This is correct behavior, not inflation.

This tool converts between Base64 and hex at the byte level. If your hex represents UTF-8 encoded text (e.g., C3 A9 for é), converting to Base64 and then decoding with a UTF-8 aware decoder will recover the text. However, the hex output itself is raw byte pairs. The tool does not interpret encoding semantics beyond byte values.