How to Encode Text in Base64 (and Decode It Back)

October 17, 2026 • NOFYI Editorial Team

What Base64 Is

Base64 is a way to represent binary data or plain text using only a limited set of safe text characters. Instead of sending raw bytes that might be changed, cut off, or misread by a system that expects text, Base64 converts every three bytes of input into four characters drawn from a 64-character alphabet. The result looks like a long string of letters, digits, plus signs, slashes, and equals signs. It can be copied, pasted, stored in a text file, or placed in a message without losing information, because every character in the output is an ordinary text character.

The name Base64 comes from the size of its alphabet. It uses 64 different symbols to represent data. Those symbols are the uppercase letters A through Z, the lowercase letters a through z, the digits 0 through 9, the plus sign, and the slash. The equals sign is used as padding at the end when the input length is not a multiple of three bytes. Together, these 64 characters plus padding cover every possible byte value. That is the whole idea: take data that may contain any byte, and rewrite it using only characters that text systems handle reliably.

Base64 is used in many everyday places. Email systems originally handled only text, so attachments were encoded in Base64 before sending. Web pages sometimes embed small images as Base64 data URLs. Configuration files, tokens, and application programming interfaces often carry binary or structured data in Base64 form because it survives transport through text-based formats such as JSON and XML. When you see a long string that ends in one or two equals signs and contains only letters, digits, plus, and slash, there is a good chance you are looking at Base64.

The 64-Character Alphabet

The Base64 alphabet is worth learning because it explains both the output and the limits of the format. The first 26 values, 0 through 25, map to A through Z. The next 26 values, 26 through 51, map to a through z. The next 10 values, 52 through 61, map to 0 through 9. Value 62 maps to the plus sign, and value 63 maps to the slash. Each group of three input bytes is split into four 6-bit groups, and each 6-bit group selects one character from this alphabet. That is why Base64 output is always built from these characters and no others in its standard form.

There are variants of Base64 that change two characters to make the output safer in specific contexts. The URL-safe variant replaces the plus sign with a hyphen and the slash with an underscore, because plus and slash have special meanings in URLs. Some systems also omit padding. These variants are not interchangeable with standard Base64 unless the receiving system expects them. If you are copying a value from one tool to another, check whether the tool uses standard Base64 or the URL-safe variant. A single plus sign or slash in the wrong place can cause a decoder to reject the value or produce the wrong bytes.

Padding is the other detail to understand. Because Base64 processes input in groups of three bytes, an input whose length is not divisible by three needs padding. If one byte remains in the last group, the output ends with two equals signs. If two bytes remain, the output ends with one equals sign. If the input length is already a multiple of three, there is no padding. Padding tells the decoder how many bytes were in the final group, so it can recover the exact original length. Removing padding may work in some tolerant decoders, but keeping it is safer when a system expects standard Base64.

How to Encode Text Step by Step

Start with the exact text you want to encode. Check the spelling, spacing, capitalization, and punctuation, because encoding preserves every byte. A missing space, an extra line break, or a different capital letter will produce a different encoded string and decode to different text. Decide whether the text includes a trailing newline. Many tools add a newline when you press Enter, and that newline becomes part of the encoded output. If you want to encode only the visible words, make sure no hidden newline is included.

Next, choose a trustworthy encoder. You can use a built-in tool on your computer, a programming language library, or a well-known utility that runs locally. Avoid pasting sensitive text into an unknown website for encoding, because that site could log what you typed. For ordinary practice text, any standard encoder will do. Type or paste the text, confirm that the encoder is set to UTF-8 if it offers a character encoding option, and run the encoding. UTF-8 matters because characters outside basic English are represented as multiple bytes, and the encoder must use the same byte representation that the decoder will use.

Then copy the full encoded output, including any padding at the end. Do not trim the equals signs, and do not add line breaks inside the string unless the format you are using expects wrapped lines. Some email formats wrap Base64 at a fixed width, but most modern uses expect a single unbroken string. Paste the encoded value where it is needed, and keep the original text as well if you may need it later. Base64 is reversible, so you can always decode it, but keeping the original saves a step and avoids mistakes.

