Written by Alex Chen · Reviewed by Jane Smith · July 21, 2026
Encode text or files to Base64 and decode Base64 strings back to plain text. All encoding and decoding happens on your device.
The Base64 Encoder / Decoder converts text between plain form and the Base64 format used to carry binary data through text-only channels. Encode mode turns any text into a Base64 string with the browser's btoa(); decode mode turns a Base64 string back into readable text with atob(). You can also load a file — an image, PDF, or document — and get its Base64 data URI, the format you paste into an img src, a CSS url(), or an email body.
Every conversion happens inside this tab. The input never leaves your device, which makes the tool handy for peeking at tokens and payloads you would rather not paste anywhere else.
If a Base64 string is malformed — wrong characters, stray whitespace, or truncated data — the tool does not guess: it shows "Error:" with the reason and leaves the output empty so you know to fix the input first.
Base64 uses an alphabet of 64 characters — A-Z, a-z, 0-9, plus and slash — so each character encodes six bits of data. The encoder reads the input in groups of three bytes, which is 24 bits, and splits each group into four six-bit chunks that map onto the alphabet. That is why every Base64 string has a length that is a multiple of four, and why the format grows the data by roughly a third: four characters carry the same information as three bytes.
When the last group is short — one or two bytes left over — the encoder pads the output with equals signs so the string still ends on a multiple of four. One leftover byte earns a single =; two leftover bytes earn two.
Type hello in Encode mode and the result is aGVsbG8=. The five bytes of "hello" do not divide evenly into three-byte groups, so the last group holds just one byte and earns a single padding sign. Decode the string and you are back to hello — the round trip is exact.
The same rule scales to any input. "Base64" itself becomes QmFzZTY0, and "TL3 Tools" becomes VEwzIFRvb2xz. Run a familiar word through first when you want to confirm the tool is behaving before trusting it with a real payload.
Load a file in Encode mode and the page reads it locally with the FileReader API, then writes the full result — a data URI that begins with data:, carries the file's MIME type, and appends the Base64 payload — into the output box. The input box shows a confirmation line like "[File loaded: logo.png (24.3 KB)]" so you can see exactly which file produced the string, and a toast confirms the conversion. Paste that data URI into an image tag or CSS and the asset loads without a separate network request.
Remember the size math: the data URI is about a third larger than the original file plus a short prefix, so it makes sense for small icons and fonts, not for megabytes of imagery that would bloat a page on every visit.
Data URIs also have a place in prototypes and demos, where a single self-contained HTML file is easier to hand around than a folder of assets. The trade-off is repeatability: every page load re-transmits the encoded bytes, so browsers cannot cache the image the way they cache a separate file.
Base64 is not encryption. Anyone can decode a Base64 string with the same tool, so never rely on it to hide a password, a token, or a private document — encoding only guarantees safe transport, not secrecy.
No. Encoding is a reversible format change with no key, so anyone who recognizes the alphabet can decode it. Encryption scrambles data with a key that the recipient must possess. If you need secrecy, encrypt first and encode the result for transport.
Padding. When the input does not divide into whole three-byte groups, the encoder adds = characters so the output length stays a multiple of four. Decoding removes them automatically.
Yes. The tool encodes input as UTF-8 before applying btoa() and restores it on decode, so emoji, é, and non-Latin scripts come back exactly as typed.
The decoder is strict about the 64-character alphabet and the padding. Whitespace, a stray character, or truncated data triggers an error. URL-safe Base64 — which swaps - and _ for plus and slash — also needs its own variant before this tool will accept it.
No. The FileReader API opens the file directly in the browser and produces the data URI locally. The file stays on your device, which is why the tool is safe for documents you do not want to share.
Base64 spends six bits per character instead of eight, so it needs roughly four characters for every three input bytes — about a 33% increase, plus padding. That is the price of moving binary through text-only channels.