A base64 hex converter translates the same byte sequence between RFC 4648 Base64 and Base16 hexadecimal so a payload expressed in one form can be reproduced exactly in the other. Both encodings are reversible representations of raw bytes, not security transforms: Base64 packs three input bytes into four characters drawn from the 64-symbol alphabet of A–Z, a–z, 0–9, +, /, while hex writes each byte as two digits from 0–9 and a–f. A strict converter validates canonical padding, rejects non-zero pad bits, and never accepts base64url or MIME line wrapping under the standard profile, because guessing the profile can conceal input mistakes and break exact comparisons against signed data, protocol fixtures, or cache keys. The tool reads the canonical padded form on one side and emits the equivalent lowercase hex on the other, with byte boundaries held explicit so a single leading 0x00 byte is preserved instead of being dropped. Everything runs in the browser on a numeric byte array, so a single conversion is a deterministic round trip: paste the input, get the equivalent representation, and copy the exact output without reformatting.
The job is narrow on purpose. A specification hands you bytes in one representation, the next tool in the chain expects the other, and the question is which character set the source actually uses. Once that is settled, the conversion itself is a deterministic, reversible step that does not interpret the bytes as text, numbers, JSON, images, or files.
How the Two Encodings Compare
Base64 and hex both encode raw bytes, but they optimize for different things. Hex is human-friendly at the cost of size; Base64 is compact at the cost of having to explain padding, alphabets, and URL variants. A converter that handles both must hold the rules of each side independently, because the two representations are not interchangeable and the rules of one do not apply to the other.
| Property | RFC 4648 Base64 | Base16 hexadecimal |
|---|---|---|
| Alphabet size | 64 characters (A–Z, a–z, 0–9, +, /) | 16 characters (0–9, a–f, case-insensitive input) |
| Bits per character | 6 | 4 |
| Bytes per character group | 3 bytes produce 4 characters | 1 byte produces 2 characters |
| Padding | One or two trailing = characters to fill the 4-character quantum | None; missing digits are rejected |
| Output size vs input | About 4/3 of byte length, rounded up | Exactly 2× byte length |
| Canonical form | Length multiple of 4, required =, zero pad bits | Two digits per byte, no 0x, no separators, lowercase output |
That ratio is the reason Base64 dominates wherever compactness matters, while hex dominates wherever byte boundaries, leading zeros, or human inspection matter. The same three-byte input, the word foo, comes out as Zm9v in Base64 and as 666f6f in hex, and the underlying byte sequence 0x66 0x6f 0x6f is identical. That single example illustrates the entire API surface of a base64 hex converter: the same bytes can be written either way, and nothing in either representation hides the underlying value.
Convert Between Base64 and Hex
The Base64 to Hex Converter runs both directions in the browser, validates canonical form, and copies the exact output. Treat the procedure as three concrete decisions rather than a single click: which direction, which source profile, and how to verify the result.
- Pick the direction and identify the source profile. Choose Base64 → hex if the source is canonical padded Base64, or hex → Base64 if the source is a continuous run of two-digit bytes. Confirm the source actually uses standard RFC 4648 Base64, not base64url (which swaps + and / for - and _) and not MIME (which adds 76-character line wrapping). If the profile is wrong, convert it under its own rules first.
- Paste the canonical input with no extras. For Base64, the string must be a multiple of four characters, end with the required = or == padding, contain only A–Z, a–z, 0–9, +, /, and have no whitespace. For hex, paste a continuous run of two-digit bytes with no 0x prefix, no spaces, no colons, no underscores, and no odd trailing nibble; 0f is one byte, f alone is incomplete and will be rejected.
- Run the conversion, then verify the byte count and leading zeros. The output is the exact equivalent representation. Before copying, sanity-check the byte length: every pair of hex digits is one byte, and every four Base64 characters decode to three bytes (two with =, one with ==, and the converter rejects = on an otherwise complete final group). A leading 00 in hex is a real byte and must survive the round trip; if the source has it, the destination must too.
- Copy the exact converted value. The copy action returns the converted value alone, with no labels, prefixes, or commentary, so it can be pasted into the next tool without reformatting. If the input is malformed, the converter returns a specific error and no partial result, rather than silently emitting whatever the parser managed to consume.
Why Strict Canonical Validation Matters
Loose Base64 decoders will happily accept multiple spellings of the same byte sequence. Zm9v in canonical form, Zm9v=== with extra padding, and a hypothetical non-canonical form whose last six pad bits are non-zero can all decode to foo. That flexibility is fine for casual use, but it is dangerous when the bytes are a signature, a cache key, a JWT payload, or a value that is compared character-for-character against a specification. Two decoders that accept different canonical forms can produce the same bytes yet disagree on the textual representation, which breaks log greps, equality checks, and signed payload verification.
The Base64 to Hex Converter is intentionally strict: it decodes the Base64 input, then re-encodes the result and compares the two textual forms. Any mismatch — extra = padding, = on a complete final group, or non-zero pad bits — is rejected as a specific error with no partial output. The hex side is strict in the same way: two digits per byte, no separators, no 0x prefix, and a hard rejection of an odd trailing nibble. The result is that the same bytes always produce the same string, in either direction, which is what you need when the goal is to compare or store the value rather than just view it.
For the same reason, the converter does not silently accept base64url. A value such as Zm9v is identical in both profiles, but -m9v or Zm9v without padding is base64url, not standard Base64. If the source really is base64url, convert it under that profile first using a base64url-aware decoder, then feed the canonical padded output in here. Treating profile detection as a separate step makes the input mistake visible instead of hiding it behind a successful conversion.
Profiles You Must Identify First
Before opening the converter, decide which profile the source actually uses. The two are easy to confuse because the alphabets overlap, but they have different rules for two characters and different rules for padding. The spec, RFC 4648, defines both standard Base64 (section 4) and base64url (section 5) as distinct profiles, and many tools and protocols add their own line wrapping on top.
| Profile | Alphabet and separators | Padding | Used in |
|---|---|---|---|
| RFC 4648 standard Base64 | A–Z, a–z, 0–9, +, / | Required = to fill the 4-character group | Email attachments, generic protocol fields, this tool |
| base64url (RFC 4648 §5) | A–Z, a–z, 0–9, -, _ | Often omitted | JWT, JWS, URL paths, filenames |
| MIME Base64 | Standard alphabet plus \r\n line wrapping at 76 chars | Required = | Email bodies, some legacy encoders |
| Strict hex (Base16) | 0–9, a–f (or A–F) | None; two digits per byte | Hashes, binary IDs, hex dumps, this tool |
The practical rule: if the source has + or /, it is standard; if it has - or _, it is base64url; if it has line breaks, it is MIME-style. Strip wrapping and re-pad before feeding the value to the converter, and the rest of the workflow becomes a single deterministic step rather than a chain of guesswork.
Limits, Privacy, and What the Tool Will Not Do
The converter operates on a numeric byte array inside the browser and never uploads the input. That matters for values that should not leave the local machine, but it does not turn Base64 or hex into a security control. Both are reversible encodings, not encryption, hashing, signing, or access control. A credential, token, or private key copied through this tool is still the same secret it was on the way in, and the tool will not warn you about that. Keep sensitive values out of untrusted clipboards, logs, screenshots, and shared browser sessions, and treat any successful conversion as a syntax check, not as semantic validation of the payload.
Two hard limits shape what the tool can do. First, decoded input is capped at 500,000 bytes to keep browser memory and output size bounded. Second, the converter does not interpret the bytes: it does not add MIME headers, data: URLs, line wrapping, or checksum fields, and it does not parse the result as UTF-8, JSON, certificates, or images. If the surrounding application expects one of those containers, use the converted bytes as one layer and validate the container separately. Malformed input always returns a specific error with no partial result, so a failed paste is a clean signal to re-check the profile, the padding, and the digit count rather than a silent truncation.
When a Base64 Hex Converter Is the Right Tool
Use the Base64 to Hex Converter when a specification hands you bytes in one form and the next step expects the other, and the value is small enough to fit in 500,000 bytes. The classic situations are protocol field inspection, comparing signed payloads against a published test vector, building a hex literal from a Base64 sample, generating deterministic cache keys, and translating between test fixtures written in different conventions. For background on the kind of byte-level mistakes strict validation is meant to catch, the guide on how to convert base64 to hex without mistakes walks through the same canonical rules with additional examples.
For security-sensitive protocols, treat a successful conversion as necessary but not sufficient: the conversion proves the bytes round trip exactly between representations, and the actual semantics still need to match the governing specification or official test vector. The tool is a precise translator, not a validator, and the difference between those two roles is the difference between "the bytes are equal" and "the bytes mean what the protocol says they mean."