A field that expects a Base64-encoded SHA-256 digest needs the digest bytes in that representation. Copying a hexadecimal hash into a text-to-Base64 encoder adds a different conversion: it encodes the visible hex characters. The resulting value can look plausible while carrying the wrong bytes.
This guide reproduces that mistake with a public text fixture. First confirm that your receiving format requires an ordinary SHA-256 digest, standard Base64 and padding; other constructions or variants need their own instructions.
Keep the digest separate from its printed form
SHA-256 produces 256 bits, or 32 bytes. Those bytes can be displayed as 64 hexadecimal characters or encoded directly as Base64. The MDN digest reference describes the returned byte buffer and distinguishes it from a hexadecimal display string.
For standard padded Base64, 32 bytes produce 44 characters, including one final equals sign. Encoding the 64 ASCII characters of a hex display instead produces 88 characters, including two padding signs. RFC 4648 defines the byte grouping, alphabet and padding behind those lengths.
The difference is the input to the encoding step: 32 digest bytes versus 64 bytes of hexadecimal text. Neither operation changes the SHA-256 algorithm, but they do not produce interchangeable field values.
Generate both representations from one text input
- Open the SHA-256 Generator and enter
parcel-314in Text to hash, without a final newline. - Choose SHA-256 under Algorithm.
- Choose Hexadecimal and Base64 under Output format. Leave Uppercase hex output unchecked.
- Select Generate hash and compare the two labelled results.
The hexadecimal result is:
062dbdb7ee7289aaca405295a39a4b0e47152a10040686cab67c2e23485f2528
The Base64 representation of those same digest bytes is:
Bi29t+5yiarKQFKVo5pLDkcVKhAEBobKtnwuI0hfJSg=
The input has 10 characters and 10 UTF-8 bytes; those input statistics are separate from the output lengths. Change Output format to Base64 before using Copy when you need only that value. The tool hashes entered text, rather than uploading a file or submitting an integration request.
Reproduce the extra encoding step deliberately
For a comparison, open the Base64 Encoder and Decoder. Choose Encode text to Base64, paste the complete lowercase hexadecimal result into Input, and leave both the URL-safe alphabet and output wrapping unchecked. Select Convert.
The deliberately wrong value for our digest requirement is:
MDYyZGJkYjdlZTcyODlhYWNhNDA1Mjk1YTM5YTRiMGU0NzE1MmExMDA0MDY4NmNhYjY3YzJlMjM0ODVmMjUyOA==
This is valid Base64 of the hexadecimal text, not the required Base64 of the digest bytes. Decoding it restores the original 64-character hex string. By contrast, decoding the correct value gives 32 bytes that are not intended to be read as a UTF-8 sentence.
The MDN btoa reference explains that Base64 operates on bytes. Printable hex characters are still data when passed to a text encoder; they are not automatically interpreted as pairs representing byte values.
Use lengths as a diagnostic clue
For this full-length SHA-256 example, a byte-oriented Base64 decoder should report 32 decoded bytes for the correct value and 64 for the extra-encoded value. Use a decoder that preserves bytes when comparing arbitrary digest data. A text decoder can replace sequences that are not valid text, so re-encoding its displayed characters is an unreliable check.
A 44-character string alone does not prove that SHA-256 was used, that the input matched, or that a receiving system accepted it. Likewise, 88 characters can have other legitimate meanings in another format. Compare the documented operation, exact fixture and decoded bytes together.
Repair the conversion chain at its source
Prefer generating the required Base64 directly from the digest byte buffer. If only a hexadecimal digest is available, a byte-aware implementation must parse each hex pair back into a byte before Base64 encoding; encoding the characters again repeats the mistake.
Keep the required alphabet, padding, prefixes and line breaks in your integration notes. If the representation is correct but the hash still differs, follow the separate text hash mismatch checklist for input bytes and line endings. If the contract requires a keyed operation, consult the SHA-256 versus HMAC guide before changing output formatting. A representation change cannot supply a missing authentication key.