Finally, test the round trip. Decode the encoded string you just produced and compare the result with your original text. They should match exactly, character for character. If they do not match, check for a copied value that was cut off, padding that was removed, a plus sign that was changed to a space, or a line break that was added. A successful round trip is the simplest proof that the encoding step worked, and it is a habit worth keeping for any data you encode.

Worked Example: Hello Becomes SGVsbG8=

Take the simple word Hello as the worked example. It has five letters, each one byte in UTF-8. The encoder processes the input in groups of three bytes. The first group is Hel, and the second group is lo plus one missing byte that must be padded. The first group produces four Base64 characters. The second group produces three Base64 characters plus one padding character. The full result is SGVsbG8=, which is eight characters long. Notice the single equals sign at the end. That padding shows that the last group contained two bytes rather than three.

Reading the result character by character helps show why it is not a code or a secret. S, G, V, s, b, G, 8, and the padding sign are simply the 6-bit pieces of the letters in Hello, rewritten in the Base64 alphabet. Anyone with a standard decoder can reverse the process and recover Hello. There is no key, no password, and no hidden step. The transformation is public and deterministic. The same input always produces the same output when the same alphabet, character encoding, and padding rules are used. That predictability is useful for data transport, and it is exactly why Base64 must never be treated as protection.

Now decode SGVsbG8= back to Hello. A decoder reads the eight characters, removes the padding, converts each character back to its 6-bit value, regroups those bits into bytes, and then interprets those bytes as UTF-8 text. The result is Hello, with the capital H preserved. Try this round trip yourself with a local tool. Encode Hello, confirm that you get SGVsbG8=, then decode SGVsbG8= and confirm that you get Hello again. If a tool gives a different result for Hello, check whether it used a different character encoding, a URL-safe alphabet, or omitted padding. For standard Base64 with UTF-8, SGVsbG8= is the expected result.

You can extend the example to a short sentence to see how length changes. Encode a sentence of twelve characters and watch the output grow. The pattern remains the same: three input bytes become four output characters. Short inputs may show padding, and longer inputs may not. The key point is that encoding does not change the meaning of the text. It changes only the representation, so the text can travel safely through systems that expect plain text characters.

How to Decode Base64 Back

Decoding is the reverse process. Start with the complete encoded string. Remove any whitespace or line breaks that were added for display, but keep the padding at the end. Check that the string contains only characters from the Base64 alphabet plus padding. If it contains a space, a hyphen, an underscore, or another unexpected character, it may be a URL-safe variant, or it may have been damaged by copying. Do not guess. Confirm which variant the sender used before you decode.

Next, run the string through a decoder that you trust. Use a local tool or a standard library rather than an unknown website when the content could be private. The decoder will convert the characters back to bytes. If the decoder reports an error, the string may be truncated, may have missing padding, or may contain a character outside the alphabet. Fix the string rather than forcing the decoder to accept it, because a forced decode can produce the wrong bytes without warning.

Finally, interpret the decoded bytes as text in the correct character encoding, usually UTF-8. If the result looks like readable text, the decode succeeded. If the result looks like random symbols, the original data may have been binary rather than text, or the wrong character encoding was used. In that case, save the decoded bytes to a file and open the file with the program that understands its format, rather than trying to read it as plain text. Decoding is exact when the input is complete and the encoding rules are followed.

Size, Line Breaks, and Padding

Base64 output is larger than its input. Because three bytes become four characters, the output is about 33 percent larger than the input, before padding and line breaks are counted. A 3-byte input becomes 4 characters. A 300-byte input becomes about 400 characters. A 3-megabyte file becomes about 4 megabytes when encoded. This size increase is the cost of using only safe text characters. For short strings, the increase is trivial. For large files, it matters, and it is one reason why Base64 is best for small payloads, tokens, and short data rather than for large media files.

Line breaks are another practical detail. Older email standards wrapped Base64 output at 76 characters per line. Modern JSON, URLs, and configuration files usually expect a single line with no breaks. If you copy a wrapped value and paste it into a system that expects one line, the line breaks may be treated as errors or as part of the value. If you need to share a long Base64 string in a document, keep it as one unbroken string when the receiving system expects that form, or follow the wrapping rules of the format you are using.

