How this instrument works
Base64 is a way of representing arbitrary bytes using only 64 printable characters (A-Z, a-z, 0-9, plus + and /), which makes binary-ish data safe to paste into places built for plain text, like email bodies, JSON fields, URLs, or config files. It works by grouping the underlying bytes three at a time (24 bits), then splitting those 24 bits into four 6-bit chunks, and looking each 6-bit chunk up in the 64-character alphabet defined by RFC 4648. If the last group has only one or two bytes instead of three, the output is padded with one or two '=' characters so every decoder knows exactly where the real data ends.
Encoding text first turns it into bytes using UTF-8 (the standard way computers represent Unicode characters as bytes), then runs those bytes through the process above. Decoding reverses it: read the Base64 characters back into bytes, then interpret those bytes as UTF-8 text. Because the whole pipeline goes through UTF-8 rather than treating text as raw Latin-1 bytes, this instrument encodes and decodes accented letters, symbols, and other non-English characters correctly, not just plain ASCII.
Base64 is an encoding, not encryption — it doesn't require a key and provides no secrecy at all. Anyone can decode a Base64 string back to its original text in one step, so it's meant for making data transportable through text-only systems, never for hiding or protecting it. If you actually need to keep text private, look at a cipher like this site's Caesar Cipher Shifter or Vigenère Cipher Calculator instead (and be aware neither of those is secure by modern standards either — for real secrecy, use established encryption software, not a text-transform tool).
- Type or paste your input into the Text field.
- Choose Encode (text -> Base64) to convert plain text into a Base64 string, or Decode (Base64 -> text) to reverse it.
- Read Result for the output of whichever direction you picked.
- When decoding, paste the Base64 string exactly as given, including any trailing '=' padding characters.
- Switch Mode and paste the Result back in to round-trip a value and confirm it decodes to what you started with.
Worked example — encoding "Man" and "Hi", then decoding back
This is Base64's classic textbook example. "Man" is 3 ASCII bytes: M=0x4D, a=0x61, n=0x6E, which is 010011010110000101101110 in binary (24 bits exactly, so no padding is needed). Splitting that into four 6-bit chunks gives 010011, 010110, 000101, 101110, which are the decimal values 19, 22, 5, and 46. Counting from 0 through the Base64 alphabet (A=0 ... Z=25, a=26 ... z=51), those four values land on T, W, F, and u. "Man" encodes to TWFu.
"Hi" is only 2 bytes, so the 24-bit group isn't full. H=0x48 and i=0x69 give 16 bits total; those 16 bits split into two full 6-bit chunks plus 4 leftover bits, which get padded with two zero bits to form a third 6-bit chunk. Those three values (18, 6, and 36) are S, G, and k. Since a full 6-bit group's worth of data is missing to complete the usual set of four, a single '=' padding character is appended: "Hi" encodes to SGk=.
Decoding runs the same process backward. Switching Mode to Decode and entering aGVsbG8= strips the trailing '=', reads the remaining Base64 characters back into their 6-bit values, regroups those bits into bytes, and reads the bytes as UTF-8 text — recovering the original word "hello" exactly.
Questions
Is Base64 encoding the same as encryption?
No. Base64 is just a reversible representation of bytes using text-safe characters — there's no secret key, and anyone can decode a Base64 string back to its original content using nothing but the same standard alphabet this tool uses. If you need to actually hide information rather than just make it transportable as text, use a cipher or real encryption software instead; Base64 provides zero confidentiality.
Why does encoded text sometimes end with one or two '=' signs?
Base64 packs bytes three at a time into four output characters. When the input's length isn't a multiple of 3, the final group is short by one or two bytes, and '=' characters pad the output to keep every Base64 string a clean multiple of 4 characters long — one '=' for a group short by 1 byte, two '=' for a group short by 2 bytes. It's a bookkeeping marker, not part of the encoded data itself.
Can Base64 handle accented letters, emoji, or non-English text?
Yes, for any character representable in UTF-8. This tool converts your text to UTF-8 bytes before Base64-encoding it, and UTF-8 covers the full range of standard Unicode text, so accented letters and most non-Latin scripts round-trip correctly. It uses TextEncoder/TextDecoder rather than the older btoa/atob browser functions specifically because those older functions mishandle non-Latin1 characters without extra workarounds.
Why does decoding fail on some pasted Base64 strings?
Decoding requires every character to come from the standard 64-character Base64 alphabet (A-Z, a-z, 0-9, +, /) plus optional '=' padding. If a character was corrupted, wrapped with line breaks that got mangled, or the string is missing required '=' padding, decoding will fail or produce garbled output. Copy the Base64 string exactly as it was given to you, including any trailing '='.
What's the difference between Base64 and encoding text as hex?
Both represent raw bytes using printable text characters, but Base64 packs 3 bytes into 4 characters (using a 64-symbol alphabet), while hex uses 2 characters per byte (using a 16-symbol alphabet) — so Base64 output is roughly 33% larger than the original data, while hex output is exactly double. Hex is easier to read and edit byte-by-byte; Base64 is more compact. This site's Text-to-Hexadecimal Converter covers the hex version if that's what you need.