Pular para o conteúdo principal
ToolsByUs

Hex to Base64

This converter re-encodes a hexadecimal string as standard Base64 in your browser. Input is case-insensitive, 0x prefixes and stray spacing are stripped, and output follows RFC 4648 with padding. Odd-length input is rejected outright: a missing nibble is never guessed at. Nothing is uploaded.

Só local

A interface desta ferramenta está em inglês.

O guia abaixo está disponível apenas em inglês.

Hex to Base64 explained

Hex is the programmer's spelling of bytes; Base64 is the wire's. This converter reads a hexadecimal string byte-pair by byte-pair and re-encodes the same bytes in the RFC 4648 standard alphabet, padding included — the exact string a proper encoder would emit for the underlying data, ready for a header, a config file or a token field.

Real-world hex is messy, and the converter meets it halfway: uppercase and lowercase digits are equal, 0x prefixes are stripped wherever they appear, and stray spacing — column dumps, spaced pairs, line breaks — is cleaned before parsing. What it will not do is guess. An odd number of hex digits means one nibble is missing somewhere, and the converter refuses rather than inventing where.

The conversion is entirely local, as everywhere on this site: your string is parsed and encoded in this browser tab, no request is made, and the page's Content-Security-Policy forbids outbound connections. The Network panel staying empty while you convert is the proof, checkable in seconds.

Checking the answer by hand is easy in the opposite direction: feed the result to the sibling Base64 to Hex converter and you should get your original hex string back, byte for byte.

Choosing between the two encodings in the first place is the subject of the site's Base64 vs hex comparison which compares size, readability and protocol fit without the tribal folklore.

How the conversion actually works

Base64's grouping rule does all the real work, and it is worth seeing once, because it explains both the length and the padding of everything this tool emits:

  • Clean: 0x and 0X prefixes are stripped, all whitespace is removed, and the remaining characters must be 0–9, a–f or A–F; anything else is a named error with its position.
  • Pair: every two hex digits become one byte — 48 is the byte 0x48, the letter H.
  • Group: bytes are taken three at a time; each triple's 24 bits split into four 6-bit values, and each value maps to one character of the RFC 4648 alphabet A–Z a–z 0–9 + /.
  • Pad: a final group of 1 or 2 bytes is completed with = characters so the output length is always a multiple of 4.

Input is cleaned, not judged

Hex in the wild arrives decorated. Hash digests come 0x-prefixed from some libraries; packet dumps arrive as columns of spaced pairs; documentation writes 48 65 6C with capitals while a log printed 48656c lowercase. All of that is the same bytes, so the converter treats it the same: prefixes and whitespace go, case stops mattering, and only after cleaning does the parser insist on hexadecimal digits. Mixed case within one string — 6C beside 6c — is fine, because the two spellings denote one nibble value.

Odd-length input: the explicit policy

A hex string of odd length cannot be parsed without guessing, because one digit is missing and either end is a plausible place for the loss. Prepending a zero and appending a zero produce different bytes — 0x48 versus 0x84 — so silently fixing the input would pick one meaning at random and hand you data that looks right. This converter's policy is to refuse: an odd-length input returns a named error stating the length, and the repair belongs to whoever knows where the digit actually went. It is the same refuse-rather-than-mangle rule the rest of this site's converters apply.

What the output looks like

The worked example below is the exact pair the Load sample button produces: a decorated hex string — 0x prefix, spaces, mixed case — arriving as five bytes spelling "Hello" and leaving as the standard Base64 SGVsbG8=, with one = because the final group carries two bytes instead of three. The output uses the standard alphabet, plus and slash included, not the URL-safe variant; if your destination mangles those two characters, RFC 4648's URL-safe alphabet is the documented substitution to apply afterwards.

Frequently asked questions

Does converting hex to Base64 upload my input anywhere?

No. The parsing and encoding run inside this browser tab, in code that shipped with the page. The page defines no upload endpoint, and its Content-Security-Policy blocks outbound connections, so exfiltration is structurally impossible rather than merely promised. DevTools makes the claim verifiable: open the Network panel, convert a string, and watch it record nothing at all.

Why is odd-length hex rejected instead of being fixed?

Because every fix is a guess with real consequences. An odd digit count means one nibble is missing, and padding a zero at the front versus the back yields different bytes — 48 versus 84 — so a silent repair would invent data that looks plausible. The converter returns a named error with the length, and you correct the source where the digit was actually lost.

Are uppercase letters, 0x prefixes and spaces really accepted?

Yes. Case is irrelevant — 4C and 4c are the same nibble — 0x and 0X prefixes are stripped even when repeated before every byte, and all whitespace is removed before parsing, so a pasted hex-dump column converts without pre-cleaning. After cleaning, only 0–9 and a–f or A–F are valid; a stray g or a comma is a named error with its position.

Does the output always include = padding?

Padding appears only when the byte count is not a multiple of three — one = for a two-byte remainder, two for a one-byte remainder — and the output length is always a multiple of 4. The = characters are part of RFC 4648, not noise: stripping them breaks decoders that rely on the length. This tool emits the padded standard form, matching what standard encoders produce.

Why is the Base64 output shorter than the hex input?

Encoding-overhead arithmetic: hex spends 2 characters per byte, Base64 spends 4 per 3. For the same bytes, hex runs at 100 percent overhead and Base64 at about 33 percent, so a 64-byte digest drops from 128 hex digits to 88 Base64 characters including padding. The data is identical throughout — only the alphabet's packing efficiency changed.

Is Base64 encoding a way to encrypt data?

No, and treating it as one is a genuine security mistake. Base64 is a reversible encoding with no key: anyone holding the string can decode it, offline, in milliseconds — this page does it without a network. It exists to move bytes through text-safe channels, not to protect them. If confidentiality matters, encrypt first, then Base64 the ciphertext for transport.

ToolsByUs team · How we check our tools