Padding errors are also common. A missing equals sign can cause a strict decoder to fail. An extra equals sign can do the same. Some decoders accept missing padding and infer the correct length, but you should not rely on that tolerance. When you produce Base64, include the padding that the encoder generates. When you receive Base64, preserve the padding when you copy it. Treating padding as part of the value, not as decoration, prevents a whole class of avoidable errors.

Limitations of Base64

The most important limitation is that Base64 is not encryption. It does not use a key, it does not scramble data in a secret way, and it does not prevent anyone from reading the content. Anyone who sees a Base64 string can decode it in seconds with a free tool. That means Base64 must never be used to hide a password, a private key, a token, a personal message, or any other secret. If a value needs to stay private, it needs real encryption and proper access control, not encoding. Using Base64 as if it were encryption creates a false sense of security.

Base64 also does not prove that data is authentic or unchanged. It has no checksum, no signature, and no way to detect tampering. A person who can change a Base64 string can also re-encode modified data, and the result will still decode cleanly. If you need to know whether data came from a trusted source or was altered in transit, you need a hash, a message authentication code, or a digital signature. Encoding alone gives you transport safety, not trust.

Base64 does not compress data either. It makes data larger, not smaller. It does not remove duplicates, and it does not reduce storage or bandwidth. If you need smaller data, compress the data before encoding it, and remember that the recipient must decompress after decoding. Base64 also does not fix broken data. If the original bytes were corrupted before encoding, the encoded form will faithfully carry that corruption, and decoding will return the corrupted bytes. Encoding preserves whatever it is given, whether that is correct or not.

Common Mistakes

One common mistake is to treat Base64 as a way to hide secrets. People sometimes encode a password or an API key and paste it into a message, a screenshot, or a public file, believing that the encoding makes it unreadable. It does not. Anyone who recognizes the format can decode it. The safe rule is simple: never put a secret into Base64 and then share the encoded form as if it were safe. Keep secrets in a password manager, a vault, or another system designed for secrets.

Another mistake is to mix standard and URL-safe Base64. A standard string that contains a plus sign or a slash will break if it is placed in a URL without care, and a URL-safe string that contains a hyphen or underscore will fail in a decoder that expects standard Base64. The fix is to know which variant you need before you encode, and to convert explicitly if you must move between variants. Do not replace characters by hand unless you understand both alphabets and the padding rules.

A third mistake is to copy only part of a Base64 string. Because the string is a single encoded unit, cutting it off in the middle loses data and usually makes decoding fail. The same problem happens when a chat program, email program, or document wraps a long string and inserts line breaks or spaces. When you share Base64, copy the whole string from start to finish, including padding, and check that the pasted version has the same length as the original.

Frequently Asked Questions

Is Base64 encryption?

No. Base64 is encoding, not encryption. It changes how data is represented so it can travel as text, but it does not use a key and does not hide the content. Anyone can decode a Base64 string. Do not use it to protect passwords, tokens, keys, or private messages. Use real encryption and access control for anything that must stay secret.

Why does Base64 output end with equals signs?

Equals signs are padding. They show that the last group of input bytes was shorter than three bytes. One remaining byte produces two padding characters, and two remaining bytes produce one padding character. Padding lets the decoder recover the exact original length. Keep the padding when you copy or store a Base64 value.

Why is Base64 output about 33 percent larger?

Base64 represents three input bytes, which are 24 bits, as four 6-bit characters. That means four output characters carry the same information as three input bytes, so the output is four-thirds the size of the input. For short values the increase is small. For large files it is significant, which is why Base64 is best for short data.

Can I decode Base64 without the original tool?

Yes. Base64 is a public standard. Any standard decoder can decode a standard Base64 string, regardless of which tool created it, as long as you use the same alphabet and character encoding. The word Hello always encodes to SGVsbG8= in standard Base64 with UTF-8, and SGVsbG8= always decodes to Hello. That portability is one of its main strengths.

Conclusion

Base64 is a practical tool for carrying data as text. It uses a 64-character alphabet to turn any bytes into safe characters, it adds padding when the input length needs it, and it grows the data by about one third. The worked example shows the round trip clearly: Hello encodes to SGVsbG8=, and SGVsbG8= decodes to Hello. Use Base64 when you need text-safe transport, test the round trip, and remember its limits. It is not encryption, it does not prove authenticity, and it must never be used to hide secrets. Used correctly, it is a simple and reliable way to move data between systems that expect text.