Base64 Encoder / Decoder

What Base64 actually does

Base64 represents arbitrary bytes using only 64 printable ASCII characters — the letters A–Z and a–z, the digits 0–9, and + and /, with = as padding. It reads the input three bytes (24 bits) at a time and re-slices those bits into four 6-bit groups, each mapped to one of the 64 characters. The point is never to compress or hide anything — it is to move binary data safely through pipes that were built only for text. You paste a string on the left and its encoded or decoded form appears on the right the instant you type; there is no button to press.

Worked example: encoding "Cat"

Take the 3-byte ASCII string Cat. The bytes are 67 97 116, or in binary 01000011 01100001 01110100 — 24 bits. Base64 regroups those 24 bits into four 6-bit chunks: 010000 110110 000101 110100, which are the values 16 54 5 52. Index those into the alphabet (0=A, 1=B, …) and you get Q 2 F 0 — so Cat encodes to Q2F0. Three input bytes became four output characters, every time. (For a full byte-by-byte walkthrough of the bit regrouping, see the guide Base64 Encoding Explained.) When the input isn't a multiple of 3, Base64 pads: Ca (2 bytes) becomes Q2E= and C (1 byte) becomes Qw==, where each = marks a missing input byte.

That 3→4 ratio is exactly why encoded output is about 33% larger than the input: four characters carry the information of three bytes, so 4 ÷ 3 ≈ 1.333. A 300 KB image becomes roughly 400 KB of Base64 text (a little more once you count padding and any line breaks). The Input and Output byte badges above show this expansion for your exact string.

Base64 is not encryption

This is the single most important point: Base64 hides nothing. There is no key and no secret — the transformation is completely reversible by anyone, which is exactly what the Decode mode here does in a fraction of a second. Encoding a password or an API token in Base64 gives you zero security; it only changes the alphabet the bytes are written in, and a glance at QWxhZGRpbjpvcGVuIHNlc2FtZQ== decodes straight back to Aladdin:open sesame. If you need to protect data, use real encryption (AES, TLS, age). Base64 is about transport and compatibility, never confidentiality.

Standard vs URL-safe alphabet

Standard Base64's +, / and = characters cause trouble in URLs and filenames, where they are reserved or need percent-encoding. The URL-safe alphabet (RFC 4648 §5) swaps two characters and usually drops the padding so the string drops cleanly into a query parameter, a path segment or a JWT:

Only positions 62 and 63 and the padding differ — the first 62 characters are identical. Toggle URL-safe on here to produce that form. When decoding, you do not need to know which variant you have: this tool restores -→+ and _→/ and re-adds any missing = before decoding, so both forms just work.

Where you actually see it

Base64 turns up wherever binary must ride inside text. Data URIs embed a whole image or font directly in HTML or CSS (data:image/png;base64,iVBOR…), saving a request. Email attachments (MIME) are Base64-encoded because SMTP historically guaranteed only 7-bit ASCII. JSON and XML carry binary blobs as Base64 strings since neither format has a native byte type. Basic HTTP auth sends Base64(user:pass), and the header and payload of a JWT are URL-safe Base64. In every case the goal is identical: make bytes survive a text-only channel.

Common mistakes

• Treating it as security. The number-one error — Base64 is a costume, not a lock. Anyone can decode it instantly.
• Using btoa(str) on Unicode. The raw browser btoa throws on any character above code point 255, so it chokes on é, 日本語 or 😀. This tool encodes to UTF-8 bytes first (via TextEncoder), so those characters round-trip exactly.
• Mixing variants without converting. Feeding a URL-safe string with -/_ to a strict standard decoder fails. Convert the alphabet (and restore padding) first — which this tool does automatically.
• Forgetting the size cost. Base64 inflates data ~33%, so it is a poor choice for large payloads where raw bytes or gzip would be far smaller.

Whole files, both directions

File → Base64 reads any file you pick or drop — a PDF, a font, a ZIP, an executable — and encodes its raw bytes locally, in chunks, so the tab stays responsive even on multi-megabyte files. The optional data: URI toggle prefixes the file's own MIME type (a 12 KB WOFF2 font becomes data:font/woff2;base64,d09GMg…, ready for a CSS @font-face); a file whose type the browser cannot detect gets the generic application/octet-stream. Base64 → File is the reverse: paste Base64 (bare, URL-safe or a full data: URI), name the file, and download a byte-exact copy of what the Base64 encodes. Invalid input is rejected with the position of the first offending character — never a silently corrupted download. For images specifically, Image to Base64 is the sharper tool: it previews the picture and emits ready-made <img> and CSS snippets.

Honest limits

File encoding is capped at ~10 MB, and the reason is arithmetic, not marketing: Base64 output is ~1.33× the input, so 10 MB of file becomes a ~13.3 MB string, and building, rendering and copying strings much beyond that freezes a browser tab. Very long results are displayed truncated (the first 500,000 characters) to keep the page snappy — Copy and Download always use the complete string. The text Decode mode assumes the result is UTF-8 text; feed it Base64 that actually represents raw binary (like a PNG) and you get mojibake — use Base64 → File for that instead. Everything runs on your own device using the browser's built-in APIs — no third-party scripts, no network calls — so a token, file or private note you paste is gone when you close the tab. Invalid Base64 (bad characters, misplaced padding or a truncated 4n+1-length string) is caught and reported inline instead of throwing.