How does encode and decode 64 figure out that the last few zeros are mere padding?

Question

https://learn.microsoft.com/en-us/dotnet/api/system.convert.tobase64string?view=net-5.0

It says

If an integral number of 3-byte groups does not exist, the remaining bytes are effectively padded with zeros to form a complete group. In this example, the value of the last byte is hexadecimal FF. The first 6 bits are equal to decimal 63, which corresponds to the base-64 digit "/" at the end of the output, and the next 2 bits are padded with zeros to yield decimal 48, which corresponds to the base-64 digit, "w". The last two 6-bit values are padding and correspond to the valueless padding character, "=".

Now,

Imagine that the byte array I send is

0

So, only one byte, namely 0

That one byte will be padded right into 000 right?

So now, we will have something like 0=== as the encoding because it takes 4 characters in base 64 encoding to encode 3 bytes.

Now, we gonna decode that.

How do we know that the original byte isn't 00, or 000, but just 0?

I must be missing something here.

Answer 1

So now, we will have something like 0=== as the encoding

3 padding characters is illegal. This would mean 6 bit plus padding.

And then 0 as a byte value is A in Base64, so it would be AA==.

So the first A has the first 6 bits of the 0 byte, the second A contributes the 2 remaining 0 bits for your byte, and then there are just 4 0 bits plus the padding left, not enough for a second byte.

How do we know that the original byte isn't 00, or 000, but just 0?

AA== has only 12 bits (6 bits per character) so it can only encode 1 Byte => 0

AAA= has 18 bits, enough for 2 bytes => 00

AAAA has 24 bits = 3 bytes => 000