Base64 Encode / Decode
Encode text to Base64 or decode Base64 back to text — UTF-8 safe, entirely in your browser.
1,277 views
How It Works
Base64 turns binary data into plain text using an alphabet of 64 printable characters: A–Z, a–z, 0–9, plus + and / (64 symbols is exactly 2⁶, which is why it's called Base64). The encoder reads the input 3 bytes (24 bits) at a time, splits those 24 bits into four 6-bit chunks, and maps each 6-bit chunk to one character from the alphabet — so 3 bytes of binary always become exactly 4 characters of text. If the input length isn't a clean multiple of 3, the last group is padded with one or two = characters to keep the output length a multiple of 4.
Concretely: the three bytes spelling "Man" (77, 97, 110 — 01001101 01100001 01101110 in binary) get regrouped into four 6-bit chunks (010011, 010110, 000101, 101110), each mapped to a character, producing TWFu. Because every 3 input bytes always expand to 4 output characters, Base64-encoded data is reliably about 33% larger than the original — a 300 KB image becomes roughly a 400 KB Base64 string, which matters when embedding images as data: URIs or attaching binary files inside JSON or email.
This tool handles Unicode correctly by UTF-8-encoding the text first, so multi-byte characters and emoji ("çğü 😀") round-trip intact — a naive JavaScript btoa() call throws an error on these because it expects one byte per character. Everything runs locally in your browser; nothing you type is sent anywhere.
Base64 shows up constantly in places most people never notice: an HTML <img src="data:image/png;base64,..."> tag embeds an entire image inline instead of linking to a file; the Authorization: Basic HTTP header carries a Base64-encoded "username:password" string (formatting only, not protection — TLS is what actually keeps it private in transit); email attachments have been Base64-encoded since the original MIME standard, because SMTP was designed to move 7-bit text, not raw binary; and JSON Web Tokens (JWTs) use the URL-safe variant to pack a signed binary structure into three dot-separated text segments.
What to Know
- Base64 is not encryption — it's a reversible, publicly-known representation with zero secrecy. Anyone can decode it instantly with the same alphabet; it exists purely to make binary data safe to carry through text-only channels (email MIME attachments, data URIs, JSON fields, HTTP Basic-Auth headers), never to hide content.
- URL-safe variant: because
+and/have special meaning in URLs, a "URL-safe" Base64 alphabet swaps them for-and_and often drops the=padding. This tool decodes both variants automatically. - Size cost is fixed and predictable: the ~33% expansion (4/3 ratio) is exact for the payload itself — it's why APIs that accept raw binary uploads are usually more bandwidth-efficient than ones that require Base64-wrapped JSON bodies.
- Padding tells you the remainder: one
=means the original data length was 2 bytes over a multiple of 3; two=means 1 byte over. No padding at all means the input was an exact multiple of 3 bytes.
Frequently Asked Questions
Why does my decoded output look garbled?
Usually the input was not valid Base64 (truncated, or with URL-safe -_ characters instead of +/), or the original bytes were not text at all. This tool decodes URL-safe variants automatically.
Can I encode files?
This tool is for text. For files, the pattern is a data: URI, which wraps the Base64 string with a MIME type prefix so a browser or mail client knows how to render it — most languages offer one-liners to build one (PHP base64_encode(file_get_contents(...)), JS FileReader.readAsDataURL). Very large files are usually better sent as raw binary rather than Base64-wrapped, given the ~33% size overhead.
Is Base64 safe for passwords?
No — it is trivially reversible by design, with no key or secret involved. HTTP Basic auth uses it only for transport formatting (packing "user:pass" into a header-safe string) and relies entirely on TLS/HTTPS for actual secrecy in transit. Store passwords hashed with a slow, salted algorithm (bcrypt, argon2, scrypt) — never encoded, and never Base64, which anyone can reverse in one line of code.
Why is Base64-encoded output always around 33% bigger than the input?
Because the encoding maps every 3 bytes (24 bits) of input to 4 characters of output, and each output character only carries 6 bits of information instead of a byte's 8 — that's a fixed 4/3 expansion ratio, not something that varies with content. A 3 MB file becomes roughly a 4 MB Base64 string every time.
What's the difference between standard Base64 and the "URL-safe" variant?
Standard Base64 uses + and / in its alphabet, both of which have reserved meaning inside URLs and file paths, so a URL-safe variant replaces them with - and _ (and often omits the = padding) so the encoded string can sit directly in a URL or filename without escaping. This tool recognizes and decodes both variants automatically.
Similar Tools
Report a Problem
Base64 Encode / Decode
Comments
No comments yet — be the first to write one!