How to Encode and Decode Base64: What It Is, What It Is Not, and When to Use It

You have seen Base64 even if you have never heard the name: the very long string after data:image/png;base64, in a web page, the token in an HTTP Authorization header, the blob of characters in a JSON payload that is clearly not meant to be read by humans. Base64 is the trick that lets binary data travel through systems that only tolerate plain text. Our Base64 encoder and decoder does both directions in your browser: type or paste text into the Plain text box and press Encode, or paste a Base64 string into the Base64 box and press Decode, then Copy Base64 (or the decoded text) with one click. Clear wipes both boxes when you are done. This guide explains how the encoding actually works, works a short example by hand, lists where it genuinely belongs — and states the one rule that matters more than all the rest: Base64 is not encryption.

How to Use the Tool

1. Encoding. Type or paste your text into the Plain text box and press Encode. The Base64 output appears in the second box, ready to copy. 2. Decoding. Paste a Base64 string into the Base64 box and press Decode; the original text appears in the first box. 3. Copy and clear. Copy Base64 grabs the encoded result without you having to select it by hand (a real convenience when the string is thousands of characters long), and Clear resets both boxes for the next round. Two behaviours are worth knowing up front. First, the decoder ignores whitespace automatically, so a string copied with line breaks from an email or a wrapped terminal window still decodes — the line breaks were never part of the data. Second, the tool handles Unicode properly: text is converted to UTF-8 bytes first, so accented letters, Chinese and Arabic characters, and emoji like ✓ and 🎉 encode and decode back byte-for-byte, where many older tools silently corrupt anything outside Latin-1. If your encoded text is destined for a URL or a pattern, our regex testing guide explains the pattern language that validates such strings, and our JSON guide covers the payloads Base64 most often travels inside.

How Base64 Actually Works

Base64 represents binary data using 64 safe characters: A–Z, a–z, 0–9, plus + and /. The engine works in groups of 3 bytes (24 bits), which it splits into 4 chunks of 6 bits; each 6-bit chunk maps to one of the 64 characters. That is the whole mechanism, and it explains the two facts people most often ask about. First, the output is about 33% longer than the input: every 3 input bytes become 4 output characters, so a 3,000-byte file becomes a 4,000-character string. Second, the = padding at the end: when the input length is not a multiple of 3, the final group is padded with one or two = characters to keep the output a multiple of 4 characters. The padding carries no data; it is just a marker saying where the real content ended, which is why one input gives one = and another gives two. Nothing is compressed, nothing is encrypted, and nothing is hidden — the mapping from 6-bit values to characters is public and fixed, so anyone can reverse it in one step with no key or password.

Worked Example: “Hello” by Hand

Take the five letters H-e-l-l-o. The first three bytes, “Hel,” regroup into four 6-bit chunks that map to the characters SGVs. The remaining two bytes, “lo,” fill only part of a final group, so they produce three characters plus one padding mark: bG8=. The full result is SGVsbG8= — eight characters for five input letters, exactly the 33%-longer rule plus one padding character, and the single = tells the decoder that the input had one byte left over in its final group (two bytes present, one missing). Try it in the tool: encode “Hello” and you get SGVsbG8=; decode SGVsbG8= and you get “Hello” back. Try a longer sentence and watch the output length track the input at roughly four-thirds. Try an emoji and watch it survive the round trip, because the UTF-8 step happens before the 6-bit regrouping. The by-hand version is worth doing once, because after it, no Base64 string ever looks mysterious again: it is just bytes, regrouped.

Where Base64 Genuinely Belongs

Base64 belongs wherever binary data must pass through a text-only channel. Embedding a small image directly in HTML or CSS as a data URL is the classic case — no separate file request, at the cost of a 33% larger payload, so it suits icons and tiny graphics, not photographs. Email attachments travel as MIME Base64 for the same reason: mail systems were built for text. HTTP Basic authentication sends “username:password” Base64-encoded in a header — encoded, not encrypted, which is why Basic auth is only ever acceptable over HTTPS, where the transport itself is encrypted. JSON APIs carry files as Base64 strings when a binary upload endpoint is not available, and SVG files embed images as data URIs. In every case the pattern is identical: the channel cannot carry raw bytes, so Base64 makes the bytes look like text, and the receiver decodes them back on arrival. If the channel can carry binary natively — a file upload, a database blob — Base64 is pure overhead, and you should skip it.

Common Mistakes

Treating Base64 as encryption or a password hash. This is the dangerous one, and the tool's own documentation states it plainly: Base64 protects data against mangling by text-only systems, not against prying eyes. Never encode a password, token, or secret “for security” — anyone who sees the string can decode it instantly. Using it on large files. A 33% size penalty on a multi-megabyte file is real bandwidth and real storage; reserve data URLs for small assets. Confusing standard and URL-safe Base64. The URL-safe variant replaces + with - and / with _ (and often drops the padding), so a standard decoder rejects it and vice versa — check which alphabet your source used before blaming the data. Pasting a truncated string. A string cut off mid-way is not decodable to the original; if the decoder reports an invalid character, the usual culprits are a stray character from copying, the URL-safe alphabet above, or truncation. Forgetting the UTF-8 step. Older tools that treat text as Latin-1 corrupt emoji and non-Latin scripts on the way in; this tool's UTF-8 conversion is what makes the round trip exact.

Limits Worth Knowing

This tool encodes and decodes text through the two boxes; it is not a file converter, so a binary file needs a file-oriented encoder rather than pasting its bytes as text. Very long strings work, but copying them in and out of a browser text box is the practical bottleneck — for bulk work, a command-line encoder is the right tool. And the privacy picture is simple: everything runs in your browser, so your text is not sent to a server for encoding — but the output is still just as readable to anyone you send it to as the input was, because encoding is not encryption, and that sentence bears repeating until it feels obvious.

Frequently Asked Questions

More guides from ToolNest