This confusion is common enough to have its own category in vulnerability catalogues, and it persists because Base64 output looks exactly like what people imagine encrypted data looks like: a wall of letters and digits ending in an equals sign.
It is not scrambled. It is the same information written in a different alphabet, using rules published in a public document.
Three different jobs
Encoding changes how data is represented so it survives a journey. No key, no secret, fully reversible by anyone. Base64, URL encoding and HTML entities are all encodings.
Encryption makes data unreadable without a key. Reversible only by someone holding it. This is the one that provides confidentiality.
Hashing produces a fixed-length fingerprint and is deliberately not reversible. Used for verifying that something matches, not for storing something you need back.
The test that separates them: can I get the original back, and what do I need in order to do it? Nothing at all means encoding. A key means encryption. You cannot means hashing.
What Base64 is actually for
Plenty of systems were built to carry text and mishandle arbitrary bytes. Email is the historical example — it was designed for seven-bit characters, and a byte with the top bit set could be altered or dropped in transit.
Base64 takes any data and rewrites it using 64 characters that survive that journey unharmed: A–Z, a–z, 0–9, plus and slash. Every three bytes become four characters, which is where the 33% size increase comes from, and = pads the end when the input length is not a multiple of three.
So an email attachment is Base64. A data URI embedding an image in a stylesheet is Base64. A binary blob inside a JSON document is Base64, because JSON has no way to carry raw bytes.
All transport. None of it protection.
Where the confusion costs something
Credentials in configuration files. Encoded rather than encrypted, because the encoded form does not look like a password to someone glancing at the file. It looks like nothing to anyone reading it deliberately.
HTTP Basic authentication. The header is literally username:password in Base64. Over plain HTTP that is a password sent in public. The transport security comes entirely from TLS, and the encoding contributes none of it.
JWTs treated as opaque. The payload of a token is Base64 — readable by anyone holding it. Putting anything private in there is publishing it to whoever has the token.
Cookies and local storage. Encoding a user identifier does not stop the user editing it. Anything the client can decode, the client can change.
The variants
URL-safe Base64 swaps + and / — which mean something in a URL — for - and _, and usually drops the padding. JWTs use it, which is why pasting one into a standard decoder fails until the characters are swapped back.
MIME Base64 inserts a line break every 76 characters, so a string copied out of an email header arrives with newlines in it that some decoders reject.
Base64 without padding is common and decodes fine in most implementations and not all.
What to use instead
To keep something private, encrypt it — with a key, and store the key somewhere other than beside the data.
To store a password, hash it with an algorithm designed for the purpose. Not SHA-256 on its own, which is fast, and fast is the wrong property for password storage.
To check a file arrived intact, compare a checksum. To carry bytes through something that only handles text — that is Base64, and it is exactly the right tool.
The short version
Base64 is an alphabet change with no key and no secret. It exists so binary data survives text-only channels, and it hides nothing from anybody. If you would be uncomfortable printing the original on the page, encoding it changes nothing about that.