This mistake shows up often enough that it deserves its own explanation, separate from the general encoding comparisons. Someone stores a password or an API key by running it through Base64 first, treats the result as if it were now protected, and moves on. It is not protected. It never was. Base64 provides no confidentiality whatsoever, and understanding exactly why is a good way to avoid repeating this mistake somewhere it actually matters.
Base64 is a reversible encoding scheme, not a cipher. It takes binary data and represents it using a fixed alphabet of 64 printable characters, which is useful for embedding binary data in text-based formats like JSON, URLs, or email. There is no key involved in the transformation, which means there is nothing an attacker needs to guess or steal to reverse it. Anyone, anywhere, with any programming language, can decode a Base64 string in one line of code:
atob("cGFzc3dvcmQxMjM=")
// "password123"That is not a vulnerability being exploited. That is the format working exactly as designed. Base64 was never intended to hide anything from anyone, so calling this a flaw would be like calling a phone book insecure because anyone can look up a name in it.
Part of the reason is visual: a Base64 string does not look like the original plaintext, so at a glance it feels like it has been obscured, the same instinct that makes ROT13 feel secretive even though it is trivially reversible too. Developers under time pressure sometimes reach for whatever transformation is already available in their language's standard library, and Base64 is almost always right there, one function call away, while a proper encryption setup requires generating and managing a key. The path of least resistance produces something that looks encoded enough to move on from, which is exactly the trap.
None of this means Base64 is a bad format. It is the correct choice whenever the goal is representation, not secrecy: embedding a small image directly in a stylesheet, attaching binary data to a JSON payload, or making sure a byte string survives being copied through a text-only channel without corruption. The distinction to hold onto is purpose. If the goal is "make this binary data safe to put in a text field," Base64 is right. If the goal is "make sure nobody else can read this value," it is the wrong tool every time, no exceptions.
If the actual requirement is confidentiality, use a real cipher like AES with a properly generated key, kept somewhere a secrets manager or environment variable can protect it, not baked into the encoding step. The Encrypt / Decrypt tool on this site supports both AES encryption and Base64 encoding side by side specifically so the difference is easy to see and easy to test, rather than something you have to take on faith.