Base64 and hex are two spellings of the same bytes: Base64 packs 3 bytes into 4 characters, hex spends 2 characters on every byte. The Hex view is already on below: paste Base64 on the right and press Decode to see the bytes as hex pairs, the view you need when the payload is a key, a hash, a signature or a binary header rather than text. Hex on the left and Encode goes the other way.
The ratio is exact: 4 Base64 characters carry 3 bytes, and 3 bytes need 6 hex digits, so the hex is 1.5× as long as the unpadded Base64 (hex is 2× the byte count, Base64 1.33×). A 32-byte SHA-256 digest is 44 Base64 characters, the last one “=” padding, and 64 hex digits.
With Hex on, Decode never rejects binary: every byte becomes two hex digits, so a key or a hash shows up as hex where Text mode would have reported “Decoded bytes are not valid UTF-8, showing hex.” If Decode reports “That looks like Base64URL (it contains “-” or “_”). Turn on URL-safe to decode it.”, the value uses the URL-safe alphabet (JWT signatures always do), so turn on URL-safe and decode again.
Inspecting a Base64 value that is not text: a key or salt from a config file, a JWT signature, the sha256- hash in a Subresource Integrity attribute, or the first bytes of an unknown blob to identify its format from the magic number.
This page is a focused view of theBase64 Encode / Decode: Text, Images & Files, which has the full set of options.
Hex uses 2 characters per byte and Base64 4 characters per 3 bytes. 3 bytes are 6 hex digits or 4 Base64 characters, so hex is 1.5× the length of the unpadded Base64.
Yes. With Hex on, the left box is read as hex bytes (spaces, line breaks and 0x prefixes are ignored) and Encode produces the Base64.
No. Decoding runs in this tab with JavaScript; nothing is sent anywhere.