Encoding fundamentals

Base64 is an encoding, not encryption

Learn why Base64 values are readable, how standard and URL-safe alphabets differ, and what to use when security is the real requirement.

6 min readPublished 2026-07-22Updated 2026-07-22

What Base64 actually changes

Computers store text, images, and files as bytes. Some text-oriented transports are safer when those bytes are represented using a limited set of printable characters. Base64 takes groups of bytes and maps them to characters from a defined alphabet. The operation does not require a password and is designed to be reversed.

Because every three input bytes are represented by four characters, Base64 usually increases size by roughly one third before surrounding protocol overhead. Padding characters may appear at the end when the number of input bytes is not divisible by three. Removing padding can be valid in a protocol that defines how to restore it, but it does not make the value more secure.

Standard Base64 and Base64URL

Standard Base64 uses plus and slash in its alphabet. Those characters have special meanings in URLs and some form encodings, so Base64URL replaces them with hyphen and underscore. Base64URL values also commonly omit padding. JWT sections use this URL-safe form.

A decoder needs to know which alphabet and byte interpretation are expected. Text tools usually interpret decoded bytes as UTF-8. Arbitrary files may contain bytes that are not valid UTF-8 and should instead be handled as binary data with a known media type.

Why encoded secrets remain secrets in plain sight

An encoded API key, password, or authorization value is still the original credential in a reversible representation. Search tools and scanners routinely recognize Base64 patterns, and a person can decode them in seconds. Encoding a secret before committing it to source control or putting it in a URL does not reduce the exposure.

When confidentiality is required, use authenticated encryption with managed keys. When a receiver must confirm who created a message, use a suitable digital signature or message authentication code. When comparing integrity, use a cryptographic hash with a trustworthy reference. Each of these solves a different problem that Base64 does not attempt to solve.

A practical inspection workflow

Before decoding an unknown value, identify the context: HTTP Basic credentials, a JWT section, a data URL, an email attachment, or an application-specific field. Decode only in a trusted environment, inspect the media type or expected character encoding, and avoid automatically executing or opening decoded content.

After encoding, perform a round trip and compare the decoded bytes with the source. For text, include non-ASCII samples to confirm UTF-8 behavior. For a URL parameter, verify that the URL-safe alphabet and padding policy match the receiving application rather than applying substitutions by guesswork.

Primary references