Hash Generator: Conversions

Convert hash bits to hex characters

How to convert hash bits to hex characters

To convert hash bits to hex characters, divide the digest bit length by four. Hexadecimal uses sixteen symbols, and each symbol encodes exactly four bits¹ - so the ratio is always exactly 4:1. Consequently, a 256-bit SHA-256 digest produces 64 hex characters, a 512-bit SHA-512 digest produces 128, and a 128-bit MD5 digest produces 32². You can reverse the calculation: multiply hex character count by four to recover the bit length.

Common hash bits to hex characters conversions

Why hash output length varies by algorithm

A hash algorithm's digest size is part of its definition. SHA-256 produces exactly 256 bits³ - always. SHA-512 produces exactly 512 bits. MD5 produces 128 bits. Consequently, the hex character count is deterministic: it is always the bit length divided by four¹. Understanding this relationship helps you validate that a hash value you have received is the correct length for the claimed algorithm. A 40-character string can only be a SHA-1 hash (160 bits Ă· 4 = 40). A 64-character string can only be SHA-256 (256 bits Ă· 4 = 64). A length mismatch immediately identifies a formatting error or algorithm mismatch.

Reading hex length as an algorithm clue

Use the character count before you compare a digest. If a field expected to contain SHA-256 has 32 characters, the issue is usually MD5, truncation, or a UI display problem. Fix the format first, then investigate algorithm behavior. This quick check is especially valuable when debugging integration failures between systems that use different hash algorithms, because a length mismatch immediately tells you which system is producing the wrong format without needing to inspect the actual hash computation code.

Checking length before comparing hashes

A length check costs almost nothing and catches many mistakes before you compare values. If a field expected to contain SHA-256 has 32 characters, the bug is probably MD5, truncation, or a UI display issue. Fix the format before investigating algorithm behavior. Adding a length assertion to your test suite takes one line of code and prevents an entire class of integration bugs where two systems silently disagree about which hash algorithm they are using.

You catch integration mistakes early by asserting the digest length in a test before any value comparison happens, because a wrong format usually means a wrong algorithm. A field that should hold SHA-256 but shows 32 characters is almost certainly MD5 or a truncated value. CapyToolkit shows hex lengths for MD5, SHA-1, SHA-256, and SHA-512 in your browser, so you can confirm the bit-to-character relationship without uploading input.

Hex vs Base64 encoding - when to use each

Hex encoding represents each byte as exactly two characters, using only the characters 0–9 and a–f. Base64 encoding represents each 6-bit group with one character⁴, using 64 symbols (A–Z, a–z, 0–9, +, /). Hex is longer - a 256-bit hash becomes 64 hex characters but only 44 Base64 characters⁴ - yet hex is more readable, more widely supported in CLI tools, and avoids the + and / characters that require escaping in URLs. Base64 is common in HTTP headers, JWT signatures, and binary protocols that need compact text representation. Yet hex is the default for most documentation, checksums, and security tools.

Practical format selection

Most systems expect hex. SHA-256 checksums on download pages, npm package integrity fields, and TLS certificate fingerprints all use hex by default. Base64 appears in JWT signatures (URL-safe Base64 without padding), SSH public key data, PEM-encoded certificates, and MIME email attachments. Building on this: if a system gives you a choice between hex and Base64 output, choose hex for human-readable contexts and Base64 for binary-protocol or compact-storage contexts. The underlying hash value is identical - only the encoding differs.

Keeping encoded values consistent across systems

Do not mix hex and Base64 in one contract unless every field name makes the encoding explicit. A SHA-256 value can be 64 hex characters or 44 Base64 characters, and both represent the same 32 bytes. The receiving system should never have to guess which text format it received. Document the encoding in your API schema or protocol specification, and add validation that rejects values with the wrong character set before they reach the comparison logic, because a hex string and a Base64 string that represent the same hash will always compare as different even though they encode identical bytes.

