At some point in almost every developer's career, you run into a string that looks like complete gibberish - something like eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 - and realize you're looking at Base64 encoded data. It shows up in JWTs, in email headers, in data URLs embedded in CSS, in HTTP authentication headers, and in dozens of other places. Once you understand what it is and why it exists, it stops being mysterious.
Base64 is not encryption. It's not compression. It's simply a way to represent binary data using only printable text characters. That might sound like a narrow use case, but it turns out there are a surprising number of systems in computing that are designed to handle text but not arbitrary binary data, and Base64 is the standard solution for bridging that gap.
The Problem Base64 Solves
Most data in computing ultimately exists as binary: sequences of bytes with values from 0 to 255. When you have a system that can handle any byte value, you can transmit any file or data through it without problems. But many older protocols - email, HTTP headers, certain database fields, XML documents - were designed around ASCII text and can have trouble with binary data.
Email is the classic example. SMTP, the protocol that moves email between servers, was originally designed for plain ASCII text. If you tried to attach a JPEG image by stuffing raw binary bytes directly into an email, the bytes that happen to look like control characters or line endings would corrupt the message or get interpreted as protocol commands. Base64 solves this by converting the binary image data into a string of safe, printable characters that email systems handle without issues.
The same principle applies anywhere text-based systems need to carry binary payloads. JSON doesn't have a binary data type, so if you need to include an image or file in a JSON payload, you encode it as Base64 and put it in a string field. HTML data URLs work the same way - the image bytes get Base64-encoded and embedded directly in the HTML as a text string.
How the Encoding Actually Works
Base64 uses an alphabet of 64 characters: the 26 uppercase letters A through Z, the 26 lowercase letters a through z, the digits 0 through 9, and the symbols + and /. A 65th character, the equals sign =, is used for padding. Every combination of binary bytes can be represented using only these characters.
The encoding process works by taking three bytes of input (24 bits) at a time and splitting them into four groups of 6 bits each. Each 6-bit group maps to one character in the Base64 alphabet. Since 2 to the power of 6 is 64, there are exactly enough alphabet characters to cover every possible 6-bit value. If the input isn't a multiple of three bytes, padding characters fill out the final group.
This is why Base64 always makes data bigger. Three input bytes become four output characters, so Base64 encoded data is always about 33 percent larger than the original. For small pieces of data like tokens or IDs, this overhead is irrelevant. For large files, it adds up.
Decoding a JWT Token by Hand
JSON Web Tokens are a great practical example of Base64 in action. A JWT looks like three strings separated by dots. The first two parts are Base64URL encoded (a variant of Base64 that uses - and _ instead of + and / to be safe in URLs). If you take the first part of any JWT and decode it, you get the algorithm header. If you decode the second part, you get the payload containing the actual claims.
This is worth understanding because it means JWTs are not encrypted by default - the data inside them is just encoded. Anyone who has the token can read the payload. The signature (the third part) proves the token was issued by someone with the right key, but it doesn't hide the contents. Storing sensitive data in a JWT payload and assuming it's protected because it looks scrambled is a real security mistake that developers make.
Decoding a JWT is as simple as taking either of the first two parts, replacing any - with + and _ with /, padding it to a multiple of 4 characters with = signs, and running it through a Base64 decoder. Online tools handle all of this automatically.
Data URLs: Images Embedded Directly in Code
You might have seen CSS or HTML that includes something like src="data:image/png;base64,iVBOR..." followed by a very long string. That's a Base64-encoded image embedded directly in the source code. The browser decodes it and displays the image without making a separate HTTP request.
This technique makes sense for very small images like icons, loading spinners, or decorative elements that are used on almost every page of a site. By embedding them directly, you eliminate the latency of a separate request. The tradeoff is that the HTML or CSS file gets larger, the browser can't cache the image separately, and the source code becomes harder to read. For anything larger than a few kilobytes, a regular image file is almost always the better choice.
HTTP Basic Authentication
When a web server or API requires Basic authentication, the client sends the username and password encoded together as a Base64 string in the Authorization header. The format is username:password, combined with a colon, then Base64-encoded, giving something like Authorization: Basic dXNlcjpwYXNzd29yZA==.
This is another place where understanding Base64 prevents a security mistake. Basic auth credentials are not encrypted by this encoding - they're just encoded. Anyone who can see the HTTP header can decode the username and password in about two seconds. This is why Basic auth must always be used over HTTPS, where the TLS connection encrypts the headers before transmission. Over plain HTTP, Basic auth credentials are essentially sent in the clear.
Base64 vs Base64URL
Standard Base64 uses + and / as its 62nd and 63rd characters. These characters have special meaning in URLs: + means a space in form-encoded data, and / is a path separator. If you include standard Base64 in a URL query parameter without further encoding, the + and / characters can be misinterpreted.
Base64URL is a variant that replaces + with - and / with _ to produce strings that are safe to use in URLs and filenames without percent-encoding. JWTs use Base64URL. Many API tokens use Base64URL. When you're working with tokens that appear in URLs or headers, you'll often encounter this variant without it being explicitly labeled.
Using an Online Base64 Tool
For day-to-day development work, an online Base64 encoder and decoder is one of the most useful bookmarks you can have. Common uses include decoding a JWT to inspect its payload, encoding a test file for inclusion in a JSON request body, decoding an email attachment header to check the content type, verifying what's inside an authorization header during debugging, and encoding configuration values for storage in environment variables.
The process is straightforward: paste your text or data into the encoder, get the Base64 string back instantly. Or paste a Base64 string into the decoder and see the original content. Browser-based tools do this entirely client-side, which matters when you're working with tokens or credentials that shouldn't be sent to a third-party server.
Online Quick Tools includes a free Base64 encoder and decoder that runs entirely in your browser. No data is transmitted, no account is needed, and it handles both standard Base64 and the URL-safe variant.