Base64 is not encryption. It is worth saying that first, because it is the most common misunderstanding about it. Base64 is an encoding, and anyone can decode it instantly - including this page. It provides no secrecy whatsoever.
What it does is make arbitrary data survive a journey through systems that only handle text. Email was designed for plain ASCII, so an image attachment is Base64-encoded to get through. HTTP headers cannot carry arbitrary bytes, so basic authentication credentials are Base64-encoded. Data URIs embed a whole file inside an HTML attribute the same way.
How it works, briefly
Base64 takes three bytes of input and rewrites them as four characters drawn from a 64-character alphabet: A-Z, a-z, 0-9 and two symbols. Because four characters carry three bytes, encoded data is about 33% larger than the original. That overhead is the price of safe transport.
When the input length is not divisible by three, the output is padded with one or two = signs. That padding is why Base64 strings so often end in an equals sign, and why a string whose length is not a multiple of four has usually been truncated somewhere.
URL-safe mode
Standard Base64 uses + and /, and both cause problems in a URL. A plus sign in a query string means a space, and a forward slash is a path separator. Put standard Base64 in a URL unencoded and it will be corrupted.
URL-safe mode substitutes - for + and _ for /, and drops the padding. This is the variant used in JSON Web Tokens, in OAuth state parameters, and in most modern APIs that pass encoded values through a URL. If you are decoding something that contains hyphens or underscores rather than plus signs and slashes, it is this variant - and the decoder here detects that automatically rather than making you specify it.
Text that is not plain English
A lot of Base64 tools break on accented characters, and the failure is not always obvious. The reason is that Base64 encodes bytes, not characters, so the text must be converted to bytes first - and if that conversion uses the wrong character set, the result decodes to garbage.
This tool encodes as UTF-8, which is the correct choice for essentially all modern use. café, 日本語 and emoji all round-trip correctly. If you decode something here and get scrambled characters, the likely explanation is that whatever encoded it used a different character set - a legacy system using Latin-1 is the usual culprit.
What to use it for, and what not to
Reasonable uses: inspecting the payload of a JWT to see what claims it carries, preparing a small image as a data URI, encoding a value that has to pass through a system that mangles special characters, decoding a configuration string from a service that hands them out encoded.
Not a reasonable use: hiding anything. Encoding a password in Base64 protects it from nobody. If the data needs to stay private, it needs real encryption, and Base64 is at most the step that comes after.