Base64 Encoder & Decoder Online

What is Base64 encoding?

Base64 is a way of representing binary data using only 64 printable ASCII characters (A–Z, a–z, 0–9, +, and /, with = used for padding). It's not encryption — anyone can decode it — it's simply a safe way to move binary or non-text data through systems that only reliably handle plain text.

A worked example

Encoding works on bytes, not characters, six bits at a time. Take the three-letter word Cat: as bytes it's 01000011 01100001 01110100 (C, a, t). Regroup those 24 bits into four 6-bit chunks — 010000 110110 000101 110100 — and each chunk becomes an index (0–63) into the Base64 alphabet: 16, 54, 5, 52, which map to the characters Q, 2, F, 0. So "Cat" becomes Q2F0. Three input bytes divide evenly into four 6-bit groups, which is why 3-byte-aligned input needs no padding.

Now take Hi — only 2 bytes (16 bits). 16 doesn't divide evenly into 6, so the encoder pads with zero bits to reach 18, encodes three 6-bit groups (S, G, k), and appends a literal = character to mark that the last group was padded rather than real data. The result is SGk=. A single leftover byte needs two = signs; two leftover bytes need one. This is also why decoding a string with the wrong number of = characters, or one missing entirely, fails — the decoder can't tell real data from padding anymore.

Common uses

• Embedding small images directly in CSS or HTML as data URIs
• Encoding binary attachments for email (MIME) or JSON payloads
• HTTP Basic Authentication headers
• The header and payload segments of a JWT (JSON Web Token)

Mistakes people make

• Treating it as security. Base64 is an encoding, not a cipher — there's no key. Anyone can paste the output back in and read it instantly. Don't put secrets, tokens, or passwords through it expecting protection; use real encryption for that.
• Assuming character count and Base64 length track 1:1. A word full of accented or non-Latin characters (é, ñ, 中) encodes to more bytes per character in UTF-8 first, then those bytes get Base64'd — so the output can be noticeably longer than 4/3 × character count, not just 4/3 × byte count of plain ASCII text.
• Mixing up standard and URL-safe Base64. Some systems (JWTs, URL query parameters) use a variant that replaces + and / with - and _ and often drops the = padding entirely, so it's safe inside a URL. Pasting URL-safe output into a standard decoder (or vice versa) will fail or silently produce garbage — this tool expects standard Base64.
• Stray whitespace or line breaks. Some tools (older email clients, some CLI utilities) wrap encoded output at 76 characters with line breaks. Most modern decoders strip whitespace automatically, but if you're troubleshooting a decode failure, check for an invisible newline or trailing space copied along with the text.

Why decoding can fail

This tool decodes Base64 back into UTF-8 text strictly — if the decoded bytes don't form valid UTF-8 (for example, you pasted the Base64 of a JPEG or a ZIP file into the text box, not actual text), you'll see an "Invalid Base64 input" error instead of a garbled mess. That's intentional: silently rendering invalid text as replacement characters would hide the fact that you decoded the wrong kind of data. If the string you're holding is a binary file, not text, use the Base64 to File panel below instead — it decodes to raw bytes and gives you a download, rather than trying to read them as a string.

How the file panels differ from the text fields

File to Base64 reads a file you pick as a data URL (via the browser's FileReader API), then strips everything before the comma — the data:image/png;base64, prefix describing the file's MIME type — leaving just the raw Base64 payload. Base64 to File runs that in reverse: it decodes the payload back into raw bytes with atob and a Uint8Array, detects the file type from either a data: prefix or the file's own leading bytes, and hands you a download — never attempting to interpret the bytes as characters at any point. Both are a different code path from the text fields above, on purpose: those round-trip through UTF-8 text and reject anything that isn't valid text, while the file panels work on raw bytes the whole way through. Landed here specifically to turn a Base64 string into a downloadable file? The dedicated Base64 to File page has the same panel with a deeper walkthrough of filename and MIME-type detection.

Good to know

Every 3 bytes of input become 4 characters of Base64 output, so encoded text is roughly 33% larger than the original. Decoding reverses this exactly — no data is lost in either direction. That overhead is also why Base64 is a poor choice for anything size-sensitive: embedding a large image as a data URI instead of linking to it as a separate file makes the page itself a third bigger, and unlike a linked file it can't be cached independently by the browser.

When not to use it

Skip Base64 if you actually need compression — it does the opposite, inflating size by about a third. Skip it for anything that needs to stay secret. And skip embedding large files as data URIs in CSS/HTML if the file is reused across pages; a normal linked file that the browser can cache separately will almost always perform better than a data URI baked directly into the markup.