Zum Hauptinhalt springen
ToolsByUs

Base64 to Hex

This converter decodes Base64 per RFC 4648 and re-encodes the same bytes as lowercase hexadecimal in your browser. Padding is handled, the URL-safe alphabet is accepted, and each byte maps to exactly two hex digits in output order: no prefixes, no separators, no upload.

Nur lokal

Die Oberfläche dieses Tools ist auf Englisch.

Die folgende Anleitung ist nur auf Englisch verfügbar.

Base64 to Hex explained

Base64 and hex are two spellings of the same bytes, and this converter moves between them: decode the Base64 exactly as RFC 4648 prescribes, then print each decoded byte as two lowercase hexadecimal digits. Nothing is reinterpreted in between — what you get is the byte sequence a hex editor would show you, character for character.

The interesting parts are the ones converters usually skip. Padding: the trailing = characters are handled, and input whose padding a pipeline stripped is accepted too. Alphabets: the standard A–Z a–z 0–9 + / set is decoded, and the URL-safe -_ variant defined by the same RFC is normalised before decoding. Byte order: preserved — one byte to two hex digits, high nibble first, always.

Like every tool on this site, the conversion runs in this browser tab: your text never leaves the machine, no request is made, and the Content-Security-Policy forbids the page from connecting anywhere. DevTools' Network panel staying empty while you convert is the proof, not the promise.

The reverse trip — bytes shown as hex, headed for a header or a token field — is what the sibling Hex to Base64 converter performs, with the same RFC 4648 alphabet and the same local processing.

If the grouping and the padding rules feel arbitrary, the guide on how Base64 actually works builds the whole mechanism from first principles in three short paragraphs.

How the conversion actually works

The conversion is two well-defined stages with nothing hidden between them, and each stage has a policy you can hold it to:

  • Normalise: whitespace, line breaks (MIME-wrapped input) and a leading ? are stripped; the URL-safe characters - and _ are mapped to + and / per RFC 4648's second alphabet.
  • Decode: the remaining characters map through the RFC 4648 alphabet — 4 characters to 3 bytes — with = padding consumed at the final quantum.
  • Validate: any character outside the alphabet is a named error with its position; a length of 1 more than a multiple of 4 is rejected outright, because a lone leftover character cannot form a byte honestly.
  • Emit: each byte becomes two lowercase hex digits, high nibble first, concatenated with no separators and no 0x prefix.

Padding and alphabets, precisely

RFC 4648's standard alphabet is A–Z, a–z, 0–9, + and /, with = padding the final quantum whenever the byte count is not a multiple of 3. The padding is meaningful — it disambiguates a final quantum of one byte from two — but the decoder also accepts unpadded input when the length makes the quantum unambiguous (lengths of 2 or 3 mod 4). A length of 1 mod 4 is invalid with or without padding — a single Base64 character cannot yield a whole byte — and is rejected rather than zero-filled.

The URL-safe variant defined by the same RFC — hyphen and underscore in place of plus and slash — is accepted and normalised, which matters in practice because JWTs and URL parameters are usually emitted unpadded and URL-safe. Mixing both alphabets in one input is rejected: a string containing both + and - has no coherent reading.

What the output looks like

The worked example below is the exact pair the Load sample button produces: the Base64 for "Hello world" rendered as 22 lowercase hex digits — two per byte, eleven bytes. The output is one continuous string — no 0x prefix, no spaces, no line breaks — because hex editors, dissectors and code all prefer the plain form. The length arithmetic: Base64 spends 4 characters per 3 bytes, hex spends 2 per byte, so hex comes out about 1.5 times the length of the unpadded Base64 — a property of the encodings, not of your data.

Byte order, stated once

Endianness never enters the picture, and it is worth saying why. Base64 decodes to a byte sequence, and a sequence has a natural order: first decoded byte first. The hex output mirrors that order exactly — byte n becomes the hex characters at positions 2n and 2n+1 — so the result is the same string a hex editor with no offsets would display. There is no word swapping, no little-endian reinterpretation, and no surprise when you diff against xxd.

Frequently asked questions

Does converting Base64 to hex upload my data anywhere?

No. Decoding and re-encoding happen inside this browser tab, in JavaScript that loaded with the page. There is no upload route in the page's code, and the site's Content-Security-Policy forbids outbound connections besides. To verify it yourself: open DevTools, clear or watch the Network panel, convert, and observe that no request appears — the tool works with the network cable unplugged.

Is the hex output uppercase or lowercase?

Lowercase, always — the same convention xxd and most hex editors print. Upper- and lowercase hex denote identical bytes, and a case-folding pass is lossless if a system demands capitals. The output carries no 0x prefix, separators or line breaks, so it pastes cleanly into code, dissectors and test fixtures.

Why is the hex string longer than the Base64 input?

Arithmetic of the two encodings: Base64 packs 3 bytes into 4 characters (about 33 percent overhead), while hex spends 2 characters on every byte (100 percent overhead). Divide the two and hex comes out roughly 1.5 times the length of unpadded Base64 for the same bytes. Neither encoding compresses anything — both are just alphabets over the same byte sequence.

Does the input need its = padding?

No. Padded input is decoded as-is, and padding that some pipeline stripped is reconstructed from the length — a length of 2 or 3 mod 4 identifies the final quantum unambiguously. The one length that is always invalid is 1 mod 4, with or without padding, because a single Base64 character cannot yield a whole byte; that input is rejected with a clear error, never guessed.

Is Base64-to-hex conversion a form of decryption?

No, and the distinction matters. Both Base64 and hex are encodings: reversible spellings of the same bytes with no key anywhere in the process. Anyone can decode either, including this page, offline. If your Base64 encoded ciphertext, converting it to hex changes the representation only — the data is exactly as readable, or as protected, as before.

What about URL-safe Base64 with - and _ characters?

Accepted and handled. RFC 4648 defines the URL-safe alphabet — hyphen for plus, underscore for slash — for contexts where + and / would be mangled, such as JWTs and URL path segments. The converter normalises those characters to the standard alphabet before decoding, so a token copied straight from an Authorization header works unmodified. Only a mix of both alphabets is refused.

ToolsByUs team · How we check our tools