Text and files to Base64 and back: URL-safe alphabet, automatic padding repair, and the real file type detected from a data URI — all in the browser.
The encoded result appears here…Four directions live here: text to Base64, Base64 to text, file to Base64, and Base64 back to a file. The first two are everyday pastes; the last two cover something specific — inlining a small icon into CSS, and recovering the original image from a wall of `data:image/png;base64,…` someone handed you.
The decode side is deliberately forgiving: line breaks, spaces, missing `=` padding, the URL-safe `-` and `_`, even a `data:` prefix are handled automatically — and whatever had to be fixed is listed back to you. Real-world Base64 is rarely clean: copy it out of an email and it arrives wrapped every 76 characters; pull it out of a JWT and it is the unpadded URL-safe variant.
Base64 does exactly one thing: turn every 3 bytes (24 bits) into four 6-bit chunks, each mapped to one of 64 printable characters. No key is involved in either direction, so anyone can reverse it. It survives because of an old constraint — early mail protocols only guaranteed 7-bit-safe transport, so binary attachments had to become plain text. The same encoding now carries PEM certificates, JWTs and data URIs.
The cost is a third more bytes: 3 bytes become 4 characters. Hiding a password or key in a config file by Base64-encoding it is equivalent to leaving it in plain text — a common and costly misunderstanding. To protect content use AES; to prove it was not altered use HMAC.
The browser’s native `atob` is strict — one missing `=` and it throws. Real failures fall into a handful of shapes, and each is handled here:
Base64 moves bytes; it says nothing about character sets. The same sentence is six bytes in UTF-8, four in GBK, and unrepresentable in Latin-1. Decode with the wrong assumption and you get mojibake.
Text decoding here is strict UTF-8: an invalid byte sequence is an error, not a string of replacement characters that looks plausible. You learn that the encoding is wrong, instead of receiving data that appears fine and is quietly corrupted.
A data URI saves one request and costs a third more bytes, loses independent caching, and travels — and blocks rendering — with the stylesheet. Since HTTP/2 made request count a non-issue, the trade has aged badly.
Rule of thumb: icons and font subsets of 1–2 KB are worth inlining; a 50 KB photo usually is not. The output panel shows the exact size increase, and warns past 1 MB — at that size a file reference is the right answer.
A data URI header claims `image/png`, but that text was typed by hand and may be wrong — or absent, leaving bare Base64. So bytes come first, the declaration second: PNG starts `89 50 4E 47`, JPEG `FF D8 FF`, PDF `%PDF`, ZIP `50 4B`. The header is only the fallback when the bytes are unrecognisable.
Recognised types download with the right extension, and images preview inline. Anything unrecognisable falls back to `application/octet-stream` and a `.bin` name — more honest than guessing an extension and letting the OS open it with the wrong application.