Why padding is used in Base64 encoding? [duplicate

Question

Possible Duplicate:
Why does base64 encoding requires padding if the input length is not divisible by 3?

Quoting Wikipedia:

...these padding characters must then be discarded when decoding but still allow the calculation of the effective length of the unencoded text, when its input binary length would not be a multiple of 3 bytes. ...

But the calculation of length raw data can easily be done even if strip the padding character.

          |               Encoded
          |--------------------------------------
Raw Size  | Total Size | Real Size | Padding Size
1         | 4          | 2         | 2
2         | 4          | 3         | 1
3         | 4          | 4         | 0
4         | 8          | 6         | 2
5         | 8          | 7         | 1
6         | 8          | 8         | 0
7         | 12         | 10        | 2
8         | 12         | 11        | 1
9         | 12         | 12        | 0
10        | 16         | 14        | 2
.
.
.

So given the real encoded size (third column) you can always correctly guess what padded size would be:

PaddedSize = 4 * Ceil (RealSize / 4)

So in theory, there was no need of padding. Algorithm would have handled it. Considering that Base64 encoding is a popular industry standard, it is used in many applications and devices. These would have benefited from reduced encoded size. So question is, why padding is used in Base64 encoding?

Answer 1

Base64 is old and comes from days where there were limits on available RAM and CPU. Also writing software was more complex (today's SDKs and toolkits are much more user-friendly compared to the 80s or 90s) and Base64 had to run on many different system architectures.

That said, the developer could assume that the "real" data, after decoding the Base64 data, would be approximately n bytes long; which in turn allowed him/her to do better memory management.

Today it doesn't really matter anymore, but back in the day where resources were limited, this was a good thing.

Update: Never thought I'd get a downvote after 5 years, but now I can see the problem with my answer. I guess we all get older. ;) Dear visitors, enjoy this answer with a grain of salt.

Answer 2

It makes the encoded message an integer multiple of 4 characters. This might make writing a decoder slightly easier. You can load and process characters in blocks of 4 and convert them to 3 output characters, and the padding makes it easy to do this without going off the end of the string.

Answer 3

As you note, the end-padding is at most 2 bytes in length regardless of the length of the message, so it's not a really significant saving - more of a micro-optimization. If your application is both the producer and consumer of the encoding, you could strip out the padding, but it's not really worth the hassle.