When using EncodeBase64, Xojo always add padding (using “=”) to get a multiple of 4 characters. But removing this padding, DecodeBase64 still decodes the string correctly.
Is there a specific reason why it does add those padding? As far as I know, all programming languages do not need the padding.
RFC 4648 says to pad it, rather than make any assumptions about how it will be consumed.
Implementations MUST include appropriate pad characters at the end of
encoded data unless the specification referring to this document
explicitly states otherwise.
As Anthony said, unless you control the decoder and know its behavior, you must follow the RFC, because someone following it in a “stricto sensu” could consider the missing pads a stream damage and fire an error condition for example. But if you “own” both ends, you can make concessions to yourself. Many, probably most, decoders are relaxed, they will accept missing pads, but you can’t trust random implementations at random endpoints.
Last week I had a really freaky problem with base64 encoded data. My new app again creates html, loads the html into a WKWebview and “prints” to PDF. After updating to 26.2 some (not all!) pictures were missing. The html looked fine in the browser. Direct creation from the browser also was okay.
I asked ChatGPT for help. One of the things to check was if base64 encoded data without linebreaks would work. And that indeed was the solution.
So if the RFC says to use padding you better do this.
As I said. You are just encoding, the decoders outside are not under your domains, and they may follow the RFC strict, not relaxed.
FWIW your problem about line breaks is ANOTHER issue, not related with the = pads.