Base64 and hexadecimal are two reversible encodings of the same raw bytes, and converting between them only takes matching the strict input rules defined in RFC 4648: canonical padded Base64 on one side, two-digit lowercase hex on the other. The Base64 to Hex Converter handles that conversion entirely in your browser by validating the alphabet, byte boundaries, required padding, and zero pad bits before emitting exact lowercase hex or canonical padded Base64. Because both formats represent identical bytes, a successful round trip proves only that the input was well-formed — it does not validate semantics, signatures, or checksums, and it provides no secrecy. This cheat sheet gathers the rules you actually need in one place: what counts as canonical padded Base64, what counts as valid hex, how to spot the small gotchas (missing '=' padding, uppercase hex, odd number of hex digits, base64url), and exactly which steps to follow on the page. Keep it open while you work with protocol fixtures, cache keys, hash digests, signed payloads, and binary identifiers handed to you in whichever representation your current tool expects.
The Cheat Sheet at a Glance
Both formats encode raw bytes as printable ASCII text, so any byte sequence has exactly one canonical representation in each. The differences below are what makes one easier to read by eye or to embed in code than the other.
| Property | Base64 (RFC 4648) | Base16 Hex |
|---|---|---|
| Bits per character | 6 | 4 |
| Characters per byte | 4 characters per 3 bytes (~1.33) | 2 |
| Alphabet size | 64 | 16 |
| Character set | A–Z, a–z, 0–9, +, / | 0–9 and a–f (or A–F input) |
| Padding character | = (one or two at end) | None |
| Length signal | Trailing = tells you the final group is short | Always an even number of digits |
| Case sensitivity | Case is part of the alphabet | Input case-insensitive; output lowercase |
| Reversible to the same bytes | Yes | Yes |
| Provides secrecy or authentication | No | No |
| Variants that must NOT be silently accepted | base64url, MIME line-wrapped, unpadded | 0x prefixes, separators, odd trailing nibble |
The single most useful number to remember: 4 Base64 characters always represent 3 bytes, so (Base64 length ÷ 4) × 3, minus the count of '=' padding characters, gives the byte count. For hex, every 2 characters is exactly 1 byte.
Input Rules That Catch Every Mistake
The converter is intentionally strict on both sides because guessing the profile can hide real input errors. Before you paste anything, walk through this checklist:
- Base64 direction: the string must be a multiple of four characters, contain only A–Z, a–z, 0–9, +, /, and =, and the = characters may appear only at the very end. Whitespace, newlines, and base64url's hyphen or underscore are rejected.
- Hex direction: every byte must be exactly two characters from 0–9 and a–f (or A–F). No 0x prefix, no spaces, no colons, no underscores, no odd trailing digit. A lone "f" is incomplete and the parser will refuse it.
- Pad-bit check: when the final Base64 group has only one or two bytes, the remaining 6-bit or 12-bit slots must be zero. If they are not, the same bytes have a second non-canonical spelling, and the converter rejects it rather than silently picking one.
- Length check: the expected byte count is the first sanity check after a conversion. If the spec says 32 bytes, you should see 32 bytes — 64 hex chars, 44 Base64 chars with one '='.
These rules matter most when comparing signed data, protocol fixtures, cache keys, or exact serialized values — anywhere that "almost the same" is not the same.
Convert Base64 to Hex Step by Step
Use this procedure whenever a tool or spec hands you a Base64 string and the next step expects hex bytes.
- Confirm the input is standard RFC 4648 Base64: A–Z, a–z, 0–9, +, /, with '=' padding only at the end and no whitespace.
- Open the Base64 to Hex Converter and select the Base64 to hexadecimal direction.
- Paste the Base64 string exactly as received, with no leading or trailing whitespace and no line breaks.
- Run the conversion and read the byte length shown alongside the output. Compare it to the length the spec or source expects.
- Inspect the hex for leading 00 bytes — these are easy to lose when bytes are copied through other text tools.
- Copy the hex result and paste it into the next tool. If a downstream step expects 0x prefixes, spaces, or uppercase, add them at that step; the converter emits compact lowercase on purpose.
Convert Hex Back to Base64 Step by Step
Use this procedure when the source is hex bytes and the receiving tool expects canonical padded Base64.
- Strip any 0x prefix, whitespace, colons, or underscores from the hex input. The converter does not accept those formats.
- Confirm the remaining string has an even number of characters — every byte is exactly two hex digits.
- Open the converter and select the hexadecimal to Base64 direction.
- Paste the cleaned hex and run the conversion.
- Verify the Base64 output has length divisible by four and ends with 0, 1, or 2 equals signs. No padding mid-string is allowed.
- Copy the canonical Base64 string. If your next tool expects base64url or unpadded Base64, perform that transformation explicitly — do not assume the converter will do it for you.
Reading the RFC 4648 Test Vectors
RFC 4648 defines a small set of canonical test vectors that any compliant converter must reproduce. Working through one by hand is the fastest way to build intuition for the rules. Take the six-byte ASCII string "foobar":
- Bytes in hex: 66 6f 6f 62 61 72 (six bytes, twelve hex characters).
- Regrouped as a 48-bit stream: 01100110 01101111 01101111 01100010 01100001 01110010.
- Split into six-bit chunks: 011001 100110 111101 101111 011000 100110 000101 110010 — eight indices, eight Base64 characters.
- Map each index to the Base64 alphabet: 25→Z, 38→m, 61→9, 47→v, 24→Y, 38→m, 5→F, 50→y.
- Final Base64: Zm9vYmFy — no padding because six bytes is exactly two full 24-bit groups.
The full RFC 4648 vector set, which the converter is verified against, looks like this:
| Input bytes | Length (bytes) | Hex | Base64 |
|---|---|---|---|
| (empty) | 0 | (empty) | (empty) |
| f | 1 | 66 | Zg== |
| fo | 2 | 666f | Zm8= |
| foo | 3 | 666f6f | Zm9v |
| foob | 4 | 666f6f62 | Zm9vYg== |
| fooba | 5 | 666f6f6261 | Zm9vYmE= |
| foobar | 6 | 666f6f626172 | Zm9vYmFy |
To self-test a tool, paste any row's Base64 into the converter and confirm the hex matches; then paste the hex back and confirm the Base64 matches the canonical spelling exactly. For deeper background on canonical bytes and strict validation, see the guide on getting exact RFC 4648 bytes.
Safety Limits and What the Tool Will Not Do
Encoding is not encryption. Base64 and hex both expose exactly the same bytes as the input, so converting a credential, token, private key, or personal record does not protect it — keep sensitive values out of shared clipboards, screenshots, issue trackers, analytics fields, and untrusted browser sessions. The converter runs entirely in your browser, never uploads your input, and uses numeric byte arrays instead of text coercion to avoid silent truncation or character reinterpretation.
Three concrete limits govern what it will accept:
- Size cap: input is bounded at 500,000 decoded bytes to keep browser memory and output size predictable.
- No interpretation: the bytes are not parsed as UTF-8, numbers, certificates, images, JSON, cryptographic keys, checksums, or files. MIME headers, data-URL prefixes, line wrapping, and checksum trailers are not added.
- Exact output: malformed input produces a specific error with no partial result. Output is never silently truncated, the hex is always lowercase, and the Base64 is always standard padded RFC 4648.
For protocol fields and signed data, compare the final representation against the governing specification or official test vector rather than treating a successful conversion as semantic validation. Encoding only proves the bytes survived the round trip — the meaning of those bytes still has to be checked separately.