<p>There are many types of Bitcoin addresses. Your example specifies (legacy) pay-to-pubkey-hash (P2PKH) address defined by <a href="https://en.bitcoin.it/Base58Check_encoding" rel="nofollow noreferrer">Base58 check encoding</a> and Wallet Import Format (WIF) which is also specified by <a href="https://en.bitcoin.it/Base58Check_encoding#Encoding_a_private_key" rel="nofollow noreferrer">base58 check</a></p>
<p>Base58 encoding treats the entire input payload as a big-endian big integer. Consider these alternate examples:</p>
<p>Input value: <code>bc</code> in ASCII: <code>0x62 0x63</code> (2 bytes) interpreted as a 2-byte int and encoded without leading zeros...</p>
<p>base 2: <code>110001001100011</code> (15 characters)</p>
<p>base 10: <code>25187</code> (5 characters)</p>
<p>base 16: <code>6263</code> (4 characters)</p>
<p>base 58: <code>8VG</code> (3 characters)</p>
<p>So going <em>forwards</em> we know that for this example it took 3 base58 characters to encode two bytes. Lets run it backwards and try minimum and maximum values:</p>
<p>base 58, maximum value with 3 characters <code>zzz</code> encodes three byte value: <code>0x02fa27</code></p>
<p>base 58, minimum value with 3 characters <code>211</code> encodes two byte value: <code>0x0d24</code></p>
<p>Conclusion:</p>
<p><strong>From this example alone we discover that we <em>can not</em> determine the length in bytes of the original value based just on the length in characters of the encoded string.</strong></p>
<h3>Bonus:</h3>
<p>Modern addresses are now encoded with bech32 and represent Segregated Witness programs. The bech32 spec is defined in <a href="https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki" rel="nofollow noreferrer">BIP173</a> and look like this: <code>bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4</code></p>
<p>bech32 encoding does not use interpretation as big integers and instead maps input bytes more directly to output characters:</p>
<blockquote>
<p>The data-part values:</p>
<ul>
<li>1 byte: the witness version</li>
<li>A conversion of the 2-to-40-byte witness program (as defined by BIP141) to base32:
<ul>
<li>Start with the bits of the witness program, most significant bit per byte first.</li>
<li>Re-arrange those bits into groups of 5, and pad with zeroes at the end if needed.</li>
<li>Translate those bits to characters using the table above.</li>
</ul>
</li>
</ul>
<p>As a result of the previous rules, addresses are always between 14 and
74 characters long, and their length modulo 8 cannot be 0, 3, or 5.
Version 0 witness addresses are always 42 or 62 characters, but
implementations MUST allow the use of any version.</p>
</blockquote>
<p>So in summary, with a bech32 address you <em>can</em> determine the length in bytes of the input value based on the length in characters of the encoded string:</p>
<p><strong>In bech32, each character represents 5 bits</strong></p>

CC BY-SA 4.0
2020-06-18T14:56:53.900Z
2020-06-18T20:00:26.663Z
2020-06-18T20:00:26.663Z
pinhead
<p>Bitcoin address is <code>25 bytes</code> long, <code>address = [Version Byte (1)][Hash 160 (20)][Checksum (4)]</code>  whereas number of characters in this string are 34.</p>
<p>Same with private key:  <code>32-byte</code> have almost 52 characters.</p>
<p>I want to know how can I <strong>map</strong> <code>number of characters</code> to the <code>size(Bytes)</code> of the bitcoin address(P2PKH)?</p>

CC BY-SA 4.0
2020-06-18T13:53:51.560Z
As its name implies the ripemd160 function will always output 20 bytes (160 bits). The P2PKH address will always be 25 bytes long.
Antoine Poinsot
CC BY-SA 4.0
2020-06-18T14:35:53.733Z
That’s not correct. Leading null bytes are sequestered, encoding to addresses down to 26 characters long.
Claris
CC BY-SA 4.0
2020-06-18T16:43:47.710Z
when you start to code then only you know. Number of characters depends on how the variable is declared, is it byte, hex or character.  For example, if you may think you declare privKey="1223a34fdcb...." in hex format but the program may interpret it as ascii character 1,2,2 etc. So, you have to double checked.
Cisco Mmu
<address>
Relation between bitcoin address/private keys size and number of characters?
Haseeb Saeed
# Relation between bitcoin address/private keys size and number of characters?

(Asked by: username_0 on 2020-06-18)

Bitcoin address is `25 bytes` long, `address = [Version Byte (1)][Hash 160 (20)][Checksum (4)]` whereas number of characters in this string are 34.

Same with private key: `32-byte` have almost 52 characters.

I want to know how can I **map** `number of characters` to the `size(Bytes)` of the bitcoin address(P2PKH)?

**Tags:** address

> **Comments:**
> **username_1**: As its name implies the ripemd160 function will always output 20 bytes (160 bits). The P2PKH address will always be 25 bytes long.  
> **username_2**: That’s not correct. Leading null bytes are sequestered, encoding to addresses down to 26 characters long.  
> **username_3**: when you start to code then only you know. Number of characters depends on how the variable is declared, is it byte, hex or character.  For example, if you may think you declare privKey="1223a34fdcb...." in hex format but the program may interpret it as ascii character 1,2,2 etc. So, you have to double checked.  

---

## 1 answers

### Answer by username_4 on 2020-06-18. Score: 2 | Accepted answer

There are many types of Bitcoin addresses. Your example specifies (legacy) pay-to-pubkey-hash (P2PKH) address defined by [Base58 check encoding](https://en.bitcoin.it/Base58Check_encoding) and Wallet Import Format (WIF) which is also specified by [base58 check](https://en.bitcoin.it/Base58Check_encoding#Encoding_a_private_key)

Base58 encoding treats the entire input payload as a big-endian big integer. Consider these alternate examples:

Input value: `bc` in ASCII: `0x62 0x63` (2 bytes) interpreted as a 2-byte int and encoded without leading zeros...

base 2: `110001001100011` (15 characters)

base 10: `25187` (5 characters)

base 16: `6263` (4 characters)

base 58: `8VG` (3 characters)

So going *forwards* we know that for this example it took 3 base58 characters to encode two bytes. Lets run it backwards and try minimum and maximum values:

base 58, maximum value with 3 characters `zzz` encodes three byte value: `0x02fa27`

base 58, minimum value with 3 characters `211` encodes two byte value: `0x0d24`

Conclusion:

**From this example alone we discover that we *can not* determine the length in bytes of the original value based just on the length in characters of the encoded string.**

### Bonus:

Modern addresses are now encoded with bech32 and represent Segregated Witness programs. The bech32 spec is defined in [BIP173](https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki) and look like this: `bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4`

bech32 encoding does not use interpretation as big integers and instead maps input bytes more directly to output characters:

> The data-part values:
>
> * 1 byte: the witness version
> * A conversion of the 2-to-40-byte witness program (as defined by BIP141) to base32:
>   + Start with the bits of the witness program, most significant bit per byte first.
>   + Re-arrange those bits into groups of 5, and pad with zeroes at the end if needed.
>   + Translate those bits to characters using the table above.
>
> As a result of the previous rules, addresses are always between 14 and
> 74 characters long, and their length modulo 8 cannot be 0, 3, or 5.
> Version 0 witness addresses are always 42 or 62 characters, but
> implementations MUST allow the use of any version.

So in summary, with a bech32 address you *can* determine the length in bytes of the input value based on the length in characters of the encoded string:

**In bech32, each character represents 5 bits**


---

