Hex to Base64
Take a fingerprint or a hash into the encoding an API expects
Hex Input
Base64 Output
Hex is what tools print, Base64 is what APIs want
Command-line tools overwhelmingly print hex. sha256sum, git rev-parse, openssl x509 -fingerprint, every debugger and every hex dump. Configuration formats and HTTP headers overwhelmingly want Base64, because it is a third shorter and fits in a header without wrapping. So you regularly have a value in one notation and need it in the other, and the two look nothing alike.
Paste the hex on the left in whatever shape you found it. That is the part most converters get wrong: a fingerprint from openssl arrives as 9F:7E:C8:EE:…, a debugger prints 0x9f7ec8ee, a protocol trace gives you 9f 7e c8 ee, and a lot of tools reject all three because they only accept bare digits. Every one of those is accepted here and the page says which shape it recognised.
Both encodings are defined in the same specification. RFC 4648 calls hex "Base16" and puts it alongside Base64 and Base32 as alternative ways of writing the same bytes as text. Hex costs 100% overhead and is readable a byte at a time; Base64 costs about 33% and is not. Neither is more correct — they are chosen for different jobs.
The byte count under the title is worth a glance every time. A hash has a fixed size, so 32 bytes means SHA-256 and 20 means SHA-1. If your 64-character hex string turns out to be 32 bytes, that is a SHA-256 and not, as the length might suggest at a glance, something twice as long.
Converting a value
- Paste the hex however you have it – Colons, dashes, spaces, line breaks and
0xprefixes are all stripped. Case does not matter. Sample loads a SHA-256 fingerprint in the exact shapeopensslprints it. - Check the byte count – It appears beside the title, with the digest named when the length matches a known one. A hex string always has an even number of digits, so an odd count means a character was lost in the copy — the page says so rather than silently dropping one.
- Choose the alphabet – Standard for headers, JSON fields and most APIs. URL-safe when it goes in a query string or a token —
+and/become-and_, and the padding is dropped. - Compare, if you have something to compare against – The box under the output takes the value you are checking and reports match or differ on the bytes, so the two notations stop mattering. It also prints both byte counts when they disagree.
A digest is bytes, not text — so convert the bytes, never the hex string as characters. Base64-encoding the 64-character text 9f7ec8ee… gives a 88-character result that is not the digest at all, just a picture of it, and it will never validate anywhere. This page always converts the bytes the hex represents, which is why 32 bytes of input give 44 characters of Base64 rather than 88.
A certificate fingerprint, ready to store
This is what openssl x509 -fingerprint -sha256 gives you, colons and all. It is a genuine SHA-256 — of the string subscriber payload, so you can reproduce it with printf 'subscriber payload' | sha256sum and check this page against your own terminal rather than taking it on trust.
# openssl x509 -fingerprint -sha256 9F:7E:C8:EE:E3:E9:8B:95:06:39: A8:3C:21:26:E0:77:27:30:8C:5A: C0:FB:E4:A4:D5:1A:EA:BE:EF:92: 51:37 # also accepted, same 32 bytes: # 0x9f7ec8ee… 9f 7e c8 ee…
# standard n37I7uPpi5UGOag8ISbgdycwjFrA ++Sk1Rrqvu+SUTc= # URL-safe — note + and / become - and _ n37I7uPpi5UGOag8ISbgdycwjFrA --Sk1Rrqvu-SUTc
When you need this
Writing a Subresource Integrity attribute
An SRI hash is sha384- followed by Base64. If your build pipeline emits hex — most checksum tools do — converting is the missing step, and getting it wrong means the browser refuses the script with a console message that does not explain why.
Pinning a certificate
HTTP Public Key Pinning, mobile pinning configs and several monitoring tools take a Base64 fingerprint, while everything that shows you a fingerprint prints hex with colons. This converts one to the other without hand-deleting 31 colons.
Sending a checksum in a header
The Content-MD5 header and the newer Digest header both carry Base64, per RFC 1864. Your build produced hex. Convert, then send. If you are checking a value that came back rather than sending one, Base64 to Hex is the direction you want.
Moving a key or IV into a config file
Key material is generated as hex by openssl rand -hex 32 and consumed as Base64 by a great many libraries. Converting here shows the byte count too, which is the fastest way to confirm you really do have the 32 bytes the algorithm requires and not 32 characters.
What it accepts and does
- Every shape hex arrives in.
AA:BB:CC,0xaabbcc,aa bb cc, wrapped across lines, upper or lower case. - Names the digest from its length. 16, 20, 28, 32, 48 and 64 bytes map to MD5, SHA-1, SHA-224, SHA-256, SHA-384 and SHA-512.
- Catches a truncated copy. An odd number of digits cannot be bytes, and the page says how many it counted instead of quietly dropping one.
- Standard, URL-safe and MIME output.
- Compares two values. Paste what you are checking against and it answers on the bytes, whichever notation each side is written in.
- Nothing is uploaded. Key material stays in the tab.
Questions that come up
It says my hex has an odd number of digits.
Each byte is exactly two hex digits, so a valid string always has an even count. An odd one means a character was lost — usually a copy that missed the first or last digit, or a leading zero that got stripped by something treating the value as a number. Go back to the source and take the whole thing.
Why is 64 hex characters only 44 characters of Base64?
Because 64 hex characters are 32 bytes, and Base64 writes 3 bytes as 4 characters — so 32 bytes need 44 characters including padding. Hex doubles the size, Base64 adds about a third; the Base64 form being shorter is the whole reason headers use it.
Should I convert the hex string or the bytes it represents?
The bytes, always, and this page does that. Encoding the hex text is a real mistake people make: it produces a valid Base64 string that decodes back to the characters 9f7ec8ee… rather than to the digest, and every system you send it to will reject it. The giveaway is length — a SHA-256 done correctly is 44 Base64 characters, done wrongly it is 88.
Do capital letters matter?
Not for the input — AA and aa are the same byte, and both are accepted. It matters a great deal for the Base64 output, where upper and lower case are different characters entirely, so never "tidy" the case of an encoded value.
Can I go back the other way?
Base64 to Hex, which also offers the colon-separated fingerprint shape for pasting into a pinning config.
Does this compute a hash for me?
No — it converts a hash you already have. Producing one from a file is a separate job for sha256sum, openssl dgst, or certutil -hashfile on Windows. This page starts once you have the digest and need it in a different notation.
Related tools
Worth reading
- RFC 4648 — Base16, Base32 and Base64 – One document covering all three, which is the clearest statement that they are alternatives
- W3C: Subresource Integrity – Specifies the base64 encoding of the digest, and why the algorithm prefix is part of the value