Identifying the hash algorithm from hex string length

Hex string length uniquely identifies the algorithm that produced a hash. A 32-character hex string is always MD5 (128 bits). A 40-character string is SHA-1 (160 bits). A 64-character string is SHA-256 (256 bits). A 128-character string is SHA-512 (512 bits)³. Checking the character count is a reliable first step when inspecting an unknown hash value from a log, database record, or API response.

This identification fails when a hash has been truncated. Some systems store only the first 8, 12, or 16 characters of a SHA-256 hash as a short content identifier. A 16-character string could be truncated SHA-256 or a full MD5. Context from the system that produced the value is the only way to distinguish them: examine the documentation or source code for the field you are inspecting.

From hex character count to storage and bandwidth estimates

From the hex character count, you can calculate storage requirements directly. Each hex character occupies one UTF-8 byte. A database column storing one million SHA-256 hex strings consumes exactly 64 MB for the hash values alone. Binary storage uses 32 bytes per hash: 32 MB total, half the hex size. Binary columns in MySQL (BINARY(32)), PostgreSQL (bytea), and SQLite (BLOB) all support fixed-length binary storage that avoids the space penalty of hex encoding.

For HTTP API responses returning hash values in JSON, each SHA-256 hex field adds 66 bytes to the response body including the surrounding quote characters. At one million API calls per day, that single field contributes approximately 63 MB of daily response traffic. Switching to binary transport or Base64 (44 characters plus quotes) reduces this to around 46 MB, a meaningful saving at high call volumes.

Try in the tool

Convert hash bits to base64 characters

How to convert hash bits to base64 characters

Base64 conversion starts with the raw byte count, then applies two round-up steps. First, calculate how many Base64 symbols the raw bytes need: each Base64 symbol encodes 6 bits¹, so divide the bit count by 6 and round up. Because Base64 pads output to the next multiple of four characters², apply a second round-up to the nearest multiple of four. Consequently, 256 bits becomes ceil(256/6)=43 symbols, then ceil(43/4) times 4 = 44 characters. You can use this tool to compute the Base64 length for any standard algorithm directly.

Common hash bits to base64 characters conversions

Why hash output length varies by algorithm

Base64 length starts with a fixed digest size. SHA-256 always produces 256 bits³; SHA-512 always produces 512 bits³; MD5 produces 128 bits⁴. Because the bit length is fixed, the Base64-encoded length is also deterministic for each algorithm. Consequently, you can verify whether a received hash value is the correct length: a valid SHA-256 Base64 hash is always exactly 44 characters. A 43-character value is unpadded SHA-256 (common in JWT signatures, which use Base64url without padding). A different length indicates the wrong algorithm or a truncated value.

Calculating padded length before comparison

Start from raw bytes, not from the hex string. Convert the bit length to bytes, round up to full Base64 groups, then apply the multiple-of-four padding rule. That sequence prevents off-by-one errors when a provider accepts both padded and unpadded signatures. Getting the padding wrong by even one character causes the comparison to fail silently, which is especially frustrating in webhook verification where the signature looks correct but the padding mismatch makes every request appear forged.

Checking padding before comparing Base64 hashes

Padding is part of the format when a system uses standard Base64. A 43-character value may be valid Base64url, but it is not valid padded Base64 for SHA-256. Decide whether your API accepts padded, unpadded, or both formats before you compare values. Write a test that sends both padded and unpadded versions of the same signature to confirm which format your server accepts, because this is a common source of integration failures that is much easier to catch in a test than to debug in production.

You avoid silent mismatches by deciding up front whether your API accepts padded, unpadded, or both Base64 formats before you compare signatures. A 43-character value may be valid Base64url, but it is not valid padded Base64 for SHA-256, and the distinction changes the comparison outcome. CapyToolkit shows Base64 and Base64url lengths for standard hash outputs, so you can confirm padding before trusting a comparison result.

Base64 encoding ratio and padding

Base64 encodes 3 bytes (24 bits) into 4 characters¹, a 4:3 character-to-byte ratio. For 32 bytes (SHA-256), the calculation is ceil(32/3) times 4 = 11 times 4 = 44 characters, with the last group padded with one "=" character². For SHA-512 (64 bytes): ceil(64/3) times 4 = 22 times 4 = 88 characters, with padding two characters because 64/3 = 21.33, so ceil(21.33) times 4 = 22 times 4 = 88. MD5 (16 bytes) produces 24 Base64 characters with padding. Base64url (used in JWTs) strips the = padding, producing 43 characters for SHA-256 and 86 for SHA-512. Building on this: checking the padding pattern tells you the unpadded byte length and therefore which algorithm produced the hash.

Practical format selection

Base64 encoding appears in JWT signatures, PEM certificate data, SSH public keys, and many HTTP header values because it is more compact than hex and avoids non-printable characters. Hex encoding produces longer strings but is more readable, supports CLI tooling (xxd, sha256sum), and avoids the + and / characters that require URL encoding. Yet Base64url (the JWT variant) replaces + with - and / with _, making it URL-safe without percent-encoding. When outputting hashes for HTTP headers, API responses, or compact storage, Base64 is the natural choice. For CLI output, checksums, and developer-facing diagnostics, hex is standard because every developer can read a hex dump without reaching for a decoder, which speeds up debugging during incident response.

JWT signature length and the Base64url encoding format

JWT tokens use Base64url encoding without padding for all three sections: header, payload, and signature⁵. The signature of an HS256 JWT (HMAC-SHA256) is always 43 characters: the 32-byte digest encodes to 44 Base64 characters, and the trailing = padding is stripped to produce 43⁵. An RS256 JWT uses an RSA-2048 signature of 256 bytes, encoding to 342 Base64url characters without padding. Checking the signature length is a reliable sanity test when debugging a JWT parsing failure.

Manually decoding a JWT signature for inspection requires reversing the Base64url substitution before calling a standard Base64 decoder: replace - with +, replace _ with /, then pad with = to a multiple of four characters. Most JWT libraries handle this automatically; understanding the step explains why calling atob() directly on a raw JWT signature fails without preprocessing.

Converting between hex and Base64 hash representations

Converting a hex-encoded hash to Base64 requires decoding the hex string to raw bytes first, then re-encoding those bytes in Base64; you cannot skip the intermediate byte representation because hex and Base64 are two different text encodings of the same underlying binary data, and no direct arithmetic shortcut exists between the two formats. In Python, the standard library handles the conversion: import base64, binascii; base64.b64encode(binascii.unhexlify(hex_string)).decode() returns the Base64 string directly. In Node.js, the Buffer class does the same work: Buffer.from(hexString, 'hex').toString('base64'). Both approaches go through the identical decode-then-encode pipeline under the hood, so the result is the same regardless of language.

A 64-character SHA-256 hex string always converts to a 44-character padded Base64 string, and a 40-character SHA-1 hex string converts to a 28-character padded Base64 string. For URL-safe output from Node.js, chain the substitution: Buffer.from(hexString, 'hex').toString('base64').replace(/\+/g, '-').replace(/\//g, '_').replace(/=/g, ''). The conversion is lossless: the original hex value recovers exactly by reversing the steps in order, which means you can freely switch between hex and Base64 representations without any data loss at any point in the process.

Keeping Base64 and Base64url separate

Do not treat Base64 and Base64url as interchangeable. Base64url replaces characters and usually removes padding, so a standard decoder may reject a JWT-style signature unless you restore padding first. Name fields explicitly when both formats appear in the same system. A practical rule: if the value travels in a URL path or query parameter, use Base64url; if it travels in a JSON body or HTTP header where percent-encoding is handled automatically, either format works but you should pick one and document it in your API specification.

Try in the tool