Free Base64 Encoder and Decoder
Encode or decode Base64 — plain text or files. UTF-8 safe. Everything runs locally in your browser.
How Base64 actually packs bytes into text
Base64 solves a specific problem: some systems (older email protocols, certain URL contexts, some JSON transports) only reliably handle plain text, but real-world data — images, PDFs, encrypted blobs — is arbitrary binary. Base64 bridges the gap by regrouping the data 3 bytes (24 bits) at a time and re-slicing those 24 bits into four 6-bit chunks. Each 6-bit chunk (a value from 0–63) maps to one character from a fixed 64-character alphabet — A–Z, a–z, 0–9, plus + and /. That's the entire trick, which is also why the output is consistently about a third larger than the input: 3 bytes always become exactly 4 text characters.
When the input length isn't a clean multiple of 3 bytes, the last group is padded with one or two = characters so the decoder knows exactly how many of the final 6-bit chunks are real data versus padding — that's the origin of the trailing = or == seen at the end of many Base64 strings.
Frequently Asked Questions
What is Base64 encoding used for?
Base64 converts binary data into plain ASCII text so it can travel through systems that only handle text — embedding images in CSS or HTML, sending attachments in email, storing binary blobs in JSON, or passing data in URLs.
Is Base64 encryption?
No. Base64 is an encoding, not encryption — anyone can decode it instantly. Never use Base64 to protect passwords or sensitive data.
Does this tool handle emoji and non-English characters?
Yes. Text is encoded as UTF-8 before Base64 conversion, so emoji, accented characters, and non-Latin scripts round-trip correctly.
Why is Base64 output about a third larger than the original?
Because every 3 bytes of input becomes exactly 4 text characters — a 4:3 expansion ratio, or about 33% larger. That overhead is the price of representing arbitrary binary data using only printable text characters.
Why do some Base64 strings end with = signs?
The encoding processes input in 3-byte groups; when the total length isn't a multiple of 3, the final group is short. One or two trailing "=" characters pad that last group so the decoder can tell exactly how many bytes of real data it contains.
Are my files uploaded anywhere?
No. Files are read and encoded entirely inside your browser using the FileReader API. Nothing is sent to a server.