Base64 is not encryption
Base64 expresses arbitrary bytes using only letters, digits and a couple of symbols. It exists so that binary data can travel through channels that were built for text: mail bodies, JSON fields, HTML attributes.
There is no key and no secret, so reversing it takes nothing at all. Putting a Base64 password in a config file does not hide it, it just adds one step of inconvenience. If something genuinely needs hiding, encrypt it or hand it to a secret manager.
When to use URL-safe
Standard Base64 uses + and /. Both mean something else inside an address, so a value dropped straight into a query string comes out mangled. The trailing = padding causes the same trouble.
URL-safe is the variant that fixes all three: + becomes -, / becomes _, and the padding is dropped. That is exactly the encoding used by the three parts of a JWT, and usually by OAuth authorisation codes and anything destined for a file name. Use URL-safe when the value goes into an address, standard everywhere else.
It gets longer
Base64 turns three bytes into four characters, so the output runs about 33% longer than the input. On top of that comes UTF-8: an emoji is four bytes, most CJK characters are three, so non-English text grows before the encoding even starts.
That growth matters when you inline an image as a data: URL. For a small icon, saving one request usually wins. For a photograph, the page now carries the whole file plus a third again, and the first render pays for it.
When decoding fails
Not Base64 almost always means the string was truncated, or quotes and line breaks came along for the ride. This tool already strips whitespace and accepts URL-safe characters, so if it still refuses, the string itself is incomplete.
Decodes to bytes, not text means the decoding worked but the result is not readable text. For a Base64 image or a zip file, that is the correct answer rather than an error.