What Base64 is for
Base64 writes any data, including images and other binary files, using only 64 safe characters: A to Z, a to z, 0 to 9, + and /. It takes 3 bytes at a time and writes them as 4 characters, so the result is about a third larger than the original.
That makes it useful wherever a system only carries plain text: email attachments (MIME), data URLs in HTML and CSS, binary values inside JSON or XML, HTTP Basic authentication headers, and the three parts of a JWT.
Base64 is an encoding, not encryption. Anyone can turn it back into the original with no key, so never use it to hide a password or a secret.
Why text with accents or emoji needs UTF-8
Base64 works on bytes, not on letters. Before text can be encoded, it has to be turned into bytes, and the choice of encoding changes the result. The browser function btoa() only understands the first 256 characters (Latin-1) and throws an error on anything else, such as a Chinese character or an emoji.
This tool converts text to UTF-8 bytes first and then encodes those, which is what almost every modern system expects. When you decode, the bytes are read as UTF-8 again, so Héllo 你好 👋 survives the round trip.
If the other side used a different encoding, you can say so. PowerShell's -EncodedCommand expects Base64 of UTF-16 little endian text, and some older systems use Latin-1.
Standard and URL-safe Base64
Standard Base64 uses + and /, and both have special meanings in URLs and file names. The URL-safe form from RFC 4648 swaps them for - and _, and often leaves off the = padding. JWTs, many API tokens and file-name-safe identifiers use it.
A decoder that expects one alphabet can reject the other. The Decode view here reads both and tells you which one it found, so you do not have to guess.