Quick answer: What is base64 encoding? It’s a method for writing binary data with 64 printable characters, so files and images can travel through text-only systems. Every three bytes become four characters, and equals signs pad the end when the input doesn’t divide evenly. Base64 is encoding, not encryption, so it never hides data.
You’ve probably met one without realizing it, and if you’ve asked yourself what is base64 encoding, you’re in good company. It’s a long string of letters and numbers, often ending in one or two equals signs, buried in a JSON response, an email header, or a stylesheet. The first reaction for many developers is suspicion, as if the text were scrambled on purpose. It isn’t. Base64 is a translation, and this guide walks through it with worked examples, tools you can use right away, and the places where it commonly breaks.
The fastest way to understand it is to test it. Paste a short phrase into the Base64 converter and compare the output with the original. The converter runs in your browser, so you can experiment without writing a script. If your goal is an image rather than text, the image to Base64 tool produces the string you’d place in an img tag or a CSS file. And when a base64 value sits inside a large API response, run the response through a JSON prettifier first, so you can find the field before you decode anything.
What is base64 encoding, exactly?
Computers store everything as bytes, which are numbers from 0 to 255. Many channels were built for printable characters only. Email transports, text editors, and some APIs can truncate or reject raw bytes. Base64 avoids that problem by using only characters that survive text channels intact.
The formal definition is in RFC 4648, the IETF standard for base encodings. It describes base 64 as a 65-character subset of US-ASCII. Sixty-four of those characters carry six bits each, and the equals sign handles padding. In practice, I think of base64 as a lookup. Take bytes, regroup their bits, and map each new group to a readable character.
What is base64 encoding used for?
You’ll meet base64 in a handful of recurring places. Email attachments use it so binary files can pass through mail servers that expect text. Data URIs use it to embed small images and fonts directly in HTML or CSS. HTTP Basic authentication uses it to package a username and password into a header. APIs use it to carry binary payloads inside JSON or XML. Certificates and keys use it to wrap their binary content in a text format that editors and tools can handle.
The common thread is the same in every case. The destination understands text, and the source data doesn’t.
The encoding has a long history in mail. Privacy-Enhanced Mail, proposed in RFC 989 in 1987, used a printable encoding built on the same idea. MIME, the standard behind modern email attachments, adopted a close variant and set a maximum line length of 76 characters. That limit explains why base64 blocks in raw email source are wrapped at fixed widths, and understanding it makes those line breaks far less mysterious.
How does base64 work?
To see what is base64 encoding doing at the bit level, start with groups of three bytes. Three bytes hold 24 bits, and those 24 bits split into four groups of six bits. Each six-bit value runs from 0 to 63, and each one selects a single character from the alphabet. Three bytes in, four characters out.
RFC 4648 uses the word Man as its worked example. The letters M, a, and n are the bytes 77, 97, and 110. In binary, those are 01001101, 01100001, and 01101110. Regroup the bits into six-bit chunks and you get 010011, 010110, 000101, and 101110. Those are the decimal values 19, 22, 5, and 46, which map to T, W, F, and u. So Man becomes TWFu. The table below lays out each step, which is the quickest way to check your understanding:
| Step | Six-bit group | Decimal value | Output character |
|---|---|---|---|
| First six bits | 010011 | 19 | T |
| Second six bits | 010110 | 22 | W |
| Third six bits | 000101 | 5 | F |
| Fourth six bits | 101110 | 46 | u |
Real input seldom divides evenly, so the last group needs padding. Most libraries use a lookup table with 64 entries, read the next three bytes, combine them into a 24-bit value, and emit four table lookups. When one byte is left over, the output ends with two characters and two equals signs. When two bytes are left over, it ends with three characters and one equals sign. The RFC’s test vectors show the rule clearly. The string f encodes as Zg==, fo encodes as Zm8=, and foobar encodes as Zm9vYmFy, which has no padding because six bytes form two complete groups.
Decoding is the same process run backward. Each block of four characters returns to three bytes, and the padding tells the decoder how many bytes the last block should produce. No key, salt, or randomness is involved, so the same input always gives the same output.
The base64 character set
The standard alphabet starts with uppercase A through Z, continues with lowercase a through z, then the digits 0 through 9, and ends with plus and slash. Position matters. A is 0, Z is 25, a is 26, z is 51, 0 is 52, 9 is 61, plus is 62, and slash is 63. Those positions are what every compliant encoder and decoder agree on, which is why the same string decodes correctly across languages.
Plus and slash cause the most practical trouble. Slash is a path separator, so a base64 value inside a URL path can break routing. Plus can turn into a space when it passes through a query string without encoding, and the decoder then produces corrupted output with no error message.
Not every system uses this alphabet. IMAP mailbox names, for example, use a different pair of symbols, and the Wikipedia article on Base64 lists a number of variants that swap characters or change line lengths. When a value won’t decode, the first question to ask is which variant produced it.
The URL-safe variant, often called base64url, replaces plus with hyphen and slash with underscore, and it commonly omits the padding. RFC 4648 says this variant should not be regarded as the same as plain base64, so don’t swap one for the other without checking the specification you’re following. JSON Web Tokens use the URL-safe form. If you’re putting a base64url value into a query string, paste the full URL into a URL parser to see how the parameters split before you debug the decoder.
Base64 size increase
Base64 makes data bigger, and that cost is predictable. Every three input bytes become four output characters, so the encoded text runs about 33% larger than the binary it represents. The Wikipedia article on Base64 describes the same overhead, noting that the encoding itself adds 33 percent, with about 4 percent more when line breaks are inserted at a typical length.
The arithmetic is easy to check. A 300 KB image becomes roughly 400 KB of text, because 300 multiplied by four and divided by three equals 400. Padding adds at most three characters. Knowing what is base64 encoding does to file size lets you decide whether inlining is worth it before you ship. Inline encoding saves a network round trip, which helps for small icons and fonts. For large or frequently cached files, serving the binary with the correct content type is usually the better choice.
The table below shows the effect at a few sizes. These are estimates based on the four-to-three ratio, before line breaks and padding are added.
| Original size | Approximate encoded size |
|---|---|
| 3 bytes | 4 characters |
| 1 KB | about 1.33 KB |
| 10 KB | about 13.3 KB |
| 300 KB | about 400 KB |
Base64 inside JSON and APIs
JSON only supports text, so APIs carry binary content as base64 strings in ordinary fields. That works well, but the field can become a long, unreadable value, and debugging gets harder when a large response prints on a single line. Formatting the response first, as the JSON prettifier from the introduction does, makes the structure visible. It won’t decode the value for you, so decoding is still a separate step.
When you decode, check what the field is supposed to contain. A base64 value might hold a PNG, a PDF, a serialized object, or plain text. Decoding under the wrong assumption produces output that looks like a bug in your code, even when the bytes arrived intact.
A quick way to confirm the decoded bytes are what you expect is to inspect the first few of them. A PNG file starts with the bytes 89 50 4E 47, which spell the characters PNG after the first byte. A PDF starts with the text %PDF. If the decoded output starts with something else, the problem is probably upstream, in how the value was produced or truncated, rather than in your decoder.
Base64 in PHP
PHP ships two functions, base64_encode() and base64_decode(). Encoding takes one line:
php
<?php
$encoded = base64_encode(‘This is an encoded string’);
echo $encoded; // VGhpcyBpcyBhbiBlbmNvZGVkIHN0cmluZw==
?>
Decoding has an option that tutorials often skip. Pass true as the second argument, and base64_decode() returns false when the input contains characters outside the alphabet. Without that flag, invalid characters are discarded silently, and corruption can stay hidden until it causes a larger failure.
php
<?php
$decoded = base64_decode($encoded, true);
if ($decoded === false) {
// Reject the input rather than storing damaged data.
}
?>
The base64_decode function page in the PHP manual documents both behaviors. For data from users, forms, or external services, I’d default to strict mode. Also replace spaces with plus signs before decoding when a value came through a URL or form, because plus signs often arrive as spaces and the manual’s user notes describe that problem with canvas data.
If you’re building a data URI in PHP, the same function does most of the work. Read the file, encode it, and prefix the result with its media type:
php
<?php $path = ‘logo.png’; $mime = mime_content_type($path); $dataUri = ‘data:’ . $mime . ‘;base64,’ . base64_encode(file_get_contents($path)); ?>
Keep the output for small assets only, since every byte of the image now lives inside the page markup.
Base64 in JavaScript
If you’re wondering what is base64 encoding in JavaScript terms, start with btoa() and atob(). They only handle strings whose characters fit into a single byte. Pass an emoji or any character outside the Latin-1 range to btoa() and it throws an error. The code looks correct, which makes this easy to miss.
The reliable pattern converts the string to UTF-8 bytes first, then encodes those bytes:
javascript
const bytes = new TextEncoder().encode(‘hello ✓’);
let binary = ”;
bytes.forEach((b) => { binary += String.fromCharCode(b); });
const encoded = btoa(binary);
The base64 encoding strings in JavaScript article on web.dev explains why this works, since JavaScript stores strings as UTF-16. It also warns about lone surrogates, which can make a decoder silently replace characters. Validate input that comes from outside your system before you encode or decode it.
What is base64 encoding in .NET?
In .NET, the equivalent methods are Convert.ToBase64String() and Convert.FromBase64String(). The Convert.ToBase64String method takes a byte array and returns the encoded string. Two details from the documentation matter in practice. The method expects the complete data in one array, so streams should use ToBase64Transform instead. And when line breaks are requested, .NET inserts one every 76 characters, which follows the MIME convention.
A minimal round trip looks like this. The string “Man” becomes the bytes 77, 97, and 110, which encode to TWFu, and decoding returns the original bytes:
csharp
byte[] bytes = System.Text.Encoding.UTF8.GetBytes(“Man”);
string encoded = Convert.ToBase64String(bytes); // TWFu
byte[] decoded = Convert.FromBase64String(encoded);
Most other languages offer the same operation under different names. Once you understand the bit regrouping, the APIs look familiar.
Can base64 be decrypted?
You don’t decrypt base64. You decode it. There’s no key and no secret, so anyone holding the string can recover the original bytes. People who ask what is base64 encoding often assume it adds some protection, and it doesn’t. RFC 4648 says it plainly in its security considerations: base encoding hides visible patterns but provides no computational confidentiality.
The stakes are highest with credentials. HTTP Basic authentication sends a header that base64 encodes a username and password joined by a colon. Anyone who reads that header can read the password. Keep authorization headers out of logs, and never treat an encoded value as a secret.
Here is a concrete example. The header Authorization: Basic dXNlcjpwYXNz carries the string user:pass. Paste dXNlcjpwYXNz into the Base64 converter and the password appears immediately. No key was needed, and that’s the whole point of the warning.
If you need confidentiality, use encryption. TLS protects data in transit, and a well-established cipher protects data at rest. If the ciphertext needs to be text, base64 can carry it afterward. The encoding is never the protection.
Base64 decode: a practical checklist
When a string won’t decode, check these things before blaming the library. Start with the alphabet. Standard base64 uses plus and slash, base64url uses hyphen and underscore, and mixing them causes many failures. Next check the length. Padded standard base64 has a length that’s a multiple of four, so a value that’s off by one or two characters usually means something was truncated or the padding was stripped.
Then look for whitespace and line breaks. Some formats ignore them, and stricter decoders reject them. The RFC says implementations must reject characters outside the base alphabet unless the referring specification says otherwise, so know which behavior your format expects. If the value came from a data URI, strip the prefix. A data URI looks like data:image/png;base64, followed by the payload, and only the part after the comma is base64.
Finally, decide what the output should be. Decoded data may be binary. Paste a value into the Base64 converter if you want to test a short string, and treat anything that isn’t clearly text as bytes rather than a string.
Two quick test strings are useful for checking your setup. TWFu should decode to Man, and Zg== should decode to f. If a converter or library returns anything else, the problem is in the tool or the way you’re feeding it data, not in the encoding itself. Testing with known values like these separates a broken pipeline from a misunderstanding of the format.
Common mistakes to avoid
Treating base64 as security is the most expensive mistake, and the earlier section explains why it fails. The second is using standard base64 in URLs without switching to the URL-safe variant, which breaks paths and mangles parameters. The third is double encoding, where two layers of code both encode the same value. Each pass adds about a third to the size, and the decoding path stops matching the encoding path.
Padding is the next trap. Some decoders require it and others infer it from length. If you join strings from different sources, check for padding first, because the pieces may decode differently once they’re concatenated. Also avoid storing decoded binary in text columns without thinking about it, since many databases and log pipelines mangle non-text bytes.
Logging deserves its own warning. A base64 field that looks harmless in a debug line can contain a full image, a password, or a session credential. Scrub those fields before the logs leave your server, and decide in advance which values are allowed to appear in plain text anywhere in your stack.
When base64 is the right tool
Base64 fits when binary data must pass through a text-only channel and the size cost is acceptable. Small icons, fonts, and configuration blobs are good examples. So are tokens and credentials that must fit inside a header or a JSON field, provided you protect them with real security measures.
It’s the wrong choice for large files that change often, because the size penalty and the caching behavior both work against you. It’s also the wrong choice for hiding information. If you find yourself using base64 to conceal a value, switch to encryption or access control. Asking whether base64 fits the job, rather than whether it’s convenient, usually produces a better design.
For large uploads, the usual alternative is to send the file as raw binary with the correct content type, or as a multipart form submission. Those approaches avoid the one-third size penalty and let servers stream the data instead of holding a huge string in memory. Base64 is still the right answer when the destination truly accepts only text, but it shouldn’t be the default for every file.
Key takeaways
- Remember what is base64 encoding at its core: it turns every three bytes of binary data into four printable ASCII characters.
- The standard alphabet uses plus and slash, while base64url swaps them for hyphen and underscore to stay safe in URLs.
- Encoded output is about 33% larger than the original, so plan for that growth in JSON, HTML, and CSS.
- Base64 is encoding, not encryption. Anyone can decode it, so never rely on it to hide secrets.
Frequently asked questions
What is base64 encoding in simple terms?
Base64 encoding is a way to write binary data using only 64 printable characters. It groups bytes into sets of three, splits them into six-bit pieces, and maps each piece to a letter, digit, plus, or slash. The result is text that survives systems built for text, such as email, JSON, and HTML.
Is base64 encryption?
No. Base64 is an encoding, and it has no secret key. Anyone who has the encoded string can decode it with a standard tool. If you need confidentiality, use proper encryption, and treat base64 only as a way to represent the output as text.
Can base64 be decrypted?
It can be decoded, which is a different operation. Decoding reverses the encoding using the public alphabet, so no password or key is required. That’s why base64 should never protect passwords, tokens, or personal data on its own.
Why does base64 end with equals signs?
Equals signs are padding. Base64 works on three-byte groups, and when the input doesn’t divide evenly, the encoder fills the final group and marks it with one or two equals signs. The decoder uses that marker to know how many bytes the last group should produce.
How much bigger does base64 make a file?
About 33% larger than the original binary, since every three bytes become four characters. Line breaks add roughly another 4%. A 300 KB file therefore becomes about 400 KB of encoded text.
What is the base64 character set?
The standard set contains A through Z, a through z, 0 through 9, plus, and slash, with equals signs used for padding. The URL-safe variant replaces plus and slash with hyphen and underscore, which keeps the output safe in URLs and filenames.
How do I base64 decode a string safely?
Confirm the alphabet, check that the length is valid, strip any data URI prefix, and remove stray whitespace if the decoder requires it. Use strict mode where the language offers it, so invalid characters cause an error instead of silent damage. Decide in advance whether the output is text or binary.
Does PHP have a built-in base64 function?
Yes. base64_encode() converts a string to base64, and base64_decode() reverses it. Passing true as the second argument to base64_decode() enables strict checking, which returns false when the input contains characters outside the alphabet.
Can I use base64 to embed an image in a web page?
Yes. A data URI combines a media type with the base64 payload, and browsers accept it in img tags and CSS. This works well for small images, but large files are usually better served as separate assets because the encoded text is bigger and harder to cache.
Is base64 the same as hex encoding?
No. Hex uses 16 symbols and represents each byte as two characters, which makes it larger than base64. Base64 uses 64 symbols and represents three bytes as four characters, which is more compact. Hex is easier to read byte by byte, while base64 is more efficient for transport.
Next steps
Once you grasp what is base64 encoding at the bit level, the rest gets simpler. Everything else is about variants, padding rules, and the places where values break in transit. Practice with a few short strings in the converter, then compare the results with what your language’s library returns. For more walkthroughs on data formats, the data format articles on the X2X Converter blog cover related conversions in more